/ home / newsletters / 

Bitcoin Optech Newsletter #144

Apr 14, 2021

This week’s newsletter summarizes recent progress on code to activate taproot and contains our regular sections with descriptions of a recent Bitcoin Core PR Review Club meeting and notable changes to popular Bitcoin infrastructure software.

• ● Taproot activation discussion: since our last update on discussion about activation methods for the taproot soft fork in Newsletter #139, the Speedy Trial proposal became the focus of attention among those interested in activation. PRs were opened for two variants of it: PR#21377, using a variation on BIP9, and PR#21392, using a modification that became part of BIP8. The main technical difference between these PRs is how their start and stop points were specified. PR#21377 uses Median Time Past (MTP); PR#21392 uses the height of the current block.

  MTP is normally roughly consistent between Bitcoin’s main network (mainnet) and its various test networks, such as testnet, the default signet, and various independent signets. This allows multiple networks to share a single set of activation parameters even if they have vastly different block heights, minimizing the work of keeping those networks’ users in sync with mainnet’s consensus changes.

  Unfortunately, MTP can be easily manipulated in small ways by a small number of miners and in large ways by a majority of hash rate. It can also revert to an earlier time even by accident during a block chain reorganization. By comparison, heights can only decrease in extraordinary reorgs.1 That generally allows reviewers to make the simplifying assumption that height will only ever increase, making it easier to analyze height-based activation mechanisms than MTP mechanisms.

  These tradeoffs between the two proposals, among other concerns, created an impasse that some developers thought was preventing either PR from receiving additional review and, ultimately, getting one of them merged into Bitcoin Core. That impasse was resolved to the satisfaction of some participants in the activation discussion when the authors of the two PRs agreed to a compromise:

  1. To use MTP for the time when nodes begin counting blocks signaling for the soft fork, with counting starting at the beginning of the next 2,016-block retarget period after the start time. This is identical to the way BIP9 versionbits and BIP148 UASF started counting blocks for the soft forks they helped activate.

  2. To also use MTP for the time when nodes stop counting block signaling for a soft fork that hasn’t locked in yet. However, in a difference from BIP9, the MTP stop time is only checked at the end of retarget periods where counting was performed. This removes the ability for an activation attempt to go directly from started to failed, simplifying analysis and guaranteeing that there will be at least one complete 2,016 block period where miners can signal for activation.

  3. To use height for the minimum activation parameter. This further simplifies analysis and also remains compatible with the goal of allowing multiple test networks to share activation parameters. Even though height may differ on those networks, they can all use a minimum activation height of 0 to activate within the window defined by MTP.

  Although some discussion participants expressed their displeasure with the compromise proposal, its implementation has now received reviews or expressions of support from over a dozen active contributors to Bitcoin Core and the maintainers of two other full node implementations (btcd and libbitcoin). We hope this momentum to activate taproot continues and we’ll be able to report additional progress in a future newsletter.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Introduce deploymentstatus is a PR (#19438) by Anthony Towns that proposes three helper functions to make it easier to bury future deployments without changing all the code paths that check a soft fork’s activation status: DeploymentEnabled to test if a deployment can be active, DeploymentActiveAt to check if a deployment should be enforced in the given block, and DeploymentActiveAfter to know if a deployment should be enforced in the following block. All three work with both buried deployments and version bits deployments.

The review club discussion focused on understanding the change and its potential benefits.

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 #21594 adds a network field to the getnodeaddresses RPC to help identify nodes on various networks (i.e. IPv4, IPv6, I2P, onion). The author has also proposed that this lays the groundwork for a future patch for getnodeaddresses that takes an argument of a specific network and returns only addresses in that network.

• ● Bitcoin Core #21166 improves the signrawtransactionwithwallet RPC, allowing it to sign inputs in transactions which have other signed inputs that are not owned by the wallet. Previously, if the RPC was passed a transaction that had signed inputs not owned by the wallet, the witnesses to those inputs would be broken in the returned transaction. Signing inputs in transactions with other signed inputs can be useful in a variety of situations, including adding inputs/outputs to bump the transaction fee.

• ● LND #5108 adds support for making spontaneous Atomic Multipath Payments (also called Original AMPs) using the low-level sendtoroute RPC. Original AMPs are non-interactive (or spontaneous) by nature as the spender selects all preimages. Spender preimage selection is also a part of keysend-style spontaneous payments, which have been used for singlepath spontaneous payments. Follow-up PRs are expected to make spontaneous multipath payments available to the higher-level sendpayment RPC.

• ● LND #5047 allows the wallet to import BIP32 extended public keys (xpubs) and use them for receiving payments to LND’s onchain wallet. In combination with LND’s recently updated support for PSBTs (see Newsletter #118), this allows LND to operate as a watch-only wallet for its non-channel funds. For example, Alice can import the xpub from her cold wallet, deposit funds into that wallet using an address LND gives her, request LND open a channel, sign a PSBT opening that channel with her cold wallet, and then have LND automatically deposit funds back to her cold wallet when the channel is closed. That last part—depositing closed channel funds back to a cold wallet—may require extra steps, particularly in the case of non-cooperatively closed channels, but this change brings LND most of the way towards being fully interoperable with PSBT-compatible cold wallets and hardware wallets.

Footnotes