Bitcoin Optech Newsletter #401

By Bitcoin Optech April 17, 2026 · Edited April 17, 2026

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

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

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#discussion-of-using-nested-musig2-in-the-lightning-network) Discussion of using nested MuSig2 in the Lightning Network: ZmnSCPxj posted (https://delvingbitcoin.org/t/towards-a-k-of-n-lightning-network-node/2395) to Delving Bitcoin about the idea to create k-of-n multisignature Lightning nodes by leveraging nested MuSig2 as discussed in a recent paper (https://eprint.iacr.org/2026/223).

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.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#formal-verification-of-secp256k1-modular-scalar-multiplication) Formal verification of secp256k1 modular scalar multiplication: Remix7531 posted (https://groups.google.com/g/bitcoindev/c/l7AdGAKd1Oo) 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 (https://github.com/remix7531/secp256k1-scalar-fv-test),

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.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#coldcard-6-5-0-adds-musig2-and-miniscript) Coldcard 6.5.0 adds MuSig2 and miniscript: Coldcard 6.5.0 (https://coldcard.com/docs/upgrade/#edge-version-650xqx-musig2-miniscript-and-taproot-support) adds MuSig2 (https://bitcoinops.org/en/topics/musig/) signing support, BIP322 (https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki) proof of reserve capabilities, and additional miniscript (https://bitcoinops.org/en/topics/miniscript/) and taproot (https://bitcoinops.org/en/topics/taproot/) features including tapscript (https://bitcoinops.org/en/topics/tapscript/) support for up to eight leaves.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#frigate-1-4-0-released) Frigate 1.4.0 released: Frigate v1.4.0 (https://damus.io/nevent1qqsrg3xsjwpt4d9g05rqy4vkzx5ysdffm40qtxntfr47y3annnfwpzgpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhkummnw3ezummcw3ezuer9wcq3samnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmczyzl85553k5ew3wgc7twfs9yffz3n60sd5pmc346pdaemf363fuywvqcyqqqqqqgmgu9ev), an experimental Electrum server for silent payments (https://bitcoinops.org/en/topics/silent-payments/) scanning (see Newsletter #389 (https://bitcoinops.org/en/newsletters/2026/01/23/#electrum-server-for-testing-silent-payments)), 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.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#bitcoin-backbone-updates) Bitcoin Backbone updates: Bitcoin Backbone released (https://groups.google.com/g/bitcoindev/c/D6nhUXx7Gnw/m/q1Bx4vAeAgAJ) multiple updates (https://groups.google.com/g/bitcoindev/c/ViIOYc76CjU/m/cFOAYKHJAgAJ) adding BIP152 (https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) compact block (https://bitcoinops.org/en/topics/compact-block-relay/) support, transaction and address management improvements, and multiprocess interface groundwork (see Newsletter #368 (https://bitcoinops.org/en/newsletters/2025/08/22/#bitcoin-core-kernel-based-node-announced)). The announcement also proposes Bitcoin Kernel API extensions for standalone header verification and transaction validation.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#utreexod-0-5-released) Utreexod 0.5 released: Utreexod v0.5 (https://delvingbitcoin.org/t/new-utreexo-releases/2371) introduces IBD using SwiftSync (https://bitcoinops.org/en/newsletters/2025/04/11/#swiftsync-speedup-for-initial-block-download), reducing extra data downloaded from 1.4TB to 200GB. The release uses Floresta 0.9, a minimal utreexo (https://bitcoinops.org/en/topics/utreexo/) node implementation with an integrated Electrum server that uses assumeutreexo for fast setup.

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.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#bitcoin-core-31-0rc4) Bitcoin Core 31.0rc4 (https://bitcoincore.org/bin/bitcoin-core-31.0/test.rc4/) is a release candidate for the next major version of the predominant full node implementation. A testing guide (https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Candidate-Testing-Guide) is available.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#core-lightning-26-04rc3) Core Lightning 26.04rc3 (https://github.com/ElementsProject/lightning/releases/tag/v26.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

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#bitcoin-core-34401) Bitcoin Core #34401 (https://github.com/bitcoin/bitcoin/issues/34401) extends the btck_BlockHeader support added to the libbitcoinkernel C API (see Newsletters #380 (https://bitcoinops.org/en/newsletters/2025/11/14/#bitcoin-core-30595) and #390 (https://bitcoinops.org/en/newsletters/2026/01/30/#bitcoin-core-33822)) 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.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#bitcoin-core-35032) Bitcoin Core #35032 (https://github.com/bitcoin/bitcoin/issues/35032) stops storing network addresses learned when using the privatebroadcast option (see Newsletter #388 (https://bitcoinops.org/en/newsletters/2026/01/16/#bitcoin-core-29415)) with the sendrawtransaction RPC in addrman, Bitcoin Core’s peer address manager. The privatebroadcast option allows users to broadcast transactions through short-lived Tor (https://bitcoinops.org/en/topics/anonymity-networks/) or I2P connections, or through the Tor proxy to IPv4/IPv6 peers.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#core-lightning-9021) Core Lightning #9021 (https://github.com/ElementsProject/lightning/issues/9021) enables splicing (https://bitcoinops.org/en/topics/splicing/) by default by removing it from experimental status, following the merge of the splicing protocol into the BOLTs specification (see Newsletter #398 (https://bitcoinops.org/en/newsletters/2026/03/27/#bolts-1160)).

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#core-lightning-9046) Core Lightning #9046 (https://github.com/ElementsProject/lightning/issues/9046) increases the assumed final_cltv_expiry (the CLTV expiry delta (https://bitcoinops.org/en/topics/cltv-expiry-delta/) for the last hop) for keysend payments (https://bitcoinops.org/en/topics/spontaneous-payments/) from 22 to 42 blocks to match LDK’s value, restoring interoperability.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#ldk-4515) LDK #4515 (https://github.com/lightningdevkit/rust-lightning/issues/4515) switches zero-fee commitment (https://bitcoinops.org/en/topics/v3-commitments/) channels (see Newsletter #371 (https://bitcoinops.org/en/newsletters/2025/09/12/#ldk-4053)) from the experimental feature bit to the production feature bit. Zero-fee commitment channels replace the two anchor outputs (https://bitcoinops.org/en/topics/anchor-outputs/) with one shared Pay-to-Anchor (P2A) (https://bitcoinops.org/en/topics/ephemeral-anchors/) output, capped at a value of 240 sats.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#ldk-4558) LDK #4558 (https://github.com/lightningdevkit/rust-lightning/issues/4558) applies the existing receiver-side timeout for incomplete multipath payments (https://bitcoinops.org/en/topics/multipath-payments/) to keysend payments (https://bitcoinops.org/en/topics/spontaneous-payments/). Previously, incomplete keysend MPPs could remain pending until CLTV expiry, tying up HTLC (https://bitcoinops.org/en/topics/htlc/) slots instead of failing back after the normal timeout period.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#lnd-9985) LND #9985 (https://github.com/lightningnetwork/lnd/issues/9985) adds end-to-end support for production simple taproot channels (https://bitcoinops.org/en/topics/simple-taproot-channels/) with a distinct commitment type (SIMPLE_TAPROOT_FINAL) and production feature bits 80/81. Production uses optimized tapscripts (https://bitcoinops.org/en/topics/tapscript/) 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 (https://bitcoinops.org/en/topics/splicing/).

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#btcpay-server-7250) BTCPay Server #7250 (https://github.com/btcpayserver/btcpayserver/issues/7250) adds LUD-21 (https://github.com/lnurl/luds/blob/luds/21.md) support by introducing an optional unauthenticated endpoint named verify that allows external services to verify whether a BOLT11 (https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) invoice created via LNURL-pay (https://bitcoinops.org/en/topics/lnurl/) has been settled.

• ● (https://bitcoinops.org/en/newsletters/2026/04/17/#bips-2089) BIPs #2089 (https://github.com/bitcoin/bips/issues/2089) publishes BIP376 (https://github.com/bitcoin/bips/blob/master/bip-0376.mediawiki), which defines new PSBTv2 (https://bitcoinops.org/en/topics/psbt/) per-input fields to carry the BIP352 (https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki) tweak data needed to sign and spend silent payment (https://bitcoinops.org/en/topics/silent-payments/) outputs, plus an optional spend-key BIP32 (https://bitcoinops.org/en/topics/hd-key-generation/) derivation field compatible with BIP352’s 33-byte spend keys. This complements BIP375 (https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki), which specifies how to create silent payment outputs using PSBTs (see Newsletter #337 (https://bitcoinops.org/en/newsletters/2025/01/17/#bips-1687)).

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm (https://riverside.fm/studio/bitcoin-optech) at 16:30 UTC on April 21. The discussion is also recorded and will be available from our podcasts (https://bitcoinops.org/en/podcast/) page.

Reference: https://bitcoinops.org/en/newsletters/2026/04/17/

Write a comment

No comments yet.