{"id":15958,"date":"2021-06-23T19:47:57","date_gmt":"2021-06-23T19:47:57","guid":{"rendered":"http:\/\/ci0286612570002548"},"modified":"2025-10-02T09:40:26","modified_gmt":"2025-10-02T14:40:26","slug":"bitcoin-optech-universal-transactions","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-universal-transactions","title":{"rendered":"Bitcoin Optech #154: Universal Transaction RBF And Taproot"},"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 a proposal to allow universal transaction replacement by fee and includes the first post in a new weekly series about preparing for taproot. Also included are our regular sections describing updates to clients and services, new releases and release candidates, and notable changes to popular Bitcoin infrastructure projects.<\/p>\n<h2>News<\/h2>\n<ul>\n<li>Allowing transaction replacement by default: almost all Bitcoin full nodes today are believed to implement <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0125.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP125<\/a> opt-in Replace By Fee (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/replace-by-fee\/\" target=\"_blank\" rel=\"noopener\">RBF<\/a>), which allows unconfirmed transactions to be replaced in node mempools by alternative versions that pay higher fees\u2014but only if the creator of the transaction sets a signal in the original transaction. This opt-in behavior was proposed as a compromise between people who wanted to allow transaction replacement, such as for fee bumping or <a href=\"https:\/\/bitcoinops.org\/en\/cardcoins-rbf-batching\/\" target=\"_blank\" rel=\"noopener\">additive payment batching<\/a>, and people who objected because allowing replacement simplifies building tools that defraud merchants who accept unconfirmed transactions as final.<br \/>Over five years later, it appears very few merchants today are accepting unconfirmed transactions as final, and it\u2019s not clear how many of those that do are actually checking for the BIP125 opt-in signal and treating those transactions differently. If no one is relying on BIP125 signals, then allowing every transaction to be replaceable could provide some advantages, such as:<\/li>\n<ul>\n<li>Simplifying analysis for presigned transaction protocols (such as LN and <a href=\"https:\/\/bitcoinops.org\/en\/topics\/vaults\/\" target=\"_blank\" rel=\"noopener\">vaults<\/a>) where ideas for using RBF fee bumping need to account for a malicious counterparty\u2019s ability to prevent setting the BIP125 signal. If every transaction could be replaced, this wouldn\u2019t be a concern.<\/li>\n<li>Reducing transaction analysis opportunity because transactions that opt in to RBF look different onchain than transactions which don\u2019t. Since most wallets consistently opt in, or not, this provides evidence that surveillance companies can use in their attempts to identify who owns which bitcoins. If every transaction was replaceable, there\u2019d be no need to set the BIP125 signal.<\/li>\n<\/ul>\n<li>This week, Antoine Riard <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-June\/019074.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> a proposal to the Bitcoin-Dev mailing list for eventually changing Bitcoin Core\u2019s code to allow RBF for all transactions regardless of whether or not they set the BIP125 opt-in signal. The idea was also discussed in the first transaction relay workshop <a href=\"https:\/\/gist.githubusercontent.com\/ariard\/5f28dffe82ddad763b346a2344092ba4\/raw\/2a8e0d4ff431a225a970d0128aa78616df6b6382\/meeting-logs\" target=\"_blank\" rel=\"noopener\">meeting<\/a>. Several meeting participants mentioned Bitcoin Core <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/10823\" target=\"_blank\" rel=\"noopener\">PR #10823<\/a> as an alternative approach\u2014it allows any transaction to be replaced, but only after the transaction had spent a certain amount of time in a node mempool (originally proposed as 6 hours; later suggested to be 72 hours).<br \/>Both Riard\u2019s email and the meeting participants note that any proposal for replacing transactions that don\u2019t contain a BIP125 opt-in signal requires feedback from merchants currently depending on BIP125 behavior. Optech encourages any such merchants to respond to the mailing list thread.<\/li>\n<\/ul>\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>Trezor Suite adds RBF support: Trezor\u2019s wallet software, Trezor Suite, added <a href=\"https:\/\/wiki.trezor.io\/Replace-by-fee_(RBF)\" target=\"_blank\" rel=\"noopener\">support for Replace-by-Fee (RBF)<\/a> in version 21.2.2. RBF is on by default and also supported by some of Trezor\u2019s hardware devices.<\/li>\n<li>Lightning Labs announces Terminal Web: In a recent <a href=\"https:\/\/lightning.engineering\/posts\/2021-05-11-terminal-web\/\" target=\"_blank\" rel=\"noopener\">blog post<\/a>, Lightning Labs describes their web-based Lightning node scoring dashboard, <a href=\"https:\/\/terminal.lightning.engineering\/\" target=\"_blank\" rel=\"noopener\">Terminal Web<\/a>.<\/li>\n<li>Specter v1.4.0 released: <a href=\"https:\/\/github.com\/cryptoadvance\/specter-desktop\/releases\/tag\/v1.4.0\" target=\"_blank\" rel=\"noopener\">Specter v.1.4.0<\/a> adds a feature to <a href=\"https:\/\/github.com\/cryptoadvance\/specter-desktop\/pull\/1197\" target=\"_blank\" rel=\"noopener\">\u201ccancel\u201d a transaction<\/a> using BIP125 opt-in <a href=\"https:\/\/bitcoinops.org\/en\/topics\/replace-by-fee\/\" target=\"_blank\" rel=\"noopener\">Replace-by-Fee (RBF)<\/a>.<\/li>\n<li>Phoenix adds LNURL-pay: ACINQ\u2019s mobile wallet <a href=\"https:\/\/phoenix.acinq.co\/\" target=\"_blank\" rel=\"noopener\">Phoenix<\/a> added support for the <a href=\"https:\/\/github.com\/fiatjaf\/lnurl-rfc\/blob\/master\/lnurl-pay.md\" target=\"_blank\" rel=\"noopener\">LNURL-pay<\/a> protocol in its v1.4.12 release.<\/li>\n<li>JoinMarket v0.8.3 released: <a href=\"https:\/\/github.com\/JoinMarket-Org\/joinmarket-clientserver\/releases\/tag\/v0.8.3\" target=\"_blank\" rel=\"noopener\">JoinMarket v0.8.3<\/a> adds the ability to provide custom change addresses and an Electrum-compatible segwit signmessage implementation.<\/li>\n<\/ul>\n<h2>Preparing for taproot #1: bech32 sending support<\/h2>\n<p><em>The first segment in a weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.<\/em><\/p>\n<p>Starting at block 709,632, expected in November, Bitcoin users will be able to safely receive payments to taproot addresses. Given the user enthusiasm for taproot and the five months that wallet developers have to implement support for it, Optech expects there to be several popular wallets that will allow their users to generate taproot addresses at the earliest possible moment.<\/p>\n<p>That means any other wallet or service that sends bitcoins to user-provided addresses needs to be able to send to taproot addresses by block 709,632 or risk confusing and disappointing its users. Pay to TapRoot (P2TR) addresses use <a href=\"https:\/\/bitcoinops.org\/en\/topics\/bech32\/\" target=\"_blank\" rel=\"noopener\">bech32m<\/a> as specified in <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0350.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP350<\/a>, which is slightly different than <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0173.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP173<\/a>\u2019s bech32 algorithm used for segwit v0 P2WPKH and P2WSH addresses. Bech32m uses the constant 0x2bc830a3 instead of bech32\u2019s 0x01 in the checksum function.<\/p>\n<p>Changing that single constant provides the ability to verify bech32m checksums, but the code still needs to use the original constant for existing P2WPKH and P2WSH addresses. The code needs to decode the address without verifying the checksum, determine whether it uses v0 segwit (bech32) or v1+ segwit (bech32m), and then validate the checksum with the appropriate constant. For examples, see the <a href=\"https:\/\/github.com\/sipa\/bech32\/pull\/56\" target=\"_blank\" rel=\"noopener\">PR<\/a> that updated the bech32 reference implementations for C, C++, JS, and Python. If the code already uses the reference libraries, they can be updated to the latest code from that repository, although note that some of the APIs have slight changes. BIP350 and the reference implementations provide test vectors that all bech32m implementations should use.<\/p>\n<p>Although <em>receiving<\/em> payments to taproot addresses won\u2019t be safe until block 709,632, <em>sending<\/em> payments should not cause any problems for the sender. Bitcoin Core has supported relaying and mining transactions with taproot-paying outputs since version 0.19 (released November 2019). Optech encourages developers of wallets and services to implement support for paying bech32m taproot addresses now rather than waiting until after taproot activates.<\/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.0-beta.rc5\" target=\"_blank\" rel=\"noopener\">LND 0.13.0-beta<\/a> is a new major release that improves feerate management by making <a href=\"https:\/\/bitcoinops.org\/en\/topics\/anchor-outputs\/\" target=\"_blank\" rel=\"noopener\">anchor outputs<\/a> the default commitment transaction format, adds support for using a pruned Bitcoin full node, allows receiving and sending payments using Atomic MultiPath (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/multipath-payments\/\" target=\"_blank\" rel=\"noopener\">AMP<\/a>), and increases LND\u2019s <a href=\"https:\/\/bitcoinops.org\/en\/topics\/psbt\/\" target=\"_blank\" rel=\"noopener\">PSBT<\/a> capabilities, among many other improvements and bug fixes.<\/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\/21365\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21365<\/a> adds the ability for the wallet to create signatures for <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> spends\u2014both keypath spends using only the P2TR public key and scriptpath spends using a <a href=\"https:\/\/bitcoinops.org\/en\/topics\/tapscript\/\" target=\"_blank\" rel=\"noopener\">tapscript<\/a>. The wallet can also sign for taproot-spending <a href=\"https:\/\/bitcoinops.org\/en\/topics\/psbt\/\" target=\"_blank\" rel=\"noopener\">PSBTs<\/a>, but only if the wallet already has all the keypath or scriptpath information it needs. The somewhat related merged PR <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/22156\" target=\"_blank\" rel=\"noopener\">#22156<\/a> only allows importing that keypath and scriptpath information after taproot is active (block 709,632 on mainnet, but on test networks where taproot is already enabled, importing may be used now).<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/22144\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #22144<\/a> randomizes the order in which peers are serviced in the message handling thread, which is responsible for parsing and processing P2P messages from peers and for sending messages to those peers. Previously, the message handling thread would service each peer round-robin in the order in which the connections to those peers were first established. This PR changes the logic so that, on each iteration of the message handling loop, the order in which peers are serviced is randomized. Peers are still serviced with the same frequency (each peer is serviced once per iteration), but any weaknesses or exploits that rely on a deterministic ordering of servicing peers are avoided.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21261\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21261<\/a> makes it easier to extend inbound connection protection to more networks and then uses that framework to add <a href=\"https:\/\/en.wikipedia.org\/wiki\/I2P\" target=\"_blank\" rel=\"noopener\">I2P<\/a> to the list of protected networks. Diversity protection (often called eviction protection) allows a few peers with desirable characteristics to remain connected when Bitcoin Core is otherwise pruning high-latency connections. Retaining a few connections to peers on anonymity networks is highly desirable both because it allows transaction creators to use those networks to hide their network identity and because the ability to receive blocks over those networks in addition to the regular Internet Protocol can prevent some types of <a href=\"https:\/\/bitcoinops.org\/en\/topics\/eclipse-attacks\/\" target=\"_blank\" rel=\"noopener\">eclipse attacks<\/a>.<\/li>\n<li><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\/issues\/601\" target=\"_blank\" rel=\"noopener\">Rust Bitcoin #601<\/a> adds support for parsing <a href=\"https:\/\/bitcoinops.org\/en\/topics\/bech32\/\" target=\"_blank\" rel=\"noopener\">bech32m<\/a> addresses and requires that v1+ native segwit addresses be encoded with bech32m and not bech32.<\/li>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/issues\/2450\" target=\"_blank\" rel=\"noopener\">BTCPay Server #2450<\/a> makes generating <a href=\"https:\/\/bitcoinops.org\/en\/topics\/payjoin\/\" target=\"_blank\" rel=\"noopener\">payjoin<\/a>-compatible invoices the default when the user opts into using a hot wallet for receiving payments. A button on the create wallet screen allows the user to opt out of this default setting.<\/li>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/issues\/2559\" target=\"_blank\" rel=\"noopener\">BTCPay Server #2559<\/a> adds a separate screen for guiding the user through their choices for how to sign transactions they spend from their wallet. For hot wallets, the server can just sign, but for wallets where the keys are stored elsewhere, an attractive and informative GUI now guides the user through signing options such as entering their recovery mnemonic, using a hardware signing device, or generating a PSBT for transfer to a signing wallet.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/06\/23\/\" 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 universal transaction replacement by fee, and includes the first post in a Taproot preparation series.<\/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,881,1075],"class_list":["post-15958","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technical","tag-bitcoin-optech","tag-rbf","tag-taproot"],"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\/15958","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=15958"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/15958\/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=15958"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=15958"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=15958"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}