{"id":17436,"date":"2021-03-17T16:05:27","date_gmt":"2021-03-17T16:05:27","guid":{"rendered":"http:\/\/ci027e4e45300027d8"},"modified":"2025-10-02T15:07:08","modified_gmt":"2025-10-02T20:07:08","slug":"bitcoin-optech-140-rescuing-lightning-transactions","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-140-rescuing-lightning-transactions","title":{"rendered":"Bitcoin Optech #140: Rescuing Lightning Transactions"},"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 describes a discussion about rescuing lost LN funding transactions and includes our regular sections with announcements of releases, release candidates, and notable changes to popular Bitcoin infrastructure software.<\/p>\n<h2>News<\/h2>\n<ul>\n<li><strong>Rescuing lost LN funding transactions:<\/strong> LN funding transactions are not safe in the presence of transaction malleability. Segwit eliminated third-party malleability as a concern for most transactions, but it doesn\u2019t address the case where the creator of a transaction mutates its txid themselves, such as by fee bumping the funding transaction using <a href=\"https:\/\/bitcoinops.org\/en\/topics\/replace-by-fee\/\" target=\"_blank\" rel=\"noopener\">Replace-by-Fee<\/a> (RBF). If a txid mutation happens, then the pre-signed refund transaction is not valid, so the user can\u2019t get their funds back. Additionally, the remote node may not automatically see the funding transaction and so may not be able to help the funder get their money back.This week, Rusty Russell <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2021-March\/002981.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> to the Lightning-Dev mailing list about a quick and experimental feature he implemented in C-Lightning to help a user with this problem recover their funds. He also described alternative solutions for related problems as well as the impact of the proposed channel dual-funding protocol on this problem. Christian Decker also <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2021-March\/002982.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> a proposed change to the LN specification to help facilitate funding recovery efforts. As LN software adds support for funding channels from external wallets (e.g. C-Lightning as described in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/06\/19\/#c-lightning-2672\" target=\"_blank\" rel=\"noopener\">Newsletter #51<\/a> and LND in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/04\/08\/#lnd-4079\" target=\"_blank\" rel=\"noopener\">Newsletter #92<\/a>), developers may want to give this type of failure scenarios more attention.<\/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\/bitcoin-core\/HWI\/releases\/tag\/2.0.0\" target=\"_blank\" rel=\"noopener\">HWI 2.0.0<\/a> is the release for the next major version of HWI. Among other improvements, it contains support for multisig on the BitBox02, improved documentation, and support for paying <code>OP_RETURN<\/code> outputs with a Trezor.<\/li>\n<li><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\/releases\/tag\/v0.0.13\" target=\"_blank\" rel=\"noopener\">Rust-Lightning 0.0.13<\/a> is the latest release for this LN library containing improvements aimed at forward compatibility with <a href=\"https:\/\/bitcoinops.org\/en\/topics\/multipath-payments\/\" target=\"_blank\" rel=\"noopener\">multipath payments<\/a> and future script upgrades such as <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a>.<\/li>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/releases\/tag\/v1.0.7.0\" target=\"_blank\" rel=\"noopener\">BTCPay Server 1.0.7.0<\/a> is the latest release for this self-hosted payment processing software. Notable improvements include a more featureful and visually appealing wallet setup wizard, the ability to import wallets created using Specter, and more efficient QR codes for <a href=\"https:\/\/bitcoinops.org\/en\/topics\/bech32\/\" target=\"_blank\" rel=\"noopener\">bech32 addresses<\/a>.<\/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\/21007\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21007<\/a> adds a new <code>-daemonwait<\/code> configuration option. It has been possible to run Bitcoin Core as a background daemon process since early versions by starting the program with the <code>-daemon<\/code> configuration option. The <code>-daemon<\/code> option causes the program to immediately start the daemon process in the background. The new <code>-daemonwait<\/code> option is similar, but only puts the daemon process in the background after initialization is complete. This allows the user or parent process to more easily know whether the daemon started successfully by observing the program\u2019s output or exit code.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4404\" target=\"_blank\" rel=\"noopener\">C-Lightning #4404<\/a> allows the <code>keysend<\/code> RPC (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/07\/22\/#c-lightning-3792\" target=\"_blank\" rel=\"noopener\">Newsletter #107<\/a>) to send messages even to nodes that don\u2019t explicitly signal that they support the feature. As <a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4299#issuecomment-781606865\" target=\"_blank\" rel=\"noopener\">discussed<\/a>, the signal was never standardized and the procedure implemented by LND didn\u2019t depend on signaling, so this change should allow C-Lightning to send to roughly the same set of nodes that LND can address.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4410\" target=\"_blank\" rel=\"noopener\">C-Lightning #4410<\/a> brings the experimental implementation for dual-funded channels in line with the most recent draft specification changes. Most notably, the use of Proof of Discrete Log Equivalency (PODLE) has been dropped, at least temporarily (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/02\/05\/#interactive-construction-of-ln-funding-transactions\" target=\"_blank\" rel=\"noopener\">Newsletter #83<\/a> for original discussion of PODLEs and <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/01\/13\/#ln-dual-funding-anti-utxo-probing\" target=\"_blank\" rel=\"noopener\">Newsletter #131<\/a> for discussion about alternatives). Subsequent to this merge, a <a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4427\" target=\"_blank\" rel=\"noopener\">new PR<\/a> was opened that will make experimenting with dual-funding more accessible by eliminating the need to compile C-Lightning with special build flags (although a special configuration option will still be required).<\/li>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/5083\" target=\"_blank\" rel=\"noopener\">LND #5083<\/a> allows a <a href=\"https:\/\/bitcoinops.org\/en\/topics\/psbt\/\" target=\"_blank\" rel=\"noopener\">PSBT<\/a> to be read from a file rather than by reading the standard input (stdin) file descriptor. Some terminals have a <a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/5080\" target=\"_blank\" rel=\"noopener\">limit<\/a> on the number of characters that can be added to stdin simultaneously (i.e. pasted), which made PSBTs over 4096 base64 characters (equivalent to 3.072 bytes of binary) unusable. Especially now that several hardware wallets require PSBTs include previous transactions for segwit spends (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/06\/10\/#fee-overpayment-attack-on-multi-input-segwit-transactions\" target=\"_blank\" rel=\"noopener\">Newsletter #101<\/a>), it\u2019s common to create PSBTs over 3 KiB in size.<\/li>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/5033\" target=\"_blank\" rel=\"noopener\">LND #5033<\/a> adds an <code>updatechanstatus<\/code> RPC that can advertise that a channel has been disabled (similar to your node going offline) or that it\u2019s been re-enabled (similar to your node coming back online).<\/li>\n<li>Rust-Lightning #826 increases the maximum allowed <code>OP_CHECKSEQUENCEVERIFY<\/code> delay to 2,016 blocks for the output paying the node that is unilaterally closing the channel. This fixes an interoperability issue when opening channels with LND, which may request a delay up to 2016 blocks, larger than the previous Rust-Lightning maximum of 1008 blocks.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/issues\/488\" target=\"_blank\" rel=\"noopener\">HWI #488<\/a> implements a breaking change in how the <code>displayaddress<\/code> command handles multisig addresses when used with the <code>--desc<\/code> option for <a href=\"https:\/\/bitcoinops.org\/en\/topics\/output-script-descriptors\/\" target=\"_blank\" rel=\"noopener\">output script descriptors<\/a>. Previously, HWI applied <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0067.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP67<\/a> lexicographic key sorting automatically based on what the device involved used (e.g. applying BIP67 for Coldcard devices, not applying it for Trezor devices). The way this was implemented created problems when the user explicitly specified the <code>sortedmulti<\/code> descriptor option that implements BIP67 key sorting. After this change, users of descriptors need to specify <code>sortedmulti<\/code> for devices that require lexicographic key sorting or <code>multi<\/code> for those that don\u2019t.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>This week\u2019s Bitcoin Optech newsletter describes discussion on rescuing lost Lightning Network funding transactions, announcements of releases and release candidates, and notable changes to popular Bitcoin infrastructure software.<\/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,460],"class_list":["post-17436","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technical","tag-bitcoin-optech","tag-lightning-network"],"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\/17436","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=17436"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/17436\/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=17436"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=17436"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=17436"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}