Bitcoin Optech # 158: Why Wallets Ought to Wait Earlier than Producing Taproot Addresses


The Bitcoin Optech newsletter provides readers with a summary of the most important technical news about 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 subscribe to get this content straight to your inbox.

This week’s newsletter details the latest changes to services and client software, discusses why wallets should wait before generating taproot addresses, lists new software releases and release candidates, and summarizes notable changes to popular Bitcoin infrastructure software together.


No news to speak of this week.

Changes to services and client software

In this monthly feature we present interesting updates on Bitcoin wallets and services.

Preparing for taproot # 5: why are we waiting?

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

In previous entries in this series, we encouraged developers working on wallets and services to start implementing Taproot upgrades now so that they will be ready when taproot is activated. However, we have also warned against generating addresses for P2TR before block 709,632, as doing so could cause your service or users to lose money.

The reason not to pre-generate addresses is so that any payment to a P2TR-style dispenser can be issued by anyone prior to block 709.632. The money would be completely unsecured. But starting with this block, thousands of full nodes will start enforcing the rules of BIP341 and BIP342 (and associated BIP340).

If it were guaranteed that there would be no reorganization of the blockchain, it would be safe to start generating addresses for P2TR as soon as the last pre-taproot block was seen (block 709.631). But there is cause for concern about blockchain reorgs – not just accidental reorgs, but also ones that are intentionally created to take money from early P2TR payments.

Imagine a large number of people who all want to be one of the first to receive a P2TR payment. They naively send each other some money as soon as they see block 709,631. These payments will be safe in block 709.632, but they can be stolen by any miner who creates an alternative to block 709.631. If the value of the money being sent to P2TR exits is large enough, it could easily become more profitable to try and mine two blocks instead of just one (see our topic on charge wiping for more information).

For this reason, we do not recommend that your software or service generate addresses for P2TR until you are of the opinion that the risk of reorganization has been effectively eliminated. We believe that waiting for 144 blocks (about a day) after activation is a reasonably conservative margin that minimizes risk without significantly preventing you or your users from taking advantage of taproot.

In summary:

  • 709.631: last block where anyone can spend money sent to a P2TR style exit
  • 709.632: first block in which P2TR outputs can only be output if they meet the rules BIP341 and BIP342.
  • 709,776: a reasonable block from which wallets can start giving their users bech32m receiving addresses for P2TR outputs

None of this changes the advice given in the first part of this series in order to be able to pay at bech32m addresses as quickly as possible. If someone requests payment to a P2TR address before you think it’s safe, you’re taking that risk.

Releases and release candidates

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

  • LND 0.13.1-Beta is a maintenance release with minor improvements and bug fixes for features introduced in 0.13.0-Beta.
  • Rust-Lightning 0.0.99 is a version with some API and configuration changes. Please see the release notes for more information.
  • Eclair 0.6.1 is a new version with performance improvements, some new features and several bug fixes. In addition to the release notes, note the descriptions of Eclair No. 1871 and No. 1846 in the “Notable Changes” section below.

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 Proposals (BIPs), and Lightning BOLTs.

  • Bitcoin Core # 22112 changes the accepted port for I2P addresses to 0 instead of 8333 (which is the default for IPv4 and IPv6 addresses) and prevents connections to I2P addresses with ports other than 0. The SAM v3.1 specification (which is supported by Bitcoin Core) does not include the concept of ports. This limitation can be lifted if Bitcoin Core is updated to support SAM v3.2, which incorporates the concept of ports.
  • C-Lightning # 4611 updates the keyend RPC provided by the plug-in to add a routehints parameter that allows information to be provided for routing payments to unannounced channels.
  • C-Lightning # 4646 makes two changes to remove the old behavior. The first change assumes that nodes support the TLV-style coding added in 2019 (see Newsletter # 55). Only nodes that explicitly state that they do not support TLV encoding are treated differently. The second change requires payment secrets (see Newsletter No. 75 for previous discussions and Newsletter No. 126 for starting the LND request).
  • C-Lightning # 4614 updates the listchannels RPC with a new optional destination parameter that can be used to return only channels that lead to the requested node.
  • Eclair # 1871 changes its SQLite settings to increase the number of HTLCs it can process per second by five times and increase its resilience to data loss. In the PR, reference is made to a blog post by Joost Jager, who compares the HTLC throughput in different node software.
  • Eclair # 1846 adds opt-in support for using an upfront shutdown script – an address that the node specifies when negotiating a new channel and that the far end agrees to be the only address it will use on a later one may use mutual closing of the channel. See also newsletter # 76, which describes the implementation of this function by LND.
  • Rust-Lightning # 975 makes the forwarding fee for the base payment configurable with a default value of 1 satoshi (the market price from July 2021). LN Routing Nodes can charge two fees for forwarding a payment, a fixed base fee or a percentage of the forwarded amount; many nodes use both. Previously, Rust-Lightning set the base fee at the estimated fee required to process the HTLC on-chain, which was much higher than 1 Sat.
  • BTCPay Server # 2462 makes it easier to use BTCPay to track payments from a separate wallet, for example if the operator of an instance wants to make a refund with his own personal wallet.


  • Users who want to receive a P2TR payment in the first taproot block should generate an address they will not share with anyone and then create a transaction to that address with nLockTime set to 709,631. This transaction can be sent once block 709.631 has been received. The nLockTime ensures that the transaction cannot be included in a block before 709.632 in which taproot rules are enforced. Playing around with new script types and custom lock times can be dangerous if you don’t know what you are doing, so be careful.

You can find the original article here.

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

Leave A Reply

Your email address will not be published.

Contact Us