This week’s newsletter links to transcripts of recent LN specification meetings and summarizes a thread about the safety of blind MuSig2 signing. Also included are our regular sections with descriptions of new releases, release candidates, and notable code changes to popular Bitcoin infrastructure software.

News

• ● Transcripts of periodic LN specification meetings: Carla Kirk-Cohen posted to the Lightning-Dev mailing list to announce that the last several video conference meetings to discuss changes to the LN specification were transcribed. The transcripts are now available on Bitcoin Transcripts. In related news, as discussed a few weeks ago during the in-person LN developer conference, the #lightning-dev IRC chatroom on the Libera.chat network has seen a significant burst of renewed activity for LN-related discussion.

• ● Safety of blind MuSig2 signing: Tom Trevethan posted to the Bitcoin-Dev mailing list to request a review of a cryptographic protocol planned as part of a statechains deployment. The goal was to deploy a service that would use its private key to create a MuSig2 partial signature without gaining any knowledge about what it was signing or how its partial signature was used. The blind signer would simply report how many signatures it had created with a particular key.

  Discussion on the list examined pitfalls of various constructions related to the specific problem and of even more generalized blind schnorr signing. Also mentioned was a year-old gist by Ruben Somsen about a 1996 protocol for blind Diffie–Hellman (DH) key exchange, which can be used for blinded ecash. Lucre and Minicash are previous implementations of this scheme unrelated to Bitcoin, and Cashu is an implementation related to Minicash that also integrates support for Bitcoin and LN. Anyone interested in cryptography may find the thread interesting for its discussion of cryptographic techniques.

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.

• ● BTCPay Server 1.11.1 is the latest release of this self-hosted payment processor. The 1.11.x release series includes improvements to invoice reporting, additional upgrades to the checkout process, and new features for the point of service terminal.

Notable code and documentation changes

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

• ● Bitcoin Core #26467 allows the user to specify which output of a transaction is change in bumpfee. The wallet deducts value from this output to add fees when creating the replacement transaction. By default, the wallet attempts to detect a change output automatically and creates a new one if it fails to do so.

• ● Core Lightning #6378 and #6449 will mark an offchain incoming HTLC as failed if the node is unable (or unwilling because of fee costs) to time out a corresponding onchain HTLC. For example, Alice’s node forwards an HTLC to Bob’s node with an expiry of 20 blocks and Bob’s node forwards an HTLC with the same payment hash to Carol’s node with an expiry of 10 blocks. Subsequently, the channel between Bob and Carol is forced closed onchain.

  After the 10-block expiry, there arises a situation that should not be common: Bob’s node either spends using the refund condition but the transaction doesn’t confirm, or he determines that the cost of fees to claim the refund are higher than the value and doesn’t create a spend. Prior to this PR, Bob’s node wouldn’t create an offchain cancellation of the HTLC he received from Alice because that could allow Alice to keep the money she forwarded to Bob and for Carol to claim the money Bob forwarded to her, costing Bob the amount of the HTLC.

  However, after the 20-block expiry of the HTLC Alice offered him, she can force-close the channel to attempt to receive a refund of the amount she forwarded to Bob, and her software may automatically do this to prevent Alice from potentially losing the money to a node upstream of her. But, if she force-closes the channel, she might end up in the same position as Bob: she’s either unable to claim the refund or doesn’t attempt it because it’s not economical. That means a useful channel between Alice and Bob was closed for no gain to either one of them. This problem could be repeated multiple times for any hops upstream of Alice, resulting in a cascade of unwanted channel closures.

  The solution implemented in this PR is for Bob to wait as long as is reasonable to claim a refund and, if it’s not going to happen, create an offchain cancellation of the HTLC he received from Alice, allowing their channel to continue operating even if it means he might lose the amount of the HTLC.

• ● Core Lightning #6399 adds support to the pay command for paying invoices created by the local node. This can simplify account management code for software that calls CLN in the background, as discussed in a recent mailing list thread.

• ● Core Lightning #6389 adds an optional CLNRest service, “a lightweight Python-based Core Lightning plugin that transforms RPC calls into a REST service. By generating REST API endpoints, it enables the execution of Core Lightning’s RPC methods behind the scenes and provides responses in JSON format.” See its documentation for details.

• ● Core Lightning #6403 and #6437 move the runes authorization and authentication mechanism out of CLN’s commando plugin (see Newsletter #210) and into its core functionality, allowing other plugins to use them. Several commands related to creating, destroying, and renaming runes are also updated.

• ● Core Lightning #6398 extends the setchannel RPC with a new ignorefeelimits option that will ignore the minimum onchain fee limits for the channel, allowing the remote channel counterparty to set a feerate below the minimum the local node will permit. This can help work around a potential bug in another LN node implementation or can be used to eliminate fee contention as a source of problems in partly trusted channels.

• ● Core Lightning #5492 adds User-level Statically Defined Tracepoints (USDT) and the means to use them. These allow users to probe the internal operation of their node for debugging without introducing any significant overhead when tracepoints aren’t being used. See Newsletter #133 for the previous inclusion of USDT support into Bitcoin Core.

• ● Eclair #2680 adds support for the quiescence negotiation protocol that is required by the splicing protocol proposed in BOLTs #863. The quiescence protocol prevents the two nodes sharing a channel from sending each other any new HTLCs until a certain operation has completed, such as agreeing on the parameters of a splice and cooperatively signing the onchain splice-in or splice-out transaction. An HTLC received during splice negotiation and signing may invalidate previous negotiations and signatures, so it’s simpler to simply pause HTLC relay for the few network round trips required to get the splice transaction mutually signed. Eclair already supports splicing, but this change brings it closer to supporting the same splicing protocol that other node software will likely use.

• ● LND #7820 adds to the BatchOpenChannel RPC all the fields available to the non-batched OpenChannel RPC except for funding_shim (not needed for batched opens) and fundmax (you can’t give one channel all of the balance when opening multiple channels).

• ● LND #7516 extends the OpenChannel RPC with a new utxo parameter that allows specifying one or more UTXOs from the wallet which should be used to fund the new channel.

• ● BTCPay Server #5155 adds a reporting page to the back office that provides payment and onchain wallet reports, the ability to export to CSV, and is extendable by plugins.