This week’s newsletter describes a proposal to allow universal transaction replacement by fee and includes the first post in a new weekly series about preparing for taproot. Also included are our regular sections describing updates to clients and services, new releases and release candidates, and notable changes to popular Bitcoin infrastructure projects.

News

  • ● Allowing transaction replacement by default: almost all Bitcoin full nodes today are believed to implement BIP125 opt-in Replace By Fee (RBF), which allows unconfirmed transactions to be replaced in node mempools by alternative versions that pay higher fees—but only if the creator of the transaction sets a signal in the original transaction. This opt-in behavior was proposed as a compromise between people who wanted to allow transaction replacement, such as for fee bumping or additive payment batching, and people who objected because allowing replacement simplifies building tools that defraud merchants who accept unconfirmed transactions as final.

    Over five years later, it appears very few merchants today are accepting unconfirmed transactions as final, and it’s not clear how many of those that do are actually checking for the BIP125 opt-in signal and treating those transactions differently. If no one is relying on BIP125 signals, then allowing every transaction to be replaceable could provide some advantages, such as:

    • ● Simplifying analysis for presigned transaction protocols (such as LN and vaults) where ideas for using RBF fee bumping need to account for a malicious counterparty’s ability to prevent setting the BIP125 signal. If every transaction could be replaced, this wouldn’t be a concern.

    • ● Reducing transaction analysis opportunity because transactions that opt in to RBF look different onchain than transactions which don’t. Since most wallets consistently opt in, or not, this provides evidence that surveillance companies can use in their attempts to identify who owns which bitcoins. If every transaction was replaceable, there’d be no need to set the BIP125 signal.

    This week, Antoine Riard posted a proposal to the Bitcoin-Dev mailing list for eventually changing Bitcoin Core’s code to allow RBF for all transactions regardless of whether or not they set the BIP125 opt-in signal. The idea was also discussed in the first transaction relay workshop meeting. Several meeting participants mentioned Bitcoin Core PR #10823 as an alternative approach—it allows any transaction to be replaced, but only after the transaction had spent a certain amount of time in a node mempool (originally proposed as 6 hours; later suggested to be 72 hours).

    Both Riard’s email and the meeting participants note that any proposal for replacing transactions that don’t contain a BIP125 opt-in signal requires feedback from merchants currently depending on BIP125 behavior. Optech encourages any such merchants to respond to the mailing list thread.

Changes to services and client software

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

Preparing for taproot #1: bech32m sending support

The first segment in a weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

Starting at block 709,632, expected in November, Bitcoin users will be able to safely receive payments to taproot addresses. Given the user enthusiasm for taproot and the five months that wallet developers have to implement support for it, Optech expects there to be several popular wallets that will allow their users to generate taproot addresses at the earliest possible moment.

That means any other wallet or service that sends bitcoins to user-provided addresses needs to be able to send to taproot addresses by block 709,632 or risk confusing and disappointing its users. Pay to TapRoot (P2TR) addresses use bech32m as specified in BIP350, which is slightly different than BIP173’s bech32 algorithm used for segwit v0 P2WPKH and P2WSH addresses. Bech32m uses the constant 0x2bc830a3 instead of bech32’s 0x01 in the checksum function.

Changing that single constant provides the ability to verify bech32m checksums, but the code still needs to use the original constant for existing P2WPKH and P2WSH addresses. The code needs to decode the address without verifying the checksum, determine whether it uses v0 segwit (bech32) or v1+ segwit (bech32m), and then validate the checksum with the appropriate constant. For examples, see the PR that updated the bech32 reference implementations for C, C++, JS, and Python. If the code already uses the reference libraries, they can be updated to the latest code from that repository, although note that some of the APIs have slight changes. BIP350 and the reference implementations provide test vectors that all bech32m implementations should use.

Although receiving payments to taproot addresses won’t be safe until block 709,632, sending payments should not cause any problems for the sender. Bitcoin Core has supported relaying and mining transactions with taproot-paying outputs since version 0.19 (released November 2019). Optech encourages developers of wallets and services to implement support for paying bech32m taproot addresses now rather than waiting until after taproot activates.

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.

  • ● LND 0.13.0-beta is a new major release that improves feerate management by making anchor outputs the default commitment transaction format, adds support for using a pruned Bitcoin full node, allows receiving and sending payments using Atomic MultiPath (AMP), and increases LND’s PSBT capabilities, among many other improvements and bug fixes.

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 #21365 adds the ability for the wallet to create signatures for taproot spends—both keypath spends using only the P2TR public key and scriptpath spends using a tapscript. The wallet can also sign for taproot-spending PSBTs, but only if the wallet already has all the keypath or scriptpath information it needs. The somewhat related merged PR #22156 only allows importing that keypath and scriptpath information after taproot is active (block 709,632 on mainnet, but on test networks where taproot is already enabled, importing may be used now).

  • ● Bitcoin Core #22144 randomizes the order in which peers are serviced in the message handling thread, which is responsible for parsing and processing P2P messages from peers and for sending messages to those peers. Previously, the message handling thread would service each peer round-robin in the order in which the connections to those peers were first established. This PR changes the logic so that, on each iteration of the message handling loop, the order in which peers are serviced is randomized. Peers are still serviced with the same frequency (each peer is serviced once per iteration), but any weaknesses or exploits that rely on a deterministic ordering of servicing peers are avoided.

  • ● Bitcoin Core #21261 makes it easier to extend inbound connection protection to more networks and then uses that framework to add I2P to the list of protected networks. Diversity protection (often called eviction protection) allows a few peers with desirable characteristics to remain connected when Bitcoin Core is otherwise pruning high-latency connections. Retaining a few connections to peers on anonymity networks is highly desirable both because it allows transaction creators to use those networks to hide their network identity and because the ability to receive blocks over those networks in addition to the regular Internet Protocol can prevent some types of eclipse attacks.

  • ● Rust Bitcoin #601 adds support for parsing bech32m addresses and requires that v1+ native segwit addresses be encoded with bech32m and not bech32.

  • ● BTCPay Server #2450 makes generating payjoin-compatible invoices the default when the user opts into using a hot wallet for receiving payments. A button on the create wallet screen allows the user to opt out of this default setting.

  • ● BTCPay Server #2559 adds a separate screen for guiding the user through their choices for how to sign transactions they spend from their wallet. For hot wallets, the server can just sign, but for wallets where the keys are stored elsewhere, an attractive and informative GUI now guides the user through signing options such as entering their recovery mnemonic, using a hardware signing device, or generating a PSBT for transfer to a signing wallet.