RT @murchandamus
WTF are you smoking @earndotcom?

PSA: Don't use Earn's fee estimates unless you enjoy overpaying by a factor of 20.

Episode 499 of Bitcoin And . . . is LIVE!

Topics for today:

- FDIC and
- benefits from Bitcoin
- The FED: A history
- Bitcoin in
- Teen scams 48 bitcoin
- ad

$BTC
soundcloud.com/bitcoin-and/bit

RT @raphschoen:

- Tesla will accept BTC payments again
- Retail banks will be allowed to hold BTC
- Mastercard holders will soon be rewarded with BTC
- Square will offer open-source BTC mining for everyone
- Lightning Network hitting ATHs
- Taproot going into effect on November 16

🚀 🚀 🚀

twitter.com/raphschoen/status/

The private keys of the Italian greenpass (our lovely vax passport) have been compromised.
Some people are going around with valid certificates with the name of a famous Austrian politician
---
RT @mrk4m1
Il sistema di creazione dei Green Pass è stato violato, probabilmente con chiavi private compromesse.

L'Italia ha subordinato diritti costituzionali all'uso di un sistema insicuro, violato a distanza di pochi mesi dalla sua istituzione.

twitter.com/mrk4m1/status/1453

RT @StepanSnigirev
New release of Specter-DIY is out. It includes a few minor bugfixes and moves Liquid to production so you don't need to enable it in experimental settings anymore.
Taproot is still experimental as we didn't implement taproot-specific fields for PSBT yet.
github.com/cryptoadvance/spect

Bitcoin Optech Newsletter #172

This week’s newsletter includes our regular sections with summaries of popular questions and answers from the Bitcoin Stack Exchange, information about preparing for taproot activation, a list of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure projects.

News

No significant news this week.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users.In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

Where to find the exact number of hashes required to mine most recent block? Pieter Wuille notes what while a block’s attempted number of hashes is not published, a formula of 4,295,032,833 times the block’s difficulty provides a simple way of estimating the expected number of hashes to solve a block.
Using a 2-of-3 taproot keypath with schnorr signatures? Pieter Wuille points out that, although BIP340 requires 1 key and 1 signature, it is also possible to use threshold signature schemes like FROST, multisignature schemes like MuSig, and others.
Why coinbase maturity is defined to be 100 and not 50? User liorko asks why the constant 100, instead of 50, was chosen for Bitcoin’s coinbase maturity duration. Answers point out the unexplained and potentially arbitrary nature of the choice.
Why does Bitcoin use double hashing so often? Pieter Wuille lists where the double-SHA256 and SHA256+RIPEMD160 double hash schemes were initially used in Bitcoin, notes where new features used the same schemes, and hypothesizes that Satoshi used these double hash schemes, mistakenly, to mitigate against certain attacks.

Preparing for taproot #19: future consensus changes

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

As taproot nears activation at block 709,632, we can start to look forward to some of the consensus changes that developers have previously expressed the desire to build on top of taproot.

●Cross-input signature aggregation:schnorr signatures make it easy for owners of several distinct public and private key pairs to create a single signature that proves all of the key owners cooperated in creating the signature. With a future consensus change, this may allow a transaction to contain a single signature which proves the owners of all the UTXOs being spent in that transaction authorized the spend. This will save about 16 vbytes per keypath spend after the first input, providing significant savings for consolidation and coinjoins.It could even make coinjoin-based spending cheaper than spending by yourself, providing a mild incentive to use more private spending.
●SIGHASH_ANYPREVOUT: every normal Bitcoin transaction includes one or more inputs, and each of those inputs references the output of a previous transaction, using its txid.That reference tells full verification nodes like Bitcoin Core how much money the transaction can spend and what conditions need to be fulfilled to prove the spend was authorized. All ways of generating signatures for Bitcoin transactions, both with and without taproot, either commit to the txids in the prevouts or don’t commit to the prevouts at all.
That’s a problem for multiuser protocols that don’t want to use a precise pre-arranged series of transactions.If any user can skip a particular transaction, or change any detail of any transaction besides its witness data, that will change any later transaction’s txid.Changing the txid invalidates any signatures previously created for later transactions.This forces offchain protocols to implement mechanisms (such as LN-penalty) that penalize any user who submits an older transaction.
SIGHASH_ANYPREVOUT can eliminate this problem by allowing a signature to skip committing to the prevout txid.Depending on other flags used, it will still commit to other details about the prevout and the transaction (such as amount and script), but it will no longer matter what txid is used for the previous transaction.This will make it possible to implement both the eltoo layer for LN and improvements in vaults and other contract protocols.
●Delegation and generalization: after you create a script (taproot or otherwise), there’s almost no way for you to delegate to additional people the ability to spend from that script short of giving them your private key (which can be extremely dangerous when using BIP32 wallets).Additionally, taproot could be made more affordable for users who want to use a keypath spend plus just a small number of script-based conditions.Several methods for enhancing taproot by generalizing it and providing signer delegation have been proposed:
●Graftroot:proposed shortly after the introduction of the idea for taproot, graftroot would give an extra feature to anyone capable of making a taproot keypath spend.Instead of directly spending their funds, the keypath signers could instead sign a script that described new conditions under which the funds could be spent, delegating spending authority to anyone capable of satisfying the script.The signature, the script, and whatever data was needed to satisfy the script would be provided in the spending transaction.The keypath signers could delegate to an unlimited number of scripts in this way without creating any onchain data until an actual spend occurred.
●Generalized taproot (g’root): a few months later, Anthony Towns suggested a way to use public key points to commit to multiple different spending conditions without necessarily using a MAST-like construction.This generalized taproot (g’root) construction is “potentially more efficient for cases where the taproot assumption doesn’t hold”.It also “offers an easy way to construct a softfork-safe cross-input aggregation system”.
●Entroot: a more recent synthesis of graftroot and g’root that simplifies many cases and makes them more bandwidth efficient.It can support signer delegation from anyone able to satisfy any of the entroot branches, not just those able to create a top-level keypath spend.
●New and old opcodes: the taproot soft fork includes support for tapscript which provides an improved way to add new opcodes to Bitcoin, OP_SUCCESSx opcodes.Similar to the OP_NOPx (no operation) opcodes added early in Bitcoin’s history, the OP_SUCCESSx opcodes are designed to be replaced with opcodes that don’t always return success.Some proposed new opcodes include:
●Restore old opcodes: a number of opcodes for math and string operations were disabled in 2010 due to concerns about security vulnerabilities.Many developers would like to see these opcodes re-enabled after a security review, and (in some cases) perhaps extended to handle larger numbers.
●OP_CAT: one of the previously-disabled opcodes that deserves special mention is OP_CAT, which researchers have since discovered can enable all sorts of interesting behavior on Bitcoin by itself, or which can be combined with other new opcodes in interesting ways.
●OP_TAPLEAF_UPDATE_VERIFY: as described in Newsletter #166, an OP_TLUV opcode can enable covenants in a way that’s particularly efficient and powerful when used with taproot’s keypath and scriptpath capabilities.This can be used to implement joinpools, vaults, and other security and privacy improvements.It may also combine well with OP_CHECKTEMPLATEVERIFY.

All of the ideas above are still only proposals.None is guaranteed to be successful.It’ll be up to researchers and developers to bring each proposal to maturity and then for users to decide whether adding each feature to Bitcoin is worth the effort of changing Bitcoin’s consensus rules.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects.Please consider upgrading to new releases or helping to test release candidates.

Rust-Lightning 0.0.102 is a release that makes several API improvements and fixes a bug that prevented opening channels with LND nodes.
C-Lightning 0.10.2rc1 is a release candidate that includes a fix for the uneconomical outputs security issue, a smaller database size, and an improvement in the effectiveness of the pay command (see the notable changes section below).

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

Bitcoin Core #23002 makes descriptor-based wallets the default when creating a new wallet. Descriptor-based wallets were first introduced in Bitcoin Core PR #16528. There is a long-term plan to migrate all wallets to be descriptor-based and eventually phase out support for legacy wallets.
Bitcoin Core #22918 extends the getblock RPC and /rest/block/ endpoint with a new level of verbosity (3) that includes information about each previously-created output (“prevout”) being spent in the block.
When a block creates a new unspent transaction output (UTXO), Bitcoin Core stores it in a database.When a later transaction attempts to spend that UTXO, Bitcoin Core retrieves it from the database and verifies the spend fulfills all required conditions (e.g. includes a valid signature for the correct public key).If every spend in a block is valid, Bitcoin Core moves those prevout entries out of the UTXO database and into an undo file that can be used to restore the UTXO database to its previous state if the block is later removed from the chain during a reorg.
This PR retrieves the prevouts from the undo file and includes them as part of the information that’s actually included in the block or computed from its contents.For users and applications who need prevout data, this is much faster and more convenient than directly looking up each previous transaction and its outputs.Full nodes that have pruning enabled will delete older undo files and so will be unable to use the new verbosity level three for those blocks.
C-Lightning #4771 updates the pay command to prefer routes that include channels with a larger total amount of funds (channel capacity), all other things being equal.The total amount of funds in a channel is publicly known; what’s not publicly known is how much funding is available in each direction of the channel.However, if two channels each have an equal probability of being in any state, then the larger channel’s capacity is more likely to be able to handle the payment size than the smaller channel.
C-Lightning #4685 adds an experimental websocket transport based on the draft specification in BOLTs #891.This will allow C-Lightning (and other LN implementations that support the same protocol) to advertise an alternative port to use for communication with peers.The underlying LN communication protocol remains the same, it is just performed using binary websocket frames rather than pure TCP/IP.
Eclair #1969 extends the findroute* set of API calls with several additional parameters: ignoreNodeIDs, ignoreChannelIDs, and maxFeeMsat.It also adds a full format that returns all the information known about the found routes.
LND #5709 (originally #5549) adds a new commitment transaction format for use between nodes supporting Lightning Pool (see Newsletter #123), which are currently only LND nodes. The new format will prevent the node offering a channel lease from being able to spend their funds onchain until the lease period ends. This provides them an incentive to keep the channel open for the lease period so that they can use their funds (liquidity) to earn routing fees.A channel’s commitment transaction format is only seen between its two direct peers while a channel is open, so any format can be used without affecting other nodes on the network.
LND #5346 adds the ability for an LND node and its peer to exchange custom messages—those with a type identifier above 32,767. A number of suggested uses for custom messages are suggested in the pull request.The lncli command is updated to simplify sending and listening for custom peer messages.
LND #5689 adds the ability for an LND node to delegate all private key operations to a remote, mostly-offline “signer” node. Detailed documentation is available here.
BTCPay Server #2517 adds support for issuing payouts or refunds via LN.The administrator can enter an amount to pay, the receiver can then enter their node details and have the payment sent to them.
HWI #497 sends additional information to devices using Trezor firmware that allows them to verify a change address belongs to a multisig federation.Otherwise, Trezor shows the change as a separate payment, requiring the user to manually verify their change address is correct.

Selected Q&A from Bitcoin Stack Exchange include:

- Where to find the exact number of hashes required to mine most recent block?
- Using a 2-of-3 taproot keypath with schnorr signatures?
- Why coinbase maturity is defined to be 100 and not 50?
- Why does Bitcoin use double hashing so often?

bitcoinops.org/en/newsletters/

Show thread

Bitcoin Optech newsletter #172 is here:

- summarizes popular questions and answers from the Bitcoin Stack Exchange
- continues the 'how to prepare for taproot' series: future consensus changes
- Rust-Lightning 0.0.102, C-Lightning 0.10.2rc1 releases

bitcoinops.org/en/newsletters/

Preparing for taproot #19: future consensus changes

As taproot nears activation at block 709,632, we can start to look forward to some of the consensus changes that developers have previously expressed the desire to build on top of taproot.

- Cross-input signature aggregation
- SIGHASH_ANYPREVOUT
- Delegation and generalization
- New and old opcodes

bitcoinops.org/en/newsletters/

Show thread

Smaller blocks, would be much easier to broadcast on HF AM “shortwave” low bandwidth 250bps (FM much higher)

As big media dies, Bitcoiners buy AM/FM stations & repurpose them to broadcast blocks

They are substantially more decentralized than satellite uplinks

Bit of everything

Yes! Bitcoin network doesn’t even know what a full bitcoin is.

All it knows is 2,100,000,000,000,000 (2.1e15) units
---
RT @FarooqAhmedX
There are 100,000,000 bitcoins in a Bitcoin.
twitter.com/FarooqAhmedX/statu

The improvement can be already felt: twitter.com/renepickhardt/stat

Check the UPDATE menu on your blitzes!
---
RT @steepdawn974
@openoms Amazing, upgrading to v0.10.2rc1 did the trick ➡️ all transactions go through! 🥳

Tx take quite a while (longer than with a, I would say, less-well connected LND node) with lots of attempts, but they do succeed.
Thanks for the tip 👍
twitter.com/steepdawn974/statu

RT @[email protected]

Right. The vaccine passes are ALREADY a social credit system - a reward from the state for doing what you are told, and nothing else.

twitter.com/tristaneldritch/st

--
RT @[email protected]

I had been agreeing with people who posited another function—to usher in a social credit system.

I now think that is incorrect. It IS a social credit system. It’s version one—there is no logic or science supporting it, it’s simply a compliance passport.

twitter.com/renegademormon/sta

RT @bitcoinpods
“The oil price went negative”

@saylor on  

(@bitcoinmagazine with @mcshane_writes )

TODAY - 3rd largest whale added 105 BTC to their wallet.

They now own 106,459 BTC with unrealized gains of $4.4 billion.

Federated MiniMints is a great concept for many African regions, where people save money in groups or families. Or as a basis for regional currencies. It scales .
@Blockstream @kiarabickers @EricSirion medium.com/blockstream/blockst

Lightning pool is very cool, this is actual 'defi'. The world is really sleeping on lightning development imo, I can't wait to see what the next decade brings.

I might try to get it running, anyone on here have any experience using it?
(I need to rebuild my lightning node... again... probably not on a rPi this time)

pool.lightning.engineering/ove

Even before @Bitrefill was a sponsor of my work I found it to be one of the most important platforms for people in emerging countries to get access to and use it to support their daily lifes. Congratulations @ziggamon and team!
---
RT @ziggamon
Today marks 7 years since I announced the prototype for Bitrefill to the world.

Today we're a team of 40+ people, we're profitable but still founder-controlled as a company, that is the c…
twitter.com/ziggamon/status/14

Show older
Bitcoin Mastodon

Bitcoin Maston Instance