This week’s newsletter summarizes discussion about the speedy trial soft fork activation mechanism and links to an update of an optimized LN pathfinding algorithm. Also included are our regular sections with descriptions of recent changes to services and client software, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

• ● Speedy trial discussion: a mention of the speedy trial soft fork activation method from the summary of a recent meeting about the proposed OP_CHECKTEMPLATEVERIFY opcode was spun off into a separate thread on the Bitcoin-Dev mailing list for additional discussion after Jorge Timón expressed concern about the use of speedy trial for a soft fork he thought was controversial.

  Russell O’Connor explained how the concerns had been previously addressed. Anthony Towns further described how an unwanted soft fork activation using speedy trial could be resisted by objecting users.

• ● Payment delivery algorithm update: René Pickhardt posted to the Lightning-Dev mailing list that he’d found a much more computationally efficient approximation for his and Stefan Richter’s pathfinding algorithm published last year. See Newsletter #163 for earlier discussion about the algorithm.

  Pickhardt’s email also suggests ways in which fast payment success could be improved, such as through the implementation of stuckless payments and by allowing refundable overpayments as proposed in several academic papers.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

• ● Coinswap implementation Teleport Transactions announced: In a recent Bitcoin-Dev mailing list post, Chris Belcher announced an alpha version 0.1 of Teleport Transactions that implements the coinswap protocol.

• ● JoinMarket adds taproot sends: JoinMarket v0.9.5 adds the ability to send to bech32m addresses.

• ● Mercury Wallet adds RBF support: Mercury wallet, a wallet for the Mercury statechain, released v0.6.5 including support for Replace-by-Fee (RBF) transaction replacements for withdrawals.

• ● Hexa Wallet adds Lightning support: Hexa Wallet, a Bitcoin mobile wallet, added Lightning Network features for LND users running their own node in the v2.0.71 release.

• ● Sparrow adds BIP47 support: Sparrow 1.6.0 (and subsequent 1.6.1 and 1.6.2 releases) added support and features for BIP47 reusable payment codes and described the features.

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.1.0-rc.1 is a release candidate for HWI that adds taproot support for several hardware signing devices, among other improvements and bug fixes.

Notable code and documentation changes

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

• ● Eclair #2203 adds additional configuration parameters to allow users to specify a different minimum funding for unannounced channels than the default used for announced channels.

• ● LDK #1311 adds support for the Short Channel Identifier (SCID) alias field proposed in BOLTs #910, which allows a node to request its peer identify a channel by an arbitrary value rather than one derived from the onchain transaction which anchors the channel. This can be useful for privacy by preventing the SCID from disclosing to third parties which transactions the node created, and it’s also proposed for use in a specification for opt-in zero-conf channels (sometimes called turbo channels) as described in Newsletter #156.

• ● LDK #1286 adds offsets to CLTV (OP_CHECKLOCKTIMEVERIFY) values used for routing payments as recommended by BOLT7. This makes it harder for someone observing part of the payment attempt (e.g. one of the nodes routing the payment) to correctly guess which node might be the intended receiver.

• ● HWI #584 adds support for paying bech32m addresses when using recent firmware versions with the BitBox02 hardware signing device.

• ● HWI #581 disables support for signing transactions with external inputs (e.g. in a coinjoin) when using a Trezor with future firmware versions. This PR follows a firmware change that broke the workaround HWI was using to achieve support. A follow-up PR (HWI #590) seems to indicate that Trezor is looking into giving users a way to sign such transactions in the future.

• ● BDK #515 begins retaining spent transaction outputs in the internal database. This can be useful for creating replacement transactions and simplifies the ongoing implementation of BIP47 reusable payment codes.