Bitcoin Optech: Taproot Signaling – Bitcoin Magazine: Bitcoin News, Articles, Charts and How-tos

The Bitcoin Optech newsletter provides readers with a summary of the most important technical news in Bitcoin, as well as resources to help them learn more. To help our readers stay up to date on Bitcoin, we are posting the latest edition of this newsletter below. Remember to sign up to have this content delivered straight to your inbox.

This week’s newsletter encourages miners to start signaling for tap roots and details the ongoing discussion about closing lost LN channels with just a wallet seed. Also included are our regular sections with announcements of releases and release candidates, as well as notable changes to the popular Bitcoin infrastructure software.

Action elements

• Miners are encouraged to start signaling for tap roots: Miners who are ready to enforce the new consensus rules for tap roots are encouraged to start signaling and ensure that it is Bitcoin Core 0.21.1 (described below) or other compatible Can execute taproots – Forcing software through the minimum activation block specified in BIP341.
  Anyone who wants to trustlessly monitor the 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 blocks that have been signaled, and whether Taproot can be activated in this period (assuming there is no reorganization):

$ bitcoin-cli getblockchaininfo

| jq ‘.softforks.taproot.bip9.statistics | . expired, .number, .possible ‘

353

57

not correct

• If you prefer a graphical representation with additional information on the miner’s progress and do not need to use your own node, we recommend taproot.watch from Hampus Sjöberg.

news

• Closing lost channels with only a BIP32 seed: As described in Newsletter # 128, Lloyd Fournier proposed a method of creating new channels that would allow a user who has lost all information except his BIP32 wallet seed to only let his colleagues can be retrieved using public information via the LN network. As soon as the user has found his peers, he can ask the peers to close their mutual channels using the BOLT2 protocol to protect against data loss (see Newsletter No. 31). The proposed method is not perfect – users should keep making backups1 and replicating them on independent systems – but Fournier’s proposal provides additional redundancy that would be particularly 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 discussions with Fournier and a group discussion during the weekly LN protocol development meeting, Russell said he opposed the idea and said, “I see encrypted backup as a solution that is more likely to be implemented, however. Because they are useful for sending to other places as peers and they can also contain HTLC information if you want. “The ability to include HTLC information would allow any outstanding payments to be settled at this point. This is a feature that no recovery mechanism based solely on a BIP32 seed could provide.

Publications and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new versions or help test release candidates.

• Bitcoin Core 0.21.1 is a new version of Bitcoin Core that includes activation logic for the proposed soft taproot fork. Taproot uses Schnorr signatures and enables the use of Tapscript. These are specified by BIPs 341, 340 and 342, respectively. Also included is the option to pay for bech32m addresses specified by BIP350, although Bitcoins that are issued for such addresses in the mainnet are only safe after activating a soft fork using such addresses. like taproot. The version also contains bug fixes and minor improvements.
  Note: Due to an issue with the CA that provides the code signing certificates for the Windows versions of Bitcoin Core, users on Windows must click through an additional prompt to install. It is expected that there will be a version 0.21.1.1 with an updated certificate when the problem is resolved. If you do plan to upgrade anyway, there is no reason to delay using 0.21.1 because of this issue.
• BTCPay 1.1.0 is the latest major version of this self-hosted payment processing software. It includes Lightning Loop support, adds WebAuthN / FIDO2 as a two-factor authentication option, improves various user interfaces, and marks the switch to using semantic versioning for future version numbers.

Notable code and documentation changes

Notable changes this week to Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Suggestions (BIPs), and Lightning BOLTs.

• Bitcoin Core # 19160 is the next PR in the multiprocess project and offers the Bitcoin node process the ability to generate other processes and communicate with them with Cap’n Proto. These functions are currently only used for testing. However, with the next PR in the project, Bitcoin Core can be started in multiprocess mode, with the Bitcoin Core process generating separate Bitcoin wallet and Bitcoin GUI processes.
• Bitcoin Core # 19521 almost completes coin statistics index project to dramatically speed up RPC gettxoutsetinfo. Until now, the RPC has scanned the entire UTXO set by default on each call, making it difficult for users to continuously and quickly check the coin supply or to compare UTXO set hashes between different nodes. Users can now start their nodes with the -coinstatsindex configuration option to start building the coin statistics index in the background. Once synchronized, gettxoutsetinfo runs almost instantly and users can provide an altitude or block hash for the statistics. The ability to get the statistics for a specific block is particularly useful for allowing community review of assumptions UXO chainstate archives.
• Bitcoin Core # 21009 removes the RewindBlockIndex logic that is triggered when a pre-Segwit node (v0.13.0 or older) is updated to a Segwit-enforcing version. Pre-Segwit nodes only processed stripped blocks that lacked the (separate) witness data. The RewindBlockIndex logic discarded its copies of such blocks, re-downloaded them in their full form, and validated them using the Segwit rules. Since pre-Segwit nodes have not been alive since 2018, the scenario has become unusual. Future versions will instead ask the user to re-index themselves for an equivalent result.
• LND # 5159 builds on previous work to add support for spontaneous Atomic Multipath Payments (AMPs) by manually specifying payment parameters to the Sendpayment RPC. Calling Sendpayment with an AMP invoice is expected to be implemented in follow-up PRs.
• With Rust-Lightning # 893 a payment can only be accepted if it contains a payment secret. Payment secrets are created by the recipient and included in invoices. The donor includes payment secrecy in his payment to prevent third party attempts to compromise the privacy of reusable payments. In addition to this change, there are several API changes that are designed to reduce the chance that a payment will be incorrectly accepted.
• BIPs # 1104 updates the BIP341 specification of tap roots with activation parameters based on the suggestion for a quick test (see Newsletter # 139).

Footnotes

1. The Data Loss Prevention Protocol and other suggested methods, e.g. For example, covert requests for mutual channel closures require your channel peer to remain online and responding. If they are permanently unavailable and you don’t have a backup, your money will be permanently lost. Instead, if you recover from a backup, you might still lose all of your money sending an old status. However, you have the option of getting your money back once you’ve secured the latest status or if your peer is not denying an old state.

You can find the original article here.

Please subscribe directly to the Bitcoin Optech newsletter to receive this content straight to your inbox every month.