{"id":15559,"date":"2021-07-21T21:25:00","date_gmt":"2021-07-21T21:25:00","guid":{"rendered":"http:\/\/ci0288b3fe900025a3"},"modified":"2025-10-01T15:33:14","modified_gmt":"2025-10-01T20:33:14","slug":"bitcoin-wallets-wait-for-taproot","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-wallets-wait-for-taproot","title":{"rendered":"Bitcoin Optech #158: Why Wallets Should Wait Before Generating Taproot Addresses"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>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&#8217;re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.<\/em><\/p>\n<p>This week\u2019s newsletter describes recent 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.<\/p>\n<h2>News<\/h2>\n<p><em>No significant news this week.<\/em><\/p>\n<h2>Changes to services and client software<\/h2>\n<p><em>In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.<\/em><\/p>\n<ul>\n<li>Lightning-powered news site Stacker News launches: <a href=\"https:\/\/github.com\/stackernews\/stacker.news\" target=\"_blank\" rel=\"noopener\">Open source<\/a> news site <a href=\"https:\/\/stacker.news\/\" target=\"_blank\" rel=\"noopener\">Stacker News<\/a>&nbsp;launched allowing LNURL authentication as well as voting and commenting using LN micropayments.<\/li>\n<li>Suredbits announces DLC wallet alpha release: <a href=\"https:\/\/suredbits.com\/dlc-wallet-alpha-release\/\" target=\"_blank\" rel=\"noopener\">Suredbits\u2019 bitcoin-s<\/a> software includes a GUI and allows the execution of Discreet Log Contracts (DLCs) on the Bitcoin blockchain using an oracle. The announcement concludes by mentioning they also plan to use <a href=\"https:\/\/bitcoinops.org\/en\/topics\/schnorr-signatures\/\" target=\"_blank\" rel=\"noopener\">schnorr signatures<\/a> and <a href=\"https:\/\/bitcoinops.org\/en\/topics\/ptlc\/\" target=\"_blank\" rel=\"noopener\">Point Time Locked Contracts (PTLCs)<\/a> to implement <a href=\"https:\/\/suredbits.com\/discreet-log-contracts-on-lightning-network\/\" target=\"_blank\" rel=\"noopener\">DLCs compatible with LN<\/a>.<\/li>\n<li>Sparrow 1.4.3 supports P2TR: Sparrow\u2019s <a href=\"https:\/\/github.com\/sparrowwallet\/sparrow\/releases\/tag\/1.4.3\" target=\"_blank\" rel=\"noopener\">1.4.3 release<\/a> supports <a href=\"https:\/\/bitcoinops.org\/en\/preparing-for-taproot\/#from-p2wpkh-to-single-sig-p2tr\" target=\"_blank\" rel=\"noopener\">single-sig P2TR wallets<\/a> on <a href=\"https:\/\/bitcoinops.org\/en\/topics\/signet\/\" target=\"_blank\" rel=\"noopener\">signet<\/a> and regtest. The release also supports <a href=\"https:\/\/bitcoinops.org\/en\/preparing-for-taproot\/#bech32m-sending-support\" target=\"_blank\" rel=\"noopener\">sending to bech32m addresses for P2TR<\/a>.<\/li>\n<li>Coldcard Firmware adds Seed XOR feature: Coldcard\u2019s <a href=\"https:\/\/blog.coinkite.com\/version-4.1.0-released\/\" target=\"_blank\" rel=\"noopener\">4.1.0 Firmware<\/a> supports <a href=\"https:\/\/seedxor.com\/\" target=\"_blank\" rel=\"noopener\">Seed XOR<\/a>, a way to split\/combine <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0039.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP39<\/a> seeds in which each part can function as its own wallet. The combined, XOR\u2019d, parts also function as a wallet. This allows for features like honeypot funds and plausibly deniability.<\/li>\n<li>BlueWallet integrates Lightning Dev Kit: BlueWallet <a href=\"https:\/\/twitter.com\/bluewalletio\/status\/1414908931902779394\" target=\"_blank\" rel=\"noopener\">announced<\/a> a shift to a new Lightning implementation, now using <a href=\"https:\/\/github.com\/lightningdevkit\" target=\"_blank\" rel=\"noopener\">Lightning Dev Kit (LDK)<\/a>.<\/li>\n<\/ul>\n<h2>Preparing for taproot #5: why are we waiting?<\/h2>\n<p><em>A weekly <\/em><a href=\"https:\/\/bitcoinops.org\/en\/preparing-for-taproot\/\" target=\"_blank\" rel=\"noopener\"><em>series<\/em><\/a><em> about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.<\/em><\/p>\n<p>Earlier entries in this series saw us encouraging developers working on wallets and services to begin implementing <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> upgrades now so that they\u2019re ready when taproot activates. But we\u2019ve also warned against generating any addresses for P2TR before block 709,632 as this could cause your service or your users to lose money.<\/p>\n<p>The reason not to generate addresses in advance is that any payment to a P2TR-style output can be spent by <em>anyone<\/em> prior to block 709,632. The money would be completely unsecured. But starting with that block, thousands of full nodes will begin enforcing the rules of <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0341.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP341<\/a> and <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0342.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP342<\/a> (and, by association, <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0340.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP340<\/a>).<\/p>\n<p>If it was guaranteed that there wouldn\u2019t be a reorganization of the block chain, it would be safe to start generating addresses for P2TR as soon as the final pre-taproot block was seen (block 709,631). But there\u2019s reason to be concerned about block chain reorgs\u2014not just accidental reorgs but also those deliberately created to take money from early P2TR payments.<\/p>\n<p>Imagine a large number of people all wanting to be one of the first to receive a P2TR payment. They naively send themselves some money as soon as they see block 709,631.<a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/07\/21\/#fn:timelocked-trb\" target=\"_blank\" rel=\"noopener\">1<\/a> Those payments will be secure 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 sent to P2TR outputs is large enough, it could easily become more profitable to attempt to mine two blocks instead of just one (see our <a href=\"https:\/\/bitcoinops.org\/en\/topics\/fee-sniping\/\" target=\"_blank\" rel=\"noopener\">fee sniping<\/a> topic for more details).<\/p>\n<p>For this reason, we don\u2019t recommend your software or service generate addresses for P2TR until you think the reorg risk has been effectively eliminated. We think waiting 144 blocks (approximately one day) after activation is a reasonably conservative margin that minimizes risk without significantly delaying you or your users from taking advantage of the benefits of taproot.<\/p>\n<p>In short:<\/p>\n<ul>\n<li>709,631: last block where anyone can spend money sent to a P2TR-style output<\/li>\n<li>709,632: first block where P2TR outputs can only be spent if they satisfy the <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0341.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP341<\/a> and <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0342.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP342<\/a>rules.<\/li>\n<li>709,776: a reasonable block at which wallets can start giving their users <a href=\"https:\/\/bitcoinops.org\/en\/topics\/bech32\/\" target=\"_blank\" rel=\"noopener\">bech32m<\/a> receiving addresses for P2TR outputs<\/li>\n<\/ul>\n<p>None of the above changes the advice given in the <a href=\"https:\/\/bitcoinops.org\/en\/preparing-for-taproot\/#bech32m-sending-support\" target=\"_blank\" rel=\"noopener\">first part<\/a> of this series to enable paying to bech32m addresses as soon as possible. If someone requests payment to an address for P2TR before you think it\u2019s safe, that\u2019s their risk to take.<\/p>\n<h2>Releases and release candidates<\/h2>\n<p><em>New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/releases\/tag\/v0.13.1-beta\" target=\"_blank\" rel=\"noopener\">LND 0.13.1-beta<\/a> is a maintenance release with minor improvements and bug fixes for features introduced in 0.13.0-beta.<\/li>\n<li><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\/releases\/tag\/v0.0.99\" target=\"_blank\" rel=\"noopener\">Rust-Lightning 0.0.99<\/a> is a release with a few API and configuration changes. See its <a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\/blob\/main\/CHANGELOG.md#0099---2021-07-09\" target=\"_blank\" rel=\"noopener\">release notes<\/a>for details.<\/li>\n<li><a href=\"https:\/\/github.com\/ACINQ\/eclair\/releases\/tag\/v0.6.1\" target=\"_blank\" rel=\"noopener\">Eclair 0.6.1<\/a> is a new release with performance improvements, a few new features, and several bug fixes. In addition to its <a href=\"https:\/\/github.com\/ACINQ\/eclair\/releases\/tag\/v0.6.1\" target=\"_blank\" rel=\"noopener\">release notes<\/a>, see the descriptions of Eclair #1871 and #1846 in the notable changes section below.<\/li>\n<\/ul>\n<h2>Notable code and documentation changes<\/h2>\n<p><em>Notable changes this week in <\/em><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Core<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/ElementsProject\/lightning\" target=\"_blank\" rel=\"noopener\"><em>C-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/ACINQ\/eclair\" target=\"_blank\" rel=\"noopener\"><em>Eclair<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/\" target=\"_blank\" rel=\"noopener\"><em>LND<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\" target=\"_blank\" rel=\"noopener\"><em>Rust-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\" target=\"_blank\" rel=\"noopener\"><em>libsecp256k1<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\" target=\"_blank\" rel=\"noopener\"><em>Hardware Wallet Interface (HWI)<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\" target=\"_blank\" rel=\"noopener\"><em>Rust Bitcoin<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/\" target=\"_blank\" rel=\"noopener\"><em>BTCPay Server<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin\/bips\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Improvement Proposals (BIPs)<\/em><\/a><em>, and <\/em><a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/\" target=\"_blank\" rel=\"noopener\"><em>Lightning BOLTs<\/em><\/a><em>.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/22112\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #22112<\/a> changes the assumed port for <a href=\"https:\/\/geti2p.net\/en\/\" target=\"_blank\" rel=\"noopener\">I2P<\/a> addresses to be 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 <a href=\"https:\/\/geti2p.net\/en\/docs\/api\/samv3\" target=\"_blank\" rel=\"noopener\">SAM v3.1 specification<\/a> (which is supported by Bitcoin Core), does not include the concept of ports. This restriction may be lifted if Bitcoin Core is updated to support SAM v3.2, which does include the concept of ports.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4611\" target=\"_blank\" rel=\"noopener\">C-Lightning #4611<\/a> updates the plugin-provided keysend RPC to add a routehintsparameter which allows providing information for routing payments to <a href=\"https:\/\/bitcoinops.org\/en\/topics\/unannounced-channels\/\" target=\"_blank\" rel=\"noopener\">unannounced channels<\/a>.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4646\" target=\"_blank\" rel=\"noopener\">C-Lightning #4646<\/a> makes two changes in preparation for removing old behavior. The first change assumes nodes support the TLV-style encoding added in 2019 (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/07\/17\/#bolts-607\" target=\"_blank\" rel=\"noopener\">Newsletter #55<\/a>). Only nodes that explicitly indicate they don\u2019t support TLV encoding will be treated differently. The second change makes payment secrets required (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/12\/04\/#c-lightning-3259\" target=\"_blank\" rel=\"noopener\">Newsletter #75<\/a> for previous discussion and <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/12\/02\/#lnd-4752\" target=\"_blank\" rel=\"noopener\">Newsletter #126<\/a> for when LND began requiring it).<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4614\" target=\"_blank\" rel=\"noopener\">C-Lightning #4614<\/a> updates the listchannels RPC with a new optional destinationparameter that can be used to only return channels that lead to the requested node.<\/li>\n<li><a href=\"https:\/\/github.com\/ACINQ\/eclair\/issues\/1871\" target=\"_blank\" rel=\"noopener\">Eclair #1871<\/a> changes its SQLite settings to increase by 5x the number of <a href=\"https:\/\/bitcoinops.org\/en\/topics\/htlc\/\" target=\"_blank\" rel=\"noopener\">HTLCs<\/a> it can process per second and also increase its robustness against data loss. Referenced in the PR is a <a href=\"https:\/\/bottlepay.com\/blog\/bitcoin-lightning-node-performance\/\" target=\"_blank\" rel=\"noopener\">blog post<\/a>by Joost Jager comparing HTLC throughput in various node software.<\/li>\n<li><a href=\"https:\/\/github.com\/ACINQ\/eclair\/issues\/1846\" target=\"_blank\" rel=\"noopener\">Eclair #1846<\/a> adds opt-in support for using an upfront shutdown script\u2014an address the node specifies when negotiating a new channel that the remote peer agrees will be the only address it\u2019ll allow to be used in a later mutual close of the channel. See also <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/12\/11\/#lnd-3655\" target=\"_blank\" rel=\"noopener\">Newsletter #76<\/a> describing LND\u2019s implementation of this feature.<\/li>\n<li>Rust-Lightning #975 makes the base payment forwarding fee configurable with a default value of 1 satoshi (the market rate as of July 2021). LN routing nodes can charge two fees to route a payment, a fixed base fee or a percentage of the amount routed; many nodes use both. Previously, Rust-Lightning set the base fee to the estimated fee required to settle the HTLC on-chain, which was much higher than 1 sat.<\/li>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/issues\/2462\" target=\"_blank\" rel=\"noopener\">BTCPay Server #2462<\/a> makes it easier to use BTCPay to track payments made from a separate wallet, such as the case where the operator of an instance wants to pay a refund using their own personal wallet.<\/li>\n<\/ul>\n<h2>Footnotes<\/h2>\n<ul>\n<li>Users who want to receive a P2TR payment in the first taproot block should generate an address they don\u2019t share with anyone and then create a transaction to that address with nLockTime set to 709,631. That transaction can be broadcast as soon as block 709,631 has been received. The nLockTime will ensure the transaction can\u2019t be included into any block before 709,632, where taproot rules are enforced. Messing about with new script types and custom locktimes can be dangerous if you don\u2019t know what you\u2019re doing, so please take care. <\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/07\/21\/\" target=\"_blank\" rel=\"noopener\">original post here.<\/a> <\/p>\n<p>Please <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">subscribe to the Bitcoin Optech newsletter<\/a> directly to receive this content straight to your inbox every month.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week\u2019s newsletter discusses changes to services and client software and why wallets should wait before generating Taproot addresses.<\/p>\n","protected":false},"author":3246,"featured_media":10844,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[2887,1075,163],"class_list":["post-15559","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technical","tag-bitcoin-optech","tag-taproot","tag-wallets"],"author_data":{"id":3246,"name":"Bitcoin Optech","nicename":"bitcoin-optech","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/optech-notext-96x96.png"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/cybersecurity-firm-reports-all-fortune-500-companies-exposed-on-the-dark-web.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/15559","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/3246"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=15559"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/15559\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/10844"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=15559"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=15559"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=15559"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}