{"id":17545,"date":"2021-03-10T15:27:50","date_gmt":"2021-03-10T15:27:50","guid":{"rendered":"http:\/\/ci027dba06300027c4"},"modified":"2025-10-02T15:07:13","modified_gmt":"2025-10-02T20:07:13","slug":"bitcoin-optech-bitcoin-technical-updates-newsletter-139","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-bitcoin-technical-updates-newsletter-139","title":{"rendered":"Bitcoin Optech: Bitcoin Technical Updates Newsletter #139"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>The <a href=\"https:\/\/bitcoinops.org\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Optech <\/a>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 <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">to subscribe<\/a> to receive this content straight to your inbox.<\/em><\/p>\n<p>This week\u2019s newsletter summarizes continued discussion about proposed methods for activating taproot and links to an effort to document existing software building on top of taproot. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure projects.<\/p>\n<h2>News<\/h2>\n<ul>\n<li><strong>Taproot activation discussion:<\/strong> the previous weeks\u2019 discussions about activation saw different groups of people opposing either <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0008.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP8<\/a> <code>LockinOnTimeout=true<\/code> (<code>LOT=true<\/code>) or <code>LOT=false<\/code>, so most discussion on the mailing list this week focused on alternative activation mechanisms. Some proposals included:\n<ul>\n<li><em>User Activated Soft Fork (UASF):<\/em> a plan being <a href=\"http:\/\/gnusha.org\/uasf\/2021-03-02.log\" target=\"_blank\" rel=\"noopener\">discussed<\/a> to implement BIP8 <code>LOT=true<\/code> in a software fork of Bitcoin Core that mandates miners signal for activation of taproot by July 2022 (as widely proposed), but which also allows miners to activate it earlier.<\/li>\n<li><em>Flag day:<\/em> several proposals (<a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-February\/018495.html\" target=\"_blank\" rel=\"noopener\">1<\/a>, <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018538.html\" target=\"_blank\" rel=\"noopener\">2<\/a>) to program into nodes a specific block height or time roughly 18 months from now (as proposed) where taproot activates. Miner signaling is not required to cause activation and cannot cause earlier activation. Anthony Towns wrote a <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21378\" target=\"_blank\" rel=\"noopener\">draft implementation<\/a>.<\/li>\n<li><em>Decreasing threshold:<\/em> several proposals (<a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-February\/018476.html\" target=\"_blank\" rel=\"noopener\">1<\/a>, <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018587.html\" target=\"_blank\" rel=\"noopener\">2<\/a>) to gradually decrease over time the number of blocks that must signal readiness for miners to enforce taproot before the new consensus rules lock in. See also Anthony Town\u2019s proposal from last year described in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/07\/22\/#mailing-list-thread\" target=\"_blank\" rel=\"noopener\">Newsletter #107<\/a>.<\/li>\n<li><em>A configurable LOT:<\/em> in addition to previously-discussed proposals to make BIP8\u2019s <code>LOT<\/code> value a configuration option (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/02\/24\/#taproot-activation-discussion\" target=\"_blank\" rel=\"noopener\">Newsletter #137<\/a>), rough code was <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018514.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> showing how <code>LOT=true<\/code> could be enforced via an external script calling RPC commands. Additional code was <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018512.html\" target=\"_blank\" rel=\"noopener\">created<\/a> showing how <code>LOT=true<\/code> could also be opposed by node operators who were worried about it creating block chain instability.<\/li>\n<li><em>A short-duration attempt at miner activation:<\/em> an <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018583.html\" target=\"_blank\" rel=\"noopener\">updated proposal<\/a> to give miners approximately three months to lock in taproot, starting from soon after the release of a full node implementing the activation logic. If the attempt failed, the community would be encouraged to move on to a different activation method. If the attempt succeeded, there would still be a several month delay before taproot activated to allow most of the economy to upgrade their nodes. A <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21377\" target=\"_blank\" rel=\"noopener\">draft implementation<\/a> for this proposal based on Bitcoin Core\u2019s existing <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0009.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP9<\/a> implementation was also written by Anthony Towns. Andrew Chow created an <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21392\" target=\"_blank\" rel=\"noopener\">alternative draft implementation<\/a> based on the previously proposed BIP8 implementation.<\/li>\n<\/ul>\n<p>It seemed unlikely any of the proposals would ever become almost everyone\u2019s first choice, but it appeared that a large number of people were <a href=\"https:\/\/gist.github.com\/michaelfolkson\/92899f27f1ab30aa2ebee82314f8fe7f\" target=\"_blank\" rel=\"noopener\">willing to accept<\/a> the short-duration attempt under the name <em>Speedy Trial<\/em>. There were still a few concerns with it, including:<\/p>\n<ul>\n<li><em>Could be co-opted for mandatory activation:<\/em> even though the proposal explicitly encourages making other activation attempts if miners don\u2019t quickly signal sufficient support for taproot, a concern was <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018596.html\" target=\"_blank\" rel=\"noopener\">expressed<\/a> that it could be co-opted by a group of users seeking fast mandatory activation, although it was <a href=\"http:\/\/gnusha.org\/taproot-activation\/2021-03-06.log\" target=\"_blank\" rel=\"noopener\">noted<\/a> that no group has previously expressed the desire to attempt mandatory activation on such a dangerously short timeline.<\/li>\n<li><em>Using time-based or height-based parameters:<\/em> the proposal describes the tradeoffs between setting its <code>start<\/code>, <code>timeout<\/code>, and <code>minimum_activation<\/code> parameters using either times (based on the median of the previous 11 blocks) or block heights. Using times would result in the smallest and easiest to review patch to Bitcoin Core. Using heights would provide a bit more predictability, especially for miners, and would be compatible with other attempts using BIP8.<\/li>\n<li><em>Myopic:<\/em> there was <a href=\"https:\/\/twitter.com\/rusty_twit\/status\/1368325392591822848\" target=\"_blank\" rel=\"noopener\">concern<\/a> that the proposal is too focused on the short term: \u201cSpeedy Trial fully prepares for the (likely) case where miners activate taproot, but it does nothing to codify lessons learned from Segwit\u2019s failure to activate in a timely manner. We have an opportunity with the activation of taproot to create a template for future activations that will clearly define the roles and responsibilities for developers, miners, merchants, investors, and end users in all the ways an activation can progress, not just the best-case outcomes; in particular enabling and enshrining the final arbiter role held by Bitcoin\u2019s economic users. Defining this will only get more difficult in the future, both because we\u2019ll only do so when we\u2019re already in crisis, and because Bitcoin\u2019s growth means future agreement will need to be done at greater scale and so with greater difficulty.\u201d<\/li>\n<li><em>Speed:<\/em> the proposal, based on initial discussion from the ##taproot-activation IRC channel, proposes giving miners about three months to lock in taproot and waiting a fixed six months from the start of signal measuring before activation (if lock in is achieved). Some people have sought either slightly shorter or slightly longer timelines.<\/li>\n<\/ul>\n<p>We\u2019ll continue tracking the discussion around the various proposals and will summarize any significant progress in future newsletters.<\/li>\n<li><strong>Documenting the intention to use and build upon taproot:<\/strong> In discussion about activation methods, Chris Belcher <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018538.html\" target=\"_blank\" rel=\"noopener\">noted<\/a> that a large list of software was compiled whose developers stated their intention to implement segwit during the debate around activating that soft fork. He suggested that a similar list could be created to document for posterity the amount of support taproot has. That way it could be clear that taproot was desired by a large segment of the economy no matter how it ends up being activated.Jeremy Rubin <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018604.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> to the Bitcoin-Dev mailing list a link to a somewhat related <a href=\"https:\/\/en.bitcoin.it\/wiki\/Taproot_Uses\" target=\"_blank\" rel=\"noopener\">wiki page<\/a> where developers can post links to projects they\u2019re building on top of taproot\u2019s new proposed features. This can provide assurance that taproot provides solutions people actually want and is designed in such a way that its features will get used.<\/li>\n<\/ul>\n<h2>Bitcoin Core PR Review Club<\/h2>\n<p><em>In this monthly section, we summarize a recent <a href=\"https:\/\/bitcoincore.reviews\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Core PR Review Club<\/a> 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\/18261\" target=\"_blank\" rel=\"noopener\">Erlay: bandwidth-efficient transaction relay protocol<\/a> is a PR (<a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/18261\" target=\"_blank\" rel=\"noopener\">#18261<\/a>) by Gleb Naumenko that proposes to implement <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0330.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP330<\/a> in Bitcoin Core.<\/p>\n<p>The review club discussion focused on the tradeoffs, implementation and potential new attack vectors involved with <a href=\"https:\/\/bitcoinops.org\/en\/topics\/erlay\/\" target=\"_blank\" rel=\"noopener\">Erlay<\/a>. In subsequent meetings, the review club discussed <a href=\"https:\/\/bitcoinops.org\/en\/topics\/minisketch\/\" target=\"_blank\" rel=\"noopener\">Minisketch<\/a>, a <a href=\"https:\/\/github.com\/sipa\/minisketch\" target=\"_blank\" rel=\"noopener\">library<\/a> implementing the PinSketch <em>set reconciliation<\/em> algorithm that is the basis for the efficient relay protocol in Erlay.<\/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\/ACINQ\/eclair\/releases\/tag\/v0.5.1\" target=\"_blank\" rel=\"noopener\">Eclair 0.5.1<\/a> is the latest release of this LN node, containing improvements to startup speed, reduced bandwidth consumption when syncing the network graph, and a series of small improvements in preparation for supporting <a href=\"https:\/\/bitcoinops.org\/en\/topics\/anchor-outputs\/\" target=\"_blank\" rel=\"noopener\">anchor oututs<\/a>.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/releases\/tag\/2.0.0-rc.2\" target=\"_blank\" rel=\"noopener\">HWI 2.0.0RC2<\/a> is a release candidate for the next major version of HWI.<\/li>\n<\/ul>\n<h2>Notable code and documentation changes<\/h2>\n<p><em>Notable changes this week in <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\" target=\"_blank\" rel=\"noopener\">Bitcoin Core<\/a>, <a href=\"https:\/\/github.com\/ElementsProject\/lightning\" target=\"_blank\" rel=\"noopener\">C-Lightning<\/a>, <a href=\"https:\/\/github.com\/ACINQ\/eclair\" target=\"_blank\" rel=\"noopener\">Eclair<\/a>, <a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/\" target=\"_blank\" rel=\"noopener\">LND<\/a>, <a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\" target=\"_blank\" rel=\"noopener\">Rust-Lightning<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\" target=\"_blank\" rel=\"noopener\">libsecp256k1<\/a>, <a href=\"https:\/\/github.com\/bitcoin-core\/HWI\" target=\"_blank\" rel=\"noopener\">Hardware Wallet Interface (HWI)<\/a>, <a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\" target=\"_blank\" rel=\"noopener\">Rust Bitcoin<\/a>, <a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/\" target=\"_blank\" rel=\"noopener\">BTCPay Server<\/a>, <a href=\"https:\/\/github.com\/bitcoin\/bips\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Improvement Proposals (BIPs)<\/a>, and <a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/\" target=\"_blank\" rel=\"noopener\">Lightning BOLTs<\/a>.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/20685\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #20685<\/a> Adds I2P support by using the <a href=\"https:\/\/geti2p.net\/en\/docs\/api\/samv3\" target=\"_blank\" rel=\"noopener\">I2P SAM protocol<\/a>. This feature has <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/2091\" target=\"_blank\" rel=\"noopener\">long been requested<\/a> and was only recently made possible by the addition of <a href=\"https:\/\/bitcoinops.org\/en\/topics\/addr-v2\/\" target=\"_blank\" rel=\"noopener\">addr v2<\/a> Though documentation for node operators hoping to run I2P is still being created, a <a href=\"https:\/\/bitcoin.stackexchange.com\/questions\/103402\/how-can-i-use-bitcoin-core-with-the-anonymous-network-protocol-i2p\" target=\"_blank\" rel=\"noopener\">Bitcoin StackExchange Q&amp;A<\/a> provides hints on getting started.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4407\" target=\"_blank\" rel=\"noopener\">C-Lightning #4407<\/a> updates the <code>listpeers<\/code> RPC with new fields that provide information about each channel\u2019s current unilateral close transaction, including its fee (both in total fee terms and as a feerate).<\/li>\n<li>Rust-Lightning #646 adds the ability to find multiple paths for a payment so that it will be possible to add <a href=\"https:\/\/bitcoinops.org\/en\/topics\/multipath-payments\/\" target=\"_blank\" rel=\"noopener\">multipath payment<\/a> support.<\/li>\n<li>BOLTs #839 adds funding transaction timeout recommendations to save funding fees when there\u2019s a failure to confirm funding transactions, providing stronger guarantees for the channel funder and fundee. The new recommendations suggest that the funder commits to ensuring the funding transaction confirms in 2016 blocks and recommends that the fundee forget the pending channel if the funding transaction not confirm within those 2016 blocks.<\/li>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/issues\/2181\" target=\"_blank\" rel=\"noopener\">BTCPay Server #2181<\/a> uppercases bech32 addresses when presenting <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0021.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP21<\/a> URIs as QR codes. This results in <a href=\"https:\/\/bitcoinops.org\/en\/bech32-sending-support\/#creating-more-efficient-qr-codes-with-bech32-addresses\" target=\"_blank\" rel=\"noopener\">less dense QR codes<\/a> as uppercase substrings can be encoded more efficiently. The change was preceded by an extensive <a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/issues\/2110\" target=\"_blank\" rel=\"noopener\">compatibility survey<\/a> of wallets with the BIP21 URI scheme.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>This issue of Bitcoin Optech covers Taproot activation discussion, the release of Eclair 0.5.1 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":[2887],"class_list":{"0":"post-17545","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-optech"},"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\/17545","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=17545"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/17545\/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=17545"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=17545"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=17545"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}