This week’s newsletter summarizes two proposed BIPs related to wallet support for taproot and includes our regular sections describing selected questions and answers on the Bitcoin Stack Exchange, how to prepare for taproot, and notable changes to popular Bitcoin infrastructure projects.

News

• ● PSBT extensions for taproot: Andrew Chow posted a proposed BIP to the Bitcoin-Dev mailing list that defines new fields for PSBTs to use when either spending or creating taproot outputs. The fields extend both the original version 0 PSBTs and the proposed version 2 PSBTs (see Newsletter #128). Both keypath and scriptpath spends are supported.

  The proposed BIP also recommends that P2TR inputs in a PSBT can omit copies of previous transactions because taproot fixes the fee overpayment attack against v0 segwit inputs (see Newsletter #101).

• ● Key derivation path for single-sig P2TR: Andrew Chow also posted a second proposed BIP to the Bitcoin-Dev mailing list suggesting a BIP32 derivation path to use for wallets creating single-sig taproot addresses. Chow notes that the BIP is very similar to BIP49 for P2SH-wrapped P2WPKH addresses and BIP84 for native P2WPKH addresses.

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.

• ● What are the downsides to enabling potentially suboptimal or unused opcodes in a future soft fork? G. Maxwell outlines many considerations for enabling any opcodes that affect consensus including:

  • upfront as well as ongoing maintenance costs

  • potential risks to the user of the opcode but also the entire network

  • additional complexity acting as a disincentive for customizing or reimplementing node software

  • partial or inefficient features crowding out better future alternative ones

  • accidentally creating perverse incentives

• ● Why does blockwide signature aggregation prevent adaptor signatures? Pieter Wuille explains why cross-input signature aggregation interferes with techniques like adaptor signatures or scriptless scripts, noting: “In case of block-wide signature aggregation, there is just a single signature for the entire block. There is simply no space for that single signature to reveal multiple independent secrets to multiple independent parties.”

• ● Should the Bitcoin Core wallet (or any wallet) prevent users from sending funds to a Taproot address pre activation? Murch makes the case for why wallet software should allow users to send to any future BIP173 segwit output types. By putting the onus on the receiver to provide a spendable address, the ecosystem can take advantage of the forward-compatibility of bech32/bech32m and instantly utilize new output types.

• ● Why are the witnesses segregated with schnorr signatures? Dalit Sairio asks why, since schnorr signatures do not suffer from the same malleability that ECDSA signatures do, schnorr signatures will still be segregated? Darosior points out that malleability is only one of the many benefits of segwit. Pieter Wuille adds that signature malleability is only part of broader script malleability.

• ● Possible amount of signatures with MuSig? Nickler explains that for both MuSig and MuSig2 the number of signers is practically infinite, noting that his benchmark with 1 million signers runs in about 130 seconds on his laptop.

• ● Support for P2WSH-wrapped P2TR addresses? In addition to BIP341’s collision security concern, jnewbery also points out the privacy issue with having an additional output type, and the questionable need for wrapped taproot outputs given wide ecosystem adoption of bech32 already.

Preparing for taproot #2: is taproot even worth it for single-sig?

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

Using Optech’s transaction size calculator, we can compare the sizes of different types of single-sig transactions. As expected, transactions using P2WPKH inputs and outputs are much smaller than those using P2PKH inputs and outputs—but, perhaps surprisingly, P2TR transactions are slightly larger than equivalent P2WPKH transactions.

	P2PKH (legacy)	P2WPKH (segwit v0)	P2TR (taproot/segwit v1)
Output	34	31	43
Input	148	68	57.5
2-in, 2-out tx	374	208.5	211.5

That may make it seem counterproductive for single-sig wallets to implement taproot spending in preparation for block 709,632, but a closer look reveals that there are a number of advantages to using P2TR for single-sigs, both for wallet users and for the network as a whole.

• ● Cheaper to spend: it costs about 15% less at the input level to spend a single-sig P2TR UTXO than it does to spend a P2WPKH UTXO. An overly simple analysis like the table above hides the detail that the spender can’t choose which addresses they’re asked to pay, so if you stay on P2WPKH and everyone else upgrades to P2TR, the actual typical size of your 2-in-2-out transactions will be 232.5 vbytes—while all-P2TR transactions will still only be 211.5 vbytes.

• ● Privacy: although some privacy is lost when early adopters change to a new script format, users switching to taproot also immediately receive a privacy boost. Your transactions will be able to look indistinguishable from people working on new LN channels, more efficient DLCs, secure multisignatures, various clever wallet backup recovery schemes, or a hundred other pioneering developments.

  Using P2TR for single-sig now also allows your wallet to upgrade to multisignatures, tapscripts, LN support, or other features later on without affecting the privacy of your existing users. It won’t matter whether a UTXO was received to an old version or a new version of your software—both UTXOs will look the same onchain.

• ● More convenient for hardware signing devices: since the rediscovery of the fee overpayment attack, several hardware signing devices have refused to sign a transaction unless each UTXO spent in that transaction is accompanied by metadata containing a copy of significant parts of the entire transaction which created that UTXO. This greatly increases the worst-case processing that hardware signers need to perform and is especially problematic for hardware signers using limited-size QR codes as their primary communication medium. Taproot eliminates the vulnerability underlying the fee overpayment attack and so can significantly improve the performance of hardware signers.

• ● More predictable feerates: ECDSA signatures for P2PKH and P2WPKH UTXOs can vary in size (see Newsletter #3). Since wallets need to choose a transaction’s feerate before creating the signature, most wallets just assume the worst case signature size and accept that they’ll slightly overpay the feerate when a smaller signature is generated. For P2TR, the exact size of the signature is known in advance, allowing the wallet to reliably choose a precise feerate.

• ● Help full nodes: the overall security of the Bitcoin system depends on a significant percentage of Bitcoin users verifying every confirmed transaction with their own nodes. That includes verifying the transactions your wallet creates. Taproot’s schnorr signatures can be efficiently batch verified, reducing by about 1/2 the number of CPU cycles nodes need to expend when verifying signatures during the process of catching up on previous blocks. Even if you rejected every other point on this list, consider preparing to use taproot for the benefit of people running full nodes.

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, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

• ● Bitcoin Core #22154 adds code that will allow the user to generate bech32m addresses for P2TR scripts after taproot activates in block 709,632, e.g. by calling getnewaddress "" bech32m. If a transaction includes any bech32m addresses after taproot activation, the descriptor wallet will also use a P2TR change output. The feature only applies to wallets with taproot descriptors (see Newsletter #152).

• ● Bitcoin Core #22166 adds support for inferring taproot tr() descriptors from outputs, completing basic taproot descriptor support. Descriptor inference is used to provide more accurate information in responses to RPC calls such as listunspent.

• ● Bitcoin Core #20966 changes the name and format of the saved banlist file from banlist.dat (based on serialized P2P protocol addr messages) to banlist.json. The file format update allows the new list to store ban entries for peers on Tor v3 and peers on other networks with addresses more than 128 bits wide—the maximum width that original addr messages can contain.

• ● Bitcoin Core #21056 adds a new -rpcwaittimeout parameter to bitcoin-cli. The existing -rpcwait parameter will delay sending a command (RPC call) until the bitcoind server has started. The new parameter stops the waiting after the indicated number of seconds, returning an error.

• ● C-Lightning #4606 allows creating invoices over about 0.043 BTC, following a similar change in LND (see Newsletter #93) and the change to the specification described in the next item.

• ● BOLTs #877 removes the protocol-level per-payment amount limit originally introduced to avoid significant losses arising out of implementation bugs. This follows the widespread implementation of option_support_large_channel in 2020, which (when enabled) removed the per-channel amount limit. See the topic on large channels for more details on these two limits.