Bitcoin Optech: Taproot Signaling – Bitcoin Magazine: Bitcoin News, Articles, Charts, and Guides

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 encourages miners to start signaling for taproot and describes continued discussion about closing lost LN channels using only a wallet seed. Also included are our regular sections with announcements of releases and release candidates, plus notable changes to popular Bitcoin infrastructure software.

Action items

Miners encouraged to start signaling for taproot: miners who expect to be willing to enforce the new consensus rules for taproot are encouraged to begin signaling and to ensure they’ll be able to run Bitcoin Core 0.21.1 (described below) or other compatible taproot-enforcing software by the minimum activation block specified in BIP341.
Anyone wanting to trustlessly monitor signaling progress can upgrade to Bitcoin Core 0.21.1 and use the getblockchaininfo RPC. For example, the following command line prints the number of blocks in the current retarget period, the number of those blocks which have signaled, and whether it’s possible for taproot to activate in this period (assuming there’s no reorg):

$ bitcoin-cli getblockchaininfo

| jq ‘.softforks.taproot.bip9.statistics | .elapsed,.count,.possible’

353

false

If you prefer a graphical representation with supplementary information about miner progress and don’t need to use your own node, we recommend taproot.watch by Hampus Sjöberg.

News

Closing lost channels with only a BIP32 seed: as described in Newsletter #128, Lloyd Fournier proposed a method for creating new channels that would allow a user who lost all information except for their BIP32 wallet seed to re-discover their peers using only public information about the LN network. Once the user found their peers, they could request the peers close their mutual channels using the BOLT2 data loss protection protocol (see Newsletter #31). The proposed method isn’t perfect—users should still create backups1 and replicate them across independent systems—but Fournier’s proposal provides additional redundancy that would be especially useful for everyday users.
Two weeks ago, Rusty Russell restarted the thread after trying to specify and implement the idea. After some additional mailing list discussion with Fournier and a group conversation in the weekly LN protocol development meeting, Russell indicated he was leaning against the idea, saying “I see encrypted backups as a more-likely-to-be-implemented solution though. Because they’re useful to send to places other than peers, and they can also contain HTLC information if you want.” Being able to contain HTLC information would allow settling payments that were pending at that time, which is a capability no recovery mechanism based solely on a BIP32 seed could provide.

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.

Bitcoin Core 0.21.1 is a new version of Bitcoin Core that contains activation logic for the proposed taproot soft fork. Taproot uses schnorr signatures and allows the use of tapscript. These are, respectively, specified by BIPs 341, 340, and 342. Also included is the ability to pay bech32m addresses specified by BIP350, although bitcoins spent to such addresses on mainnet will not be secure until activation of a soft fork using such addresses, such as taproot. The release additionally includes bug fixes and minor improvements.
Note: due to a problem with the certificate authority that provides the code signing certificates for the Windows versions of Bitcoin Core, users on Windows will need to click through an extra prompt to install. It is expected that there will be a 0.21.1.1 release with an updated certificate when the problem is fixed. If you are planning to upgrade anyway, there’s no reason to delay using 0.21.1 because of this problem.
BTCPay 1.1.0 is the latest major release for this self-hosted payment processing software. It includes Lightning Loop support, adds WebAuthN/FIDO2 as a two-factor authentication option, makes various UI improvements, and marks a switch to using semantic versioning for version numbers moving forward.

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 #19160 is the next PR in the multiprocess project and adds the ability for the bitcoin-node process to spawn other processes and communicate with them using Cap’n Proto. These features are currently only used for testing, but the next PR in the project will allow Bitcoin Core to be started in multiprocess mode with the bitcoin-core process spawning separate bitcoin-wallet and bitcoin-gui processes.
Bitcoin Core #19521 nearly completes the coin statistics index project to dramatically speed up the gettxoutsetinfo RPC. Until now, the RPC defaulted to scanning the full UTXO set every time it was called, making it difficult for users to continually and quickly verify the coin supply or compare UTXO set hashes between different nodes. Users can now start their nodes with the -coinstatsindex configuration option to begin building the coin statistics index in the background. Once it is synced, gettxoutsetinfo runs nearly instantly and users can specify a height or block hash for the statistics. Being able to get the statistics for a particular block will be especially useful for allowing community verification of assumeUTXO chainstate archives.
Bitcoin Core #21009 removes the RewindBlockIndex logic triggered when updating a pre-segwit node (v0.13.0 or older) to a segwit-enforcing version. Pre-segwit nodes only processed stripped blocks that lacked the (segregated) witness data. The RewindBlockIndex logic discarded its copies of such blocks, re-downloaded them in their complete form, and validated them using segwit’s rules. As pre-segwit nodes have been end-of-life since 2018, the scenario has become uncommon. Future releases will instead prompt the user to reindex for an equivalent outcome.
LND #5159 builds on previous work to add support for making spontaneous Atomic Multipath Payments (AMPs) by manually specifying payment parameters to the sendpayment RPC. Invoking sendpayment with an AMP invoice is expected to be implemented in follow-up PRs.
Rust-Lightning #893 only allows accepting a payment if it includes a payment secret. Payment secrets are created by the receiver and included in invoices. The spender includes the payment secret in their payment in order to prevent attempts by third parties to reduce the privacy of multipath payments. Alongside this change are several API changes designed to reduce the chance that a payment will be accepted incorrectly.
BIPs #1104 updates the BIP341 specification of taproot with activation parameters based on the Speedy Trial proposal (see Newsletter #139).

Footnotes

The data loss protection protocol, and other proposed methods such as covert requests for mutual channel closes requires your channel peer to still be online and responsive. If they’ve become permanently unavailable and you don’t have a backup, your funds are permanently lost. If, instead, you recover from a backup, you might still lose all of your funds if you broadcast an old state, but you have a chance to recover your funds if you backed up the latest state or if your peer doesn’t contest an old state.

Find the original post here.