{"id":16520,"date":"2021-05-12T17:11:53","date_gmt":"2021-05-12T17:11:53","guid":{"rendered":"http:\/\/ci0282eab970002568"},"modified":"2025-10-02T10:21:54","modified_gmt":"2025-10-02T15:21:54","slug":"bitcoin-optech-security-disclosure","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-security-disclosure","title":{"rendered":"Bitcoin Optech #148: A Security Disclosure Affecting Protocols"},"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 security disclosure affecting protocols depending on a certain BIP125 opt-in replace by fee behavior and includes our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.<\/p>\n<h2>News<\/h2>\n<ul>\n<li>CVE-2021-31876 discrepancy between BIP125 and Bitcoin Core implementation: the <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0125.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP125<\/a> specification of opt-in Replace By Fee (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/replace-by-fee\/\" target=\"_blank\" rel=\"noopener\">RBF<\/a>) says that an unconfirmed parent transaction that signals replaceability makes any child transactions that spend the parent\u2019s outputs also replaceable through inferred inheritance. This week, Antoine Riard <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-May\/018893.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> to the Bitcoin-Dev mailing list the full disclosure of his previously privately reported finding that Bitcoin Core does not implement this behavior. It is still possible for child transactions to be replaced if they explicitly signal replaceability or for them to be evicted from the mempool if their parent transaction is replaced.<br \/>Riard analyzed how the inability to use inherited replaceability might affect various current and proposed protocols. Only LN appears to be affected and only in the sense that an existing attack (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/04\/29\/#new-attack-against-ln-payment-atomicity\" target=\"_blank\" rel=\"noopener\">Newsletter #95<\/a>) that uses <a href=\"https:\/\/bitcoinops.org\/en\/topics\/transaction-pinning\/\" target=\"_blank\" rel=\"noopener\">pinning<\/a> becomes cheaper. The ongoing deployment of <a href=\"https:\/\/bitcoinops.org\/en\/topics\/anchor-outputs\/\" target=\"_blank\" rel=\"noopener\">anchor outputs<\/a> by various LN implementations will eliminate the ability to perform that pinning.<br \/>As of this writing, there has not been any substantial discussion of the issue on the mailing list.<\/li>\n<li>Call for Brink grant applications: Bitcoin Optech encourages any engineer contributing to open source Bitcoin or Lightning projects to apply for a Brink grant before the application deadline on May 17th. Initial grants are one year long and allow developers to work full time on open source projects from anywhere in the world.<\/li>\n<\/ul>\n<h2>Bitcoin Core PR Review Club<\/h2>\n<p><em>In this monthly section, we summarize a recent <\/em><a href=\"https:\/\/bitcoincore.reviews\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Core PR Review Club<\/em><\/a><em> meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.<\/em><\/p>\n<p><a href=\"https:\/\/bitcoincore.reviews\/21061\" target=\"_blank\" rel=\"noopener\">Introduce node rebroadcast module<\/a> is a PR (<a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21061\" target=\"_blank\" rel=\"noopener\">#21061<\/a>) by Amiti Uttarwar that continues work on the rebroadcast project (see Newsletters <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/09\/18\/#bitcoin-core-rebroadcasting-logic\" target=\"_blank\" rel=\"noopener\">#64<\/a>, <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/05\/06\/#bitcoin-core-18038\" target=\"_blank\" rel=\"noopener\">#96<\/a>, <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/12\/23\/#transaction-origin-privacy\" target=\"_blank\" rel=\"noopener\">#129<\/a> and <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/03\/31\/#will-nodes-with-a-larger-than-default-mempool-retransmit-transactions-that-have-been-dropped-from-smaller-mempools\" target=\"_blank\" rel=\"noopener\">#142<\/a>), previously discussed in review clubs <a href=\"https:\/\/bitcoincore.reviews\/16698\" target=\"_blank\" rel=\"noopener\">#16698<\/a> and <a href=\"https:\/\/bitcoincore.reviews\/18038\" target=\"_blank\" rel=\"noopener\">#18038<\/a>, whose goal is to make node rebroadcast behavior for wallet transactions indistinguishable from that of other peers\u2019 transactions.<\/p>\n<p>The review club discussion focused on current transaction behavior and the proposed changes:<\/p>\n<ul>\n<li>Why might we want to rebroadcast a transaction? When our transaction didn\u2019t propagate (perhaps our node was offline) or appears to have been dropped by other nodes\u2019 mempools in the network.\n<\/li>\n<li>Why does a node drop a transaction from its mempool? Apart from being included in a block, a transaction can expire after 14 days, be squeezed out of a node\u2019s limited mempool size (default size 300 MiB) by higher-fee transactions, be replaced via <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0125.mediawiki\" target=\"_blank\" rel=\"noopener\"><em>BIP125<\/em><\/a> opt-in Replace-By-Fee (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/replace-by-fee\/\" target=\"_blank\" rel=\"noopener\"><em>RBF<\/em><\/a>), be removed if a conflicting transaction is included in a block, or be included in a block that is later reorged out (in which case the node will try to re-add it while <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/blob\/e175a20769\/src\/validation.cpp#L357\" target=\"_blank\" rel=\"noopener\"><em>updating the mempool<\/em><\/a> to be consistent again after the reorg).\n<\/li>\n<li>What could be an issue with the current behavior of each wallet being responsible for rebroadcasting its own transactions? <br \/>This can be a privacy leak that allows linking the IP address to the wallet address, as under the current rebroadcasting behavior, a node that broadcasts a transaction more than once is essentially announcing that the transaction is from its wallet.\n<\/li>\n<li>When might a miner exclude a transaction that is in our mempool? When the miner deprioritized it for having a low fee, didn\u2019t see it yet, removed it from its mempool by RBF, censored it, or mined an empty block.\n<\/li>\n<li>When might a miner include a transaction that is not in our mempool? When the miner manually prioritized the transaction (e.g. as a commercial service), received it before our node, or the transaction conflicted with another one in our mempool but not in theirs.\n<\/li>\n<li>How would the proposal under review decide which transactions to rebroadcast?<br \/>Once per new block, it proposes to rebroadcast transactions above an estimated feerate that are at least 30 minutes old, have been rebroadcast no more than 6 times and not more recently than 4 hours ago, with up to 3\/4 of the transactions that fit the block.\n<\/li>\n<li>Why might we want to keep a transaction in our rebroadcast attempt tracker even after it has been removed from our mempool? <br \/>After a consensus rule change, there can be non-updated nodes on the network rebroadcasting transactions that don\u2019t meet the new consensus rules. Keeping transactions in the rebroadcast attempt tracker would avoid these nodes rebroadcasting them too many times (a maximum of 6 times over 90 days) and allow the transactions to expire.\n<\/li>\n<li>When would we remove a transaction from our rebroadcast attempt tracker? When the transaction is confirmed, <a href=\"https:\/\/bitcoinops.org\/en\/topics\/replace-by-fee\/\" target=\"_blank\" rel=\"noopener\"><em>RBFed<\/em><\/a>, or conflicts with another transaction included in a block.\n<\/li>\n<li>How would the estimated minimum feerate for rebroadcast be calculated? Why not use the lowest feerate in the last mined block? <br \/>The rebroadcast feerate floor would be estimated once a minute by assembling a block from the mempool to simulate inclusion in the next mined block. This approach is better than using the lowest feerate of the last mined block because it calculates fees based on the immediate future in a changing environment instead of based on the past.<\/li>\n<\/ul>\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\/rust-bitcoin\/rust-lightning\/releases\/tag\/v0.0.14\" target=\"_blank\" rel=\"noopener\">Rust-Lightning 0.0.14<\/a> is a new release that makes Rust Lightning more compatible with getting data from Electrum-style servers, adds additional configuration options, and improves compliance with the LN specification, among other bug fixes and improvements.<\/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\/20867\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #20867<\/a> increases the number of keys that can be included in multisig <a href=\"https:\/\/bitcoinops.org\/en\/topics\/output-script-descriptors\/\" target=\"_blank\" rel=\"noopener\">descriptors<\/a> and used in the addmultisigaddress and createmultisig RPCs from 16 to 20. The increased limit can only be used in P2WSH outputs. P2SH outputs are limited to 520 byte scripts which are only large enough to hold 15 compressed public keys.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin-core\/gui\/issues\/125\" target=\"_blank\" rel=\"noopener\">Bitcoin Core GUI #125<\/a> enables users to adjust the autoprune block space size from the default in the intro dialog. It also adds an improved description for how the pruned storage works, clarifying that the entire blockchain must be downloaded and processed but will be discarded in the future to keep disk usage low.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4489\" target=\"_blank\" rel=\"noopener\">C-Lightning #4489<\/a> adds a funder plugin for configuring <a href=\"https:\/\/bitcoinops.org\/en\/topics\/dual-funding\/\" target=\"_blank\" rel=\"noopener\">dual-funding<\/a> contribution behavior in response to incoming channel open requests. Users will be able to specify a general contribution policy (percent match, percent available funds, or fixed contribution), a wallet reserve amount under which no dual-funding contributions will happen, a maximum contribution amount for any single channel open request, and more.<br \/>This PR represents the last step in enabling experimental dual-funding support between C-Lightning nodes. The interactive transaction construction and channel establishment v2 protocols arising out of this work is still being standardized in the open BOLTs #851 PR.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4496\" target=\"_blank\" rel=\"noopener\">C-Lightning #4496<\/a> adds the ability for plugins to register topics about which they plan to publish notifications. Other plugins can subscribe to those topics to receive notifications. C-Lightning already had several built-in topics, but this merged PR allows plugin authors to create and consume notifications for any new topic category they\u2019d like to use.<\/li>\n<li><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\/issues\/589\" target=\"_blank\" rel=\"noopener\">Rust Bitcoin #589<\/a> starts the process of implementing support for <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> with <a href=\"https:\/\/bitcoinops.org\/en\/topics\/schnorr-signatures\/\" target=\"_blank\" rel=\"noopener\">schnorr signatures<\/a>. The existing ECDSA support is moved to a new module but continues to be exported under existing names to preserve API compatibility. A new util::schnorr module adds support for <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0340.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP340<\/a> schnorr key encodings. Issue <a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\/issues\/588\" target=\"_blank\" rel=\"noopener\">#588<\/a> is being used to track the complete implementation of taproot compatibility.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/05\/12\/\" 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 covers a security disclosure, a summary of a Bitcoin Core PR Review Club meeting and more.<\/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":[227,2887,1821,330],"class_list":["post-16520","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technical","tag-bitcoin-core","tag-bitcoin-optech","tag-replace-by-fee","tag-security"],"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\/16520","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=16520"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/16520\/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=16520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=16520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=16520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}