Bitcoin Optech #140: Rescuing Lightning Transactions

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’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s 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.


Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

  • HWI 2.0.0 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 OP_RETURN outputs with a Trezor.
  • Rust-Lightning 0.0.13 is the latest release for this LN library containing improvements aimed at forward compatibility with multipath payments and future script upgrades such as taproot.
  • BTCPay Server 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 bech32 addresses.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • Bitcoin Core #21007 adds a new -daemonwait configuration option. It has been possible to run Bitcoin Core as a background daemon process since early versions by starting the program with the -daemon configuration option. The -daemon option causes the program to immediately start the daemon process in the background. The new -daemonwait 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’s output or exit code.
  • C-Lightning #4404 allows the keysend RPC (see Newsletter #107) to send messages even to nodes that don’t explicitly signal that they support the feature. As discussed, the signal was never standardized and the procedure implemented by LND didn’t depend on signaling, so this change should allow C-Lightning to send to roughly the same set of nodes that LND can address.
  • C-Lightning #4410 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 Newsletter #83 for original discussion of PODLEs and Newsletter #131 for discussion about alternatives). Subsequent to this merge, a new PR 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).
  • LND #5083 allows a PSBT to be read from a file rather than by reading the standard input (stdin) file descriptor. Some terminals have a limit 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 Newsletter #101), it’s common to create PSBTs over 3 KiB in size.
  • LND #5033 adds an updatechanstatus RPC that can advertise that a channel has been disabled (similar to your node going offline) or that it’s been re-enabled (similar to your node coming back online).
  • Rust-Lightning #826 increases the maximum allowed OP_CHECKSEQUENCEVERIFY 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.
  • HWI #488 implements a breaking change in how the displayaddress command handles multisig addresses when used with the --desc option for output script descriptors. Previously, HWI applied BIP67 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 sortedmulti descriptor option that implements BIP67 key sorting. After this change, users of descriptors need to specify sortedmulti for devices that require lexicographic key sorting or multi for those that don’t.

Be the first to comment

Leave a Reply

Your email address will not be published.