Bitcoin Optech #141: Signature Delegation And Taproot Activism

This week’s Bitcoin Optech newsletter covers signature delegation, Taproot’s effect on Bitcoin’s resistance to quantum cryptography and more

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we're republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter describes a technique for signature delegation under Bitcoin’s existing consensus rules, summarizes a discussion about taproot’s effect on Bitcoin’s resistance to quantum cryptography, and announces a series of weekly meetings to help activate taproot. Also included are our regular sections describing notable changes to services and client software, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

Signing delegation under existing consensus rules: Imagine Alice wants to give Bob the ability to spend one of her UTXOs without immediately creating an onchain transaction or giving him her private key. This is called delegation and it’s been discussed for years, perhaps most notably in recent times as part of the graftroot proposal. Last week, Jeremy Rubin posted to the Bitcoin-Dev mailing list a description of a technique to accomplish delegation using Bitcoin today.
Let’s say Alice has UTXO_A and Bob has UTXO_B. Alice creates a partially signed transaction spending both UTXO_A and UTXO_B. Alice signs for her UTXO using the sighash flag SIGHASH_NONE, which prevents the signature from committing to any of the transaction’s outputs. This gives the owner of the other input in the transaction—Bob—unilateral control over the choice of outputs, using his signature with the normal SIGHASH_ALL flag to commit to those outputs and prevent anyone else from modifying the transaction. By using this dual-input SIGHASH_NONE trick, Alice delegates to Bob the ability to sign for her UTXO.
This technique appears to be mainly of theoretical interest. There are other proposed delegation techniques—including graftroot, OP_CHECKTEMPLATEVERIFY, and OP_CHECKSIGFROMSTACK—that would likely be superior in several ways, but only this technique is currently usable on mainnet for anyone who wants to experiment with it.
Discussion of quantum computer attacks on taproot: the original Bitcoin software provided two ways to receive bitcoin:

Pay-to-Public-Key (P2PK) implemented the simple and clear method described in the original Bitcoin paper of receiving bitcoins to a public key and allowing those coins to be spent by a signature. The Bitcoin software used this by default when the public key material could be handled entirely by software.
Pay-to-Public-Key-Hash (P2PKH) added a layer of indirection, receiving bitcoins to a hash digest that committed to the public key to be used. To spend the coins, the public key would need to be published alongside the signature, making the 20 bytes dedicated to the hash digest an overhead cost. This was used by default when the payment information might need to be handled by a person, e.g. an address that could be copied and pasted.

Nakamoto never described why he implemented both methods, but it’s widely believed that he added the hash indirection in order to make Bitcoin addresses smaller so that they could be communicated more easily. Public keys in the original Bitcoin implementation were 65 bytes, but address hashes were only 20 bytes.
In the decade since, there have been a number of developments. To make certain multisig protocols simple and secure by default, it was determined that scripts for multiparty protocols should probably use a 32-byte commitment. Bitcoin developers also learned about previously known techniques that could compress a public key down to 33 bytes—later describing how to optimize that to 32 bytes. Finally, taproot’s primary innovation showed that a 32-byte public key could commit to a script with security similar to that of a 32-byte hash. All of this means that it no longer changes the amount of address data people have to communicate whether they use a hash or a public key—it’s 32 bytes either way if they want a universally applicable address format. However, directly using public keys still eliminates the extra bandwidth and storage resulting from hash indirection. If every payment went to a public key instead of a 32-byte hash, it would save about 13 gigabytes of block chain space per year. The BIP341 specification of taproot describes space savings as the reason it accepts payments to public keys in the P2PK style instead of hashes in the P2PKH style.
But P2PKH hash indirection does have one advantage: it can hide keys from public view until they’re needed to authorize a spend. This means an adversary who has the ability to compromise the security of a public key might not be able to start using that ability until a transaction is broadcast, and they may lose the ability to steal funds controlled by that key once the transaction is confirmed to a certain depth. This limits the amount of time available for their attack and means a slow attack might not work. Although this has previously been discussed at length in the context of taproot’s choice to directly use public keys in the P2PK style (see 1, 2, and newsletters #70 and #86), it was the subject of renewed discussion this week on the Bitcoin-Dev mailing list after the publication of an email opposing taproot out of fear that we could see a quantum computer powerful enough to attack Bitcoin-style public keys “as soon as the end of the decade.”
None of the participants in the mailing list discussion said they also opposed taproot, but they did examine the argument’s premises, discuss alternatives, and evaluate what tradeoffs would be implied by those alternatives. A selection of those conversations are summarized below:

Hashes not currently doing a good job at QC resistance: as of a 2019 survey, an attacker with a powerful QC and nothing else besides a copy of the Bitcoin block chain could steal over 1/3 of all bitcoins. Most of those would be the result of users reusing addresses, a discouraged practice—but one that seems unlikely to go away soon.
Additionally, discussion participants pointed out that anyone who shares their individual public keys or BIP32 extended public keys (xpubs) with third parties would also be at risk from a powerful QC if their public keys leaked. This would likely include most bitcoins stored with a hardware wallet or in an LN payment channel. In short, it’s possible that even though we almost universally use P2PKH-style hashed public keys today, nearly all bitcoins could be stolen by a powerful QC with access to public or third-party data. That implies that the choice to use P2PK-style non-hashed public keys with taproot doesn’t significantly change Bitcoin’s current security model.
Taproot improvement in post-QC recovery at no onchain cost: if Bitcoiners learn that a powerful QC has manifested, or soon will, they can reject any taproot key-path spends—the type of spend where only a single signature is used. However, a user who prepares ahead when creating their taproot address can also spend bitcoins received to that address using a script-path spend. In that case, the taproot address commits to a hash of the tapscripts the user wants to use. That hash commitment can be used as part of a scheme to transition to a new cryptographic algorithm that’s safe against QCs, or—if such an algorithm is standardized for Bitcoin before QCs become a threat—it can allow the owner of the bitcoins to immediately transition to the new scheme. This does only work if individual users create backup tapscript spending paths, if they don’t share any public keys (including BIP32 xpubs) involved in those backup paths, and if we learn about a powerful QC before it does too much damage to Bitcoin.
Is the attack realistic? One respondent thought a fast QC by the end of the decade was “on the wildly optimistic side of projected rate of progress.” Another noted it was a “fairly straightforward engineering challenge” to turn the design for a single slow QC into a farm of QCs that could work in parallel, achieving results in a fraction of the time—making any protection from P2PKH-style hash indirection irrelevant. A third respondent proposed constructing special Bitcoin addresses that could only be spent from by someone making progress on fast QCs; users could voluntarily donate bitcoins to the addresses to create an incentivized early warning system.
We could add a hash-style address after taproot is activated: if a significant number of users really do think the sudden appearance of a powerful QC is a threat, we could use a follow-up soft fork to add an alternative P2PKH-style taproot address type that uses hashes. However, this has consequences that caused several respondents to oppose it:

It’ll create confusion
It’ll use more block space
It reduces the size of taproot’s anonymity set, both directly and when protocols such as ring signature membership proofs or Provisions are being used

Bandwidth/storage costs versus CPU costs: it’s possible to eliminate the extra 32-byte storage overhead from hash indirection by deriving the public key from a signature and the transaction data it signs, a technique called key recovery. Again, this was opposed. Key recovery requires a significant amount of CPU that would slow down nodes and also prevents the use of schnorr batch validation that can make historic block verification up to three times faster. It also makes anonymous membership proofs and related techniques both harder to develop and much more CPU intensive. There may also be a patent issue.

As of this writing, it appears the mailing list discussion has concluded without any obvious loss of community support for taproot. As researchers and businesses continue improving the state of the art in quantum computing, we expect to see future discussions about how to best keep Bitcoin secure.
Weekly taproot activation meetings: ten weekly meetings to discuss details related to activating taproot have been scheduled for each Tuesday at 19:00 UTC in the ##taproot-activation IRC channel, with the first meeting occurring yesterday (March 23rd).

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

OKCoin launches Lightning deposits and withdrawals: A blog post outlines OKCoin’s Lightning deposit and withdrawal support. They also lowered their minimum deposit/withdrawal limit from 0.001 to 0.000001 BTC as a result. At this time, 0.05 BTC is OKCoin’s limit when transacting using LN.
BitMEX announces bech32 support: In a blog post, BitMEX detailed the launch plans for bech32 deposit support. BitMEX had previously rolled out bech32 withdrawal (send) support.
Specter v1.2.0 released: Specter v1.2.0 includes support for Bitcoin Core descriptor wallets and coin control features.
Breez streams audio for Lightning payments: Breez wallet has integrated an audio player which, combined with keysend, allows users to listen to podcasts while streaming payments to the publisher and sending one-off tip payments.
Key manager Dux Reserve announced: Thibaud Maréchal announced Dux Reserve, a beta open source desktop key manager supported on MacOS, Windows, and Linux and supporting Ledger, Coldcard, and Trezor hardware wallets.
Coldcard now using libsecp256k1: Coldcard’s version 4.0.0, among other features, switches to using Bitcoin Core’s libsecp256k1 library for its cryptographic operations.

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.

C-Lightning 0.10.0-rc1 is a release candidate for the next major version of this LN node software.

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 #20861 implements support for BIP350 (Bech32m format for v1+ witness addresses). Bech32m supersedes bech32 (BIP173) as the address format for native segwit outputs of version 1-16. Native segwit version 0 outputs (P2WPKH and P2WSH) will continue to use bech32. This PR would enable Bitcoin Core users to send payments to Pay to Taproot (P2TR) addresses once taproot outputs (BIP341) were defined on the network. The change should not affect any mainnet systems, but may cause address incompatibility issues in testing environments such as signet where taproot is already active using bech32-encoded addresses as previously proposed. Bech32m support will also be backported to Bitcoin Core 0.19, 0.20, and 0.21.
Bitcoin Core #21141 updates the -walletnotify configuration setting that calls a user-specified command each time a transaction is seen that affects a loaded wallet. Two new placeholders are added to the arguments that can be passed to the command, %b for the hash of a block containing the transaction and %h for the height of the block. Both are set to defined values for unconfirmed transactions.
C-Lightning #4428 deprecates the fundchannel_complete RPC’s acceptance of txids, requesting instead that a PSBT be passed. The PSBT can be checked to ensure it contains the funding output, eliminating a problem where a user who passes incorrect data can lose the ability to recover their funds.
C-Lightning #4421 implements the funding transaction recovery procedure covered in last week’s newsletter. Users who mistakenly funded channels with a first-party malleated transaction (e.g. using RBF) but haven’t used the channel yet can now supply their transaction output to the lightning-close command to negotiate recovery with a peer supporting the shutdown_wrong_funding feature.
LND #5068 makes available a number of new configuration options for limiting how much network gossip information LND processes. This can help on systems with limited resources.
Libsecp256k1 #831 implements an algorithm that can speed up signature verification by 15%. It can also reduce by 25% the amount of time it takes to generate signatures while still using a constant-time algorithm that maximizes side-channel resistance. It additionally removes some of Libsecp256k1’s dependencies on other libraries. See Newsletter #136 for more information about this optimization.