This week’s newsletter describes an idea for nested MuSig2 Lightning nodes and summarizes a project formally verifying secp256k1’s modular scalar multiplication. Also included are our regular sections describing recent changes to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

  • ● Discussion of using nested MuSig2 in the Lightning Network: ZmnSCPxj posted to Delving Bitcoin about the idea to create k-of-n multisignature Lightning nodes by leveraging nested MuSig2 as discussed in a recent paper.

    According to ZmnSCPxj, the need for a k-of-n signature scheme in Lightning derives from large holders wanting to provide their liquidity to the network in exchange for fees. Those large holders may need strong guarantees on the safety of their funds, which a single key may not grant. Instead, a k-of-n scheme would provide the required security as long as less than k keys are compromised.

    As of today, the BOLTs specifications do not allow for a secure way to implement a k-of-n multisig scheme, with the main obstacle being the revocation key. According to the BOLTs, the revocation key is created using a shachain, which, due to its characteristics, is not suitable for use with k-of-n multisig schemes.

    ZmnSCPxj proposes a modification to the BOLTs specifications to make it optional for nodes to perform shachain validation of revocation keys from channel parties by signaling a new pair of feature bits, named no_more_shachains, in both globalfeatures and localfeatures. An odd bit would signal that the node will not perform shachain validation on the counterparty, while still providing shachain-valid revocation keys to keep compatibility with legacy nodes. An even bit would signal that the node will neither validate nor provide shachain-valid revocation keys. The former bit would be used by gateway nodes, as ZmnSCPxj defines them, which would connect the rest of the network to the k-of-n nodes, those featuring the even bit.

    Finally, ZmnSCPxj emphasizes how this proposal would present a major trade-off, namely the storage requirements for revocation keys. In fact, nodes would be required to store individual revocation keys instead of the compact shachain representation, effectively tripling the on-disk space needed.

  • ● Formal verification of secp256k1 modular scalar multiplication: Remix7531 posted to the Bitcoin-Dev mailing list about formally verifying secp256k1’s modular scalar multiplication. The project demonstrates that formal verification of a subset of bitcoin-core/secp256k1 is practical.

    In the secp256k1-scalar-fv-test codebase, Remix7531 takes real C code from the library and proves it correct with respect to a formal mathematical specification using Rocq and the Verified Software Toolchain (VST). Formalization with Rocq can prove the absence of memory errors, correctness against a specification, and termination.

    He plans to port the existing scalar multiplication proof to RefinedC, which would give a direct comparison of both frameworks on the same verified code. Also, on the verification side, the next target is Pippenger’s algorithm for multi-scalar multiplication, which is used for batch verification of signatures.

Changes to services and client software

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

  • ● Coldcard 6.5.0 adds MuSig2 and miniscript: Coldcard 6.5.0 adds MuSig2 signing support, BIP322 proof of reserve capabilities, and additional miniscript and taproot features including tapscript support for up to eight leaves.

  • ● Frigate 1.4.0 released: Frigate v1.4.0, an experimental Electrum server for silent payments scanning (see Newsletter #389), now uses the UltrafastSecp256k1 library in conjunction with modern GPU computation to reduce scanning time for a few months of blocks from an hour to half a second.

  • ● Bitcoin Backbone updates: Bitcoin Backbone released multiple updates adding BIP152 compact block support, transaction and address management improvements, and multiprocess interface groundwork (see Newsletter #368). The announcement also proposes Bitcoin Kernel API extensions for standalone header verification and transaction validation.

  • ● Utreexod 0.5 released: Utreexod v0.5 introduces IBD using SwiftSync which uses cryptographic aggregation to eliminate the need for downloading and verifying accumulator inclusion proofs during IBD, and eliminates the extra data downloaded by Compact State Nodes during IBD from 1.4 TB to ~200 GB, with further reductions possible through proof caching.

  • ● Floresta 0.9.0 released: Floresta v0.9.0 aligns its P2P networking with the BIP183 for UTXO proof exchange, and replaces libbitcoinconsensus with Bitcoin Kernel for approximately 15x faster script validation, among other changes.

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.

  • ● Bitcoin Core 31.0rc4 is a release candidate for the next major version of the predominant full node implementation. A testing guide is available.

  • ● Core Lightning 26.04rc3 is the latest release candidate for the next major version of this popular LN node, continuing the splicing updates and bug fixes from earlier candidates.

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 #34401 extends the btck_BlockHeader support added to the libbitcoinkernel C API (see Newsletters #380 and #390) by adding a method to serialize a block header into its standard byte encoding. This allows external programs using the C API to store, transmit, or compare serialized headers without needing separate serialization code.

  • ● Bitcoin Core #35032 stops storing network addresses learned when using the privatebroadcast option (see Newsletter #388) with the sendrawtransaction RPC in addrman, Bitcoin Core’s peer address manager. The privatebroadcast option allows users to broadcast transactions through short-lived Tor or I2P connections, or through the Tor proxy to IPv4/IPv6 peers.

  • ● Core Lightning #9021 enables splicing by default by removing it from experimental status, following the merge of the splicing protocol into the BOLTs specification (see Newsletter #398).

  • ● Core Lightning #9046 increases the assumed final_cltv_expiry (the CLTV expiry delta for the last hop) for keysend payments from 22 to 42 blocks to match LDK’s value, restoring interoperability.

  • ● LDK #4515 switches zero-fee commitment channels (see Newsletter #371) from the experimental feature bit to the production feature bit. Zero-fee commitment channels replace the two anchor outputs with one shared Pay-to-Anchor (P2A) output, capped at a value of 240 sats.

  • ● LDK #4558 applies the existing receiver-side timeout for incomplete multipath payments to keysend payments. Previously, incomplete keysend MPPs could remain pending until CLTV expiry, tying up HTLC slots instead of failing back after the normal timeout period.

  • ● LND #9985 adds end-to-end support for production simple taproot channels with a distinct commitment type (SIMPLE_TAPROOT_FINAL) and production feature bits 80/81. Production uses optimized tapscripts that prefer OP_CHECKSIGVERIFY over OP_CHECKSIG+OP_DROP, and adds map-based nonce handling on revoke_and_ack keyed by funding txid as groundwork for future splicing.

  • ● BTCPay Server #7250 adds LUD-21 support by introducing an optional unauthenticated endpoint named verify that allows external services to verify whether a BOLT11 invoice created via LNURL-pay has been settled.

  • ● BIPs #2089 publishes BIP376, which defines new PSBTv2 per-input fields to carry the BIP352 tweak data needed to sign and spend silent payment outputs, plus an optional spend-key BIP32 derivation field compatible with BIP352’s 33-byte spend keys. This complements BIP375, which specifies how to create silent payment outputs using PSBTs (see Newsletter #337).

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on April 21. The discussion is also recorded and will be available from our podcasts page.