{"id":16907,"date":"2021-04-21T15:44:58","date_gmt":"2021-04-21T15:44:58","guid":{"rendered":"http:\/\/ci0281302b80002496"},"modified":"2025-10-02T15:04:44","modified_gmt":"2025-10-02T20:04:44","slug":"bitcoin-optech-newsletter-145","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-newsletter-145","title":{"rendered":"Bitcoin Optech #145: Lightning Network Offers, Taproot And More"},"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 progress on activating taproot, summarizes an update to LN offers to partly address stuck payments, relays a request for feedback on anchor outputs in LND, and announces the public launch of the Sapio smart contract development toolkit. Also included are our regular sections with summaries of changes to popular clients and services, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.<\/p>\n<h2>News<\/h2>\n<ul>\n<li>Taproot activation release candidate: since our update on <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> activation in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/04\/14\/#taproot-activation-discussion\" target=\"_blank\" rel=\"noopener\">last week\u2019s newsletter<\/a>, the Bitcoin Core Project has merged a <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21377\" target=\"_blank\" rel=\"noopener\">pull request<\/a> implementing the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/03\/10\/#a-short-duration-attempt-at-miner-activation\" target=\"_blank\" rel=\"noopener\">Speedy Trial<\/a> activation mechanism and a <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21686\" target=\"_blank\" rel=\"noopener\">second PR<\/a> containing the activation parameters. These PRs and a few others are currently part of the first Release Candidate (RC) for Bitcoin Core 0.21.1. Testing and other quality assurance tasks are expected to continue for at least several days after the publication of this newsletter. See the RC and merge summary sections below for more details.<\/li>\n<li>Using LN offers to partly address stuck payments: in some cases, an attempt to pay an LN invoice can result in the payment becoming stuck for an extended period of time. Until the failure is resolved, requesting a second invoice to make a second payment attempt can result in paying twice.<br \/>This week, Rusty Russell <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2021-April\/002992.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> to the Lightning-Dev mailing list a change to his proposed <a href=\"https:\/\/bitcoinops.org\/en\/topics\/offers\/\" target=\"_blank\" rel=\"noopener\">offers<\/a> specification that allows the receiver of a payment to commit to a new invoice which supplants the previous invoice. If the spender pays the second invoice, there\u2019s still a risk that they will pay twice, but the receiver\u2019s signature on the offer combined with LN\u2019s inherent proof of payment will allow the spender to prove the receiver acted deceitfully if both payments were accepted. When paying a receiver with an established reputation, such as a popular business, that may be enough to eliminate stuck payments as a major problem.<br \/>The update to the offers specification also allows the receiver to indicate that they received the payment and the problem is with a downstream node. In that case, the funds for both the spender and the receiver are fully secure and the only consequence is that the spender will need to wait a while before they can reuse that particular one of their payment slots (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/htlc\/\" target=\"_blank\" rel=\"noopener\">HTLC<\/a> slots). This ability to communicate interactively is a clear advantage of offers over plain invoices.<\/li>\n<li>Using anchor outputs by default in LND: Olaoluwa Osuntokun <a href=\"https:\/\/groups.google.com\/a\/lightning.engineering\/g\/lnd\/c\/OuC56qq6IaY\" target=\"_blank\" rel=\"noopener\">posted<\/a> to the LND engineering mailing list about his desire for the next major version of LND to use <a href=\"https:\/\/bitcoinops.org\/en\/topics\/anchor-outputs\/\" target=\"_blank\" rel=\"noopener\">anchor outputs<\/a> by default. Anchor outputs will allow unconfirmed LN commitment transactions that close a channel to be <a href=\"https:\/\/bitcoinops.org\/en\/topics\/cpfp\/\" target=\"_blank\" rel=\"noopener\">CPFP<\/a> fee bumped. Unfortunately, there are some challenges with CPFP fee bumping in the LN model:<\/li>\n<ul>\n<li>Not always optional: for regular onchain transactions, many users can just wait longer for their transaction to confirm as an alternative to fee bumping. For LN, sometimes waiting isn\u2019t an option\u2014a fee bump will need to be submitted within a matter of hours or funds could be lost.<\/li>\n<li>Timelocked outputs: for most regular onchain payments, a user who wants to CPFP bump can pay for a fee bump using the funds stored in their output from the transaction they want to bump. In the case of LN, those funds aren\u2019t available until the channel close has been fully settled onchain. That means the user needs to use a separate UTXO to pay the fees.<\/li>\n<\/ul>\n<li>To address the above two concerns, LND is requiring users of anchor outputs to retain at least one confirmed UTXO of reasonable value in their wallet any time a channel is open. That ensures they can CPFP fee bump when necessary, but it has certain consequences, such as preventing spending the last of your onchain funds (even to open a new channel) while you still have at least one channel open.<br \/>Osuntokun\u2019s request is for wallets or services built on LND to let the development team know if any of the above concerns, or any other concerns related to anchor outputs, will cause serious problems. Although the question is specific to LND, the answers may have implications for all LN nodes.<\/li>\n<li>Sapio public launch: Jeremy Rubin <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-April\/018759.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> to the Bitcoin-Dev mailing list an announcement that he has made available the Sapio smart contract development toolkit, a Rust-based library and associated tooling that can be used to create smart contracts expressible using Bitcoin Script. The language was originally designed to make use of Rubin\u2019s proposed <a href=\"https:\/\/bitcoinops.org\/en\/topics\/op_checktemplateverify\/\" target=\"_blank\" rel=\"noopener\">OP_CHECKTEMPLATEVERIFY<\/a> opcode (OP_CTV), but it can simulate the existence of that opcode, and of other potential features for Bitcoin such as taproot, using a trusted signing oracle. In addition to the Sapio library, the release also contains extensive documentation and an experimental frontend.<\/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>Specter v1.3.0 released: <a href=\"https:\/\/github.com\/cryptoadvance\/specter-desktop\/releases\/tag\/v1.3.0\" target=\"_blank\" rel=\"noopener\">Specter v1.3.0<\/a> includes additional RBF support, Bitcoin Core setup from within the application, HWI 2 support, and an option to use <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/01\/20\/#mempool-v2-0-0-released\" target=\"_blank\" rel=\"noopener\">mempool.space<\/a> as a <a href=\"https:\/\/bitcoinops.org\/en\/topics\/block-explorers\/\" target=\"_blank\" rel=\"noopener\">block explorer<\/a> and for fee estimation.<\/li>\n<li>Specter-DIY v1.5.0: Hardware wallet firmware Specter-DIY <a href=\"https:\/\/github.com\/cryptoadvance\/specter-diy\/releases\" target=\"_blank\" rel=\"noopener\">released<\/a> v1.5.0 which adds custom SIGHASH flag support and full <a href=\"https:\/\/bitcoinops.org\/en\/topics\/output-script-descriptors\/\" target=\"_blank\" rel=\"noopener\">descriptor<\/a> support including <a href=\"https:\/\/bitcoinops.org\/en\/topics\/miniscript\/\" target=\"_blank\" rel=\"noopener\">miniscript<\/a>.<\/li>\n<li>BlueWallet v6.0.7 adds message signing: <a href=\"https:\/\/github.com\/BlueWallet\/BlueWallet\/releases\/tag\/v6.0.7\" target=\"_blank\" rel=\"noopener\">BlueWallet v6.0.7<\/a> allows users to sign and verify messages using Bitcoin addresses, among other features and fixes.<\/li>\n<li>Azteco announces Lightning support: Bitcoin voucher company Azteco <a href=\"https:\/\/medium.com\/@Azteco_\/at-azteco-weve-been-experimenting-with-lightning-for-over-a-year-refining-our-thinking-and-user-b9d112cff13c\" target=\"_blank\" rel=\"noopener\">announced<\/a> support for redeeming purchased bitcoins via Lightning Network.<\/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:\/\/bitcoincore.org\/bin\/bitcoin-core-0.21.1\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Core 0.21.1rc1<\/a> is a release candidate for a version of Bitcoin Core that, if activated, will enforce the rules of the proposed <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> soft fork, which uses <a href=\"https:\/\/bitcoinops.org\/en\/topics\/schnorr-signatures\/\" target=\"_blank\" rel=\"noopener\">schnorr signatures<\/a> and allows use of <a href=\"https:\/\/bitcoinops.org\/en\/topics\/tapscript\/\" target=\"_blank\" rel=\"noopener\">tapscript<\/a>. These are, respectively, specified by BIPs <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0341.mediawiki\" target=\"_blank\" rel=\"noopener\">341<\/a>, <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0340.mediawiki\" target=\"_blank\" rel=\"noopener\">340<\/a>, and <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0342.mediawiki\" target=\"_blank\" rel=\"noopener\">342<\/a>. Also included is the ability to pay <a href=\"https:\/\/bitcoinops.org\/en\/topics\/bech32\/\" target=\"_blank\" rel=\"noopener\">bech32m<\/a> addresses specified by <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0350.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP350<\/a>, although bitcoins spent to such addresses on mainnet will not be secure until activation of a soft fork using such addresses, such as taproot. The release additionally includes bug fixes and minor 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\/21377\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21377<\/a> adds the activation mechanism and <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21686\" target=\"_blank\" rel=\"noopener\">#21686<\/a> adds the activation parameters for the taproot softfork. Starting with the first difficulty adjustment after April 24th, miners will be able to signal readiness for Taproot activation on bit 2. If 1815 (90%) of one difficulty period\u2019s 2016 blocks in the signaling window signal readiness, the softfork activation locks in. The signaling window ends with the first difficulty adjustment after August 11th. If locked in, taproot will be activated at block height 709632, which is expected to be reached around November 12th.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21602\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21602<\/a> updates the listbanned RPC with two additional fields: ban_duration and time_remaining.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4444\" target=\"_blank\" rel=\"noopener\">C-Lightning #4444<\/a> adds <a href=\"https:\/\/github.com\/rustyrussell\/lnprototest\" target=\"_blank\" rel=\"noopener\">lnprototest<\/a> (LN Protocol Tests) to the default targets for C-Lightning\u2019s Continuous Integration (CI) tests and also makes it easier for developers to run the tests from C-Lightning\u2019s usual build system. The LN protocol tests make it easy for an implementation to test that they\u2019re following the <a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/\" target=\"_blank\" rel=\"noopener\">LN protocol specification<\/a>.<\/li>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/4588\" target=\"_blank\" rel=\"noopener\">LND #4588<\/a> skips creating a change output in cases where the amount of change is so small that it\u2019s worth less than the amount it would cost to spend it.<\/li>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/5193\" target=\"_blank\" rel=\"noopener\">LND #5193<\/a> disables channel validation by default for LND instances using the Neutrino client (which implements the <a href=\"https:\/\/bitcoinops.org\/en\/topics\/compact-block-filters\/\" target=\"_blank\" rel=\"noopener\">compact block filters<\/a> protocol). This option assumes that channel advertisements received from a peer are correct, saving the client from having to download old blocks necessary to verify those advertisements. This has the downside that payment attempts made using falsely advertised channels will fail, wasting time but not causing the loss of money\u2014a reasonable tradeoff for anyone already choosing to use a lightweight client. This new default behavior may be disabled by using the new configuration option &#8211;neutrino.validatechannels=true.<\/li>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/5154\" target=\"_blank\" rel=\"noopener\">LND #5154<\/a> adds basic support for using LND with a pruned full node, allowing LND to externally request from other Bitcoin nodes a block that has been deleted by the local node. LND can then extract whatever information it needs from the block without going through the pruned node. Because the user\u2019s own full node previously verified the block, this doesn\u2019t change the security model.<\/li>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/5187\" target=\"_blank\" rel=\"noopener\">LND #5187<\/a> adds new channel-commit-interval and channel-commit-batch-size parameters that can be used to configure how long LND will wait before sending a channel state update and the maximum number of changes it\u2019ll send in one update. The higher these values are, the more efficient a busy LND node will be, although that efficiency comes at the cost of having a slightly higher latency.<\/li>\n<li>Rust-Lightning #858 adds internal support for interoperating with Electrum-style blockchain data sources.<\/li>\n<li><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\/issues\/856\" target=\"_blank\" rel=\"noopener\">Rust-Lightning #856<\/a> updates how it handles funding transactions. Previously the wallet was asked to create the funding transaction that opened a new channel and to give Rust Lightning only that transaction\u2019s txid. Now Rust Lightning accepts the full funding transaction. Similar to a recent change to C-Lightning (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/03\/24\/#c-lightning-4428\" target=\"_blank\" rel=\"noopener\">Newsletter #141<\/a>), this allows the LN software to check the funding transaction before it is broadcast and ensure it is correct.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/498\" target=\"_blank\" rel=\"noopener\">HWI #498<\/a> adds support for signing arbitrary Bitcoin-style messages using the BitBox02 hardware wallet.<\/li>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/issues\/2425\" target=\"_blank\" rel=\"noopener\">BTCPay Server #2425<\/a> adds support for receiving <a href=\"https:\/\/bitcoinops.org\/en\/topics\/payjoin\/\" target=\"_blank\" rel=\"noopener\">payjoin<\/a> payments to the wallet even for addresses not associated with a BTCPay invoice.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/04\/21\/\" target=\"_blank\" rel=\"noopener\">original post here.<\/a> <\/p>\n<p><em>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.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week\u2019s newsletter covers using Lightning Network offers to address stuck payments, Taproot activation 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,130,1075],"class_list":{"0":"post-16907","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-core","9":"tag-bitcoin-optech","10":"tag-lightning","11":"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\/16907","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=16907"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/16907\/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=16907"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=16907"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=16907"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}