This week’s newsletter describes a discussion about LN splicing and links to a proposed BIP for recommended transaction terminology. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of new releases and release candidates—including a security update for libsecp256k1—and and descriptions of notable changes made to popular Bitcoin infrastructure software.

News

  • ● Splicing specification discussions: several LN developers posted to the Lightning-Dev mailing list this week about ongoing work on the draft specification for splicing, which allows some funds in an offchain LN channel to be spent onchain (splice-out) or for onchain funds to be added to an offchain channel (splice-in). The channel can continue to operate while an onchain splicing transaction is waiting for sufficient confirmations.

    Splicing transaction flow

    Discussions this week included:

    • ● Which commitment signatures to send: when a splice is created, a node will hold parallel commitment transactions, one that spends from the original funding output and one that spends from each new funding output for all pending splices. Each time the channel state is updated, all of the parallel commitment transactions need to be updated. The simple way to handle this is by sending the same messages that would be sent for an individual commitment transaction but repeating them, one for each parallel commitment transaction.

      That’s what was done in the original draft specifications for splicing (see Newsletters #17 and #146). However, as Lisa Neigut explained this week, the creation of a new splice requires signing the new derived commitment transaction. In the current draft specification, sending any signature requires sending signatures for all other current commitment transactions. That’s redundant: the signatures for those other commitment transactions were already sent. Additionally, the way each party in the current LN protocol acknowledges they received a signature from their counterparty is by sending the revocation point for the previous commitment transaction. Again, that information would already have been sent. It’s not harmful to re-send signatures and old revocation points, but it requires extra bandwidth and processing. The advantage is that performing the same operation in all cases helps keep the specification simple, which may reduce implementation and testing complexity.

      The alternative is to special case only sending the minimum number of signatures for the new commitment transaction when a new splice is negotiated, plus an acknowledgment that they were received. This is much more efficient, even if it adds some complexity. It’s worth noting that LN nodes only need to manage parallel commitment transactions until a splice transaction has confirmed to a sufficient depth for both counterparties to consider it secure. After that, they can return to operating on a single commitment transaction.

    • ● Relative amounts and zero-conf splices: Bastien Teinturier posted about several proposed specification updates. In addition to the aforementioned commitment signatures change, he also recommends that splice proposals use relative amounts, e.g. “200,000 sats” indicates Alice will splice in that amount and “-50,000 sats” indicates she wants to splice out that amount. He also mentions a concern involving zero-conf splicing but does not go into detail about it.

  • ● Proposed BIP for transaction terminology: Mark “Murch” Erhardt posted the draft of an informational BIP to the Bitcoin-Dev mailing list that suggests a vocabulary to use for referring to parts of transactions and concepts relating to them. As of this writing, all replies to the proposal were supportive of the effort.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Don’t download witnesses for assumed-valid blocks when running in prune mode is a PR by Niklas Gögge (dergoegge) that improves the performance of Initial Block Download (IBD) by not downloading witness data on nodes that are configured to both prune block data and use assumevalid. This optimization was discussed in a recent stack exchange question.

  • If assume-valid is enabled but not pruning, why does the node need to download (non-recent) witness data, given that the node won’t be checking this data? Should this PR also disable witness download in this non-pruning case?

    The witness data is needed because peers may request non-recent blocks from us (we advertise ourselves as non-pruned). ➚

  • How much bandwidth might be saved by this enhancement during an IBD? In other words, what is the cumulative size of all witness data up to a recent block (say, height 781213)?

    110.6 GB, which is about 25% of the total block data. One participant pointed out that 110 GB is about 10% of his monthly ISP download limit, so this is a significant reduction. Participants also expected the percentage savings to increase with the recently expanded use of witness data. ➚

  • Would this improvement reduce the amount of download data from all blocks back to the genesis block?

    No, only since segwit activation (block height 481824); blocks before segwit do not have witness data. ➚

  • This PR implements two main changes, one to the block request logic and one to block validation. What are these changes in more detail?

    In validation, when script checks will be skipped, also skip witness merkle tree checks. In the block request logic, remove MSG_WITNESS_FLAG from the fetch flags so our peers don’t send us the witness data. ➚

  • Without this PR, script validation is skipped under assume-valid, but other checks that involve witness data are not skipped. What are these checks that this PR will cause to be skipped?

    The coinbase merkle root, the witness sizes, the maximum witness stack items, and the block weight. ➚

  • The PR does not include an explicit code change for skipping all the extra checks mentioned in the previous question. Why does that work out?

    It turns out that all the extra checks just pass when you don’t have any witnesses. This makes sense considering that segwit was a soft fork. With the PR, we are essentially just pretending like we are a pre-segwit node (up to the assume-valid point). ➚

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.

  • ● Libsecp256k1 0.3.1 is a security release that fixes an issue related to code that should run in constant time but was not when compiled with Clang version 14 or higher. The vulnerability may leave affected applications vulnerable to timing side-channel attacks. The authors strongly recommend updating affected applications.

  • ● BDK 1.0.0-alpha.0 is a test release of the major changes to BDK described in Newsletter #243. Developers of downstream projects are encouraged to begin integration testing.

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.

  • ● Core Lightning #6012 implements several significant improvements in the Python library for writing CLN plugins (see Newsletter #26) that allow it to better work with CLN’s gossip store. The changes allow building better analysis tools for gossip and will make it easier to develop plugins that use gossip data.

  • ● Core Lightning #6124 adds the ability to blacklist runes with commando and maintain a list of all runes, which is useful for tracking and disabling compromised ones.

  • ● Eclair #2607 adds a new listreceivedpayments RPC that lists all payments received by the node.

  • ● LND #7437 adds support for backing up just a single channel to a file.

  • ● LND #7069 allows a client to send a message to its watchtower asking for a session to be deleted. This allows the watchtower to stop monitoring for onchain transactions which close the channel in a revoked state. This reduces the storage and CPU requirements for both the watchtower and the client.

  • ● BIPs #1372 assigns BIP327 to the MuSig2 protocol for creating multisignatures which can be used with taproot and other BIP340-compatible schnorr signature systems. As described in the BIP, the benefits include non-interactive key aggregation and a requirement for only two rounds of communication to complete the signing. Non-interactive signing is also possible with additional setup between the participants. The protocol is compatible with all of the advantages of any multisignature scheme, such as significantly reducing onchain data and enhancing privacy—both for participants and for users of the network in general.