This week’s newsletter looks at summaries of some of the topics discussed at a recent LN developer meeting. Also include are our regular sections with descriptions of changes to popular clients and services, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● LN Summit 2024 notes: Olaoluwa Osuntokun posted to Delving Bitcoin a summary of his notes (with additional commentary) from a recent LN developer conference. Some of the topics discussed included:

    • ● Version 3 commitment transactions: developers discussed how to use new P2P features, including TRUC transactions and P2A outputs, to improve the security of LN commitment transactions that can be used to unilaterally close a channel. Discussion focused on various design tradeoffs.

    • ● PTLCs: although long proposed as a privacy upgrade to LN, as well as possibly useful for other purposes such as stuckless transactions, recent research into the tradeoffs of various possible PTLC implementations was discussed (see Newsletter #268). A particular focus was the construction of the signature adaptor (e.g. using scripted multisig versus scriptless MuSig2) and its effect on the commitment protocol (see next item).

    • ● State update protocol: a proposal was discussed to convert LN’s current state update protocol from allowing either side to propose an update at any time to only allowing one party at a time to propose updates (see Newsletters #120 and #261). Allowing either side to propose updates can result in both sides proposing updates simultaneously, which is difficult to reason about and can lead to accidental channel force closures. The alternative is for only one party to be in charge at a time, e.g. Alice is initially the only one allowed to propose state updates; if she has none to propose, she can tell Bob that he’s in charge. When Bob’s finished proposing updates, he can transfer control back to Alice. This simplifies reasoning about the protocol, eliminates problems with simultaneous proposals, and further makes it easy for the non-controlling party to reject any unwanted proposals. The new round-based protocol would also work well with MuSig2-based signature adaptors.

    • ● SuperScalar: the developer of a proposed channel factory construction for end-users gave a presentation on the proposal and solicited feedback. Optech will publish a more detailed description of SuperScalar in a future newsletter.

    • ● Gossip upgrade: developers discussed upgrades to the LN gossip protocol. These are most urgently needed for supporting new types of funding transactions, such as for simple taproot channels, but may also add support for other features. One new feature discussed was having channel announcement messages include an SPV proof (or a commitment to an SPV proof) to allow lightweight clients to verify that a funding transaction (or sponsoring transaction) was included in a block at some point.

    • ● Research on fundamental delivery limits: research was presented on payment flows that cannot result in success given limitations of the network (e.g., channels with insufficient capacity); see Newsletter #309. If an LN payment is infeasible, the spender and receiver can always use an onchain payment. However, the rate of onchain payments is limited by the maximum block weight, so it’s possible to calculate the maximum throughput (payments per second) of the combined Bitcoin and LN system by dividing the maximum onchain rate by the rate of infeasible LN payments. Using this rough metric, to achieve a maximum of about 47,000 payments per second, the infeasible rate must be below 0.29%. Two techniques were discussed for reducing the infeasible rate: (1) virtual or real channels that involve more than two parties, as more parties implies more funds for forwarding and more forwarding funds increases the rate of feasibility; and (2) credit channels where parties who trust each other can forward payments between themselves without the ability to enforce those payments onchain—with all other users still receiving trustless payments.

    Osuntokun encouraged other participants to post corrections or expansions to the thread.

Changes to services and client software

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

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.

  • ● BDK 1.0.0-beta.5 is a release candidate (RC) of this library for building wallets and other Bitcoin-enabled applications. This latest RC “enables RBF by default and updates the bdk_esplora client to retry server requests that fail due to rate limiting. The bdk_electrum crate now also offers a use-openssl feature.”

Notable code and documentation changes

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

  • ● Bitcoin Core #30955 introduces two new methods to the Mining interface (see Newsletter #310), in line with the requirements for Stratum V2. The submitSolution() method allows miners to submit a block solution more efficiently by only requiring the nonce, timestamp, version fields, and coinbase transaction, instead of the entire block. Additionally, getCoinbaseMerklePath() is introduced to construct the merkle path field required in the NewTemplate message. This PR also reinstates BlockMerkleBranch, which was previously removed in Bitcoin Core #13191.

  • ● Eclair #2927 adds enforcement of recommended feerates (see Newsletter #323) for on-the-fly funding (see Newsletter #323), by rejecting open_channel2 and splice_init messages that use a feerate lower than the recommended value.

  • ● Eclair #2922 removes support for splicing without channel quiescence (see Newsletter #309), to conform to the latest splicing protocol as proposed in BOLTs #1160, which requires nodes to use the quiescence protocol during splicing. Previously, splicing was allowed under a less formal mechanism, where splice messages were permitted if the commitments were already quiescent, acting as a “poor man’s” version of channel quiescence.

  • ● LDK #3235 adds a last_local_balance_msats field to the ChannelForceClosed event, which gives the local balance of a node in millisatoshis (msats) just before the channel was force-closed, allowing users to know how many msats they lost due to rounding.

  • ● LND #8183 adds the optional CloseTxInputs field to the chanbackup.Single structure in the static channel backup (SCB) file, to store the inputs required to generate force-close transactions. This allows users to manually retrieve funds when a peer is offline using the chantools scbforceclose command as a last-resort recovery option. However, users should exercise extreme caution as this feature could result in the loss of funds if the channel has been updated since the backup was created. In addition, the PR introduces the ManualUpdate method, which will update channel backups whenever LND shuts down.

  • ● Rust Bitcoin #3450 adds v3 as a new variant of the transaction version, following Bitcoin Core’s acceptance of Topologically Restricted Until Confirmation (TRUC) transactions as standard (see Newsletter #307).