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.

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.

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.