This week’s newsletter announces the responsible disclosure of a vulnerability that allowed a remote peer to crash Core Lightning nodes and links to transcripts from a recent Bitcoin Core developer meeting. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software.

News

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#core-lightning-assertion-dos-disclosure) Core Lightning assertion DoS disclosure: Chandra Pratap posted (https://delvingbitcoin.org/t/vulnerability-disclosure-assertion-dos-in-core-lightning/2507) to Delving Bitcoin disclosing a denial-of-service vulnerability discovered during a Summer of Bitcoin 2025 internship. The vulnerability affected Core Lightning nodes that accept incoming channels.

During the channel-opening handshake, a remote peer sends a message

containing the txid of the proposed funding transaction. Core Lightning performed an assertion check requiring a non-zero txid. When a peer sent an all-zero txid instead, the assertion failed and crashed the node. Since any peer can initiate a channel-opening handshake and send the malicious message, this allowed a remote attacker to reliably crash any vulnerable node that accepted inbound channels.

The vulnerability was responsibly disclosed (https://bitcoinops.org/en/topics/responsible-disclosures/)

and discovered through fuzzing. At the time of the report, Rusty Russell had independently been working on a separate crash bug and his fix incidentally resolved this vulnerability as well. The vulnerability was fixed in Core Lightning 26.04 (https://bitcoinops.org/en/newsletters/2026/04/24/#core-lightning-26-04).

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#bitcoin-core-developer-meeting-transcripts) Bitcoin Core developer meeting transcripts: many Bitcoin Core developers met in person in May, and transcripts from the meeting have been published (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05). Topics included SwiftSync (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/swiftsync), post-cluster mempool (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/post-cluster-mempool), an Erlay redesign (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/erlay-redesign), package relay (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/package-relay), silent payments (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/silent-payments), TCP hole punching (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/tcp-holepunch) (see Newsletter #406 (https://bitcoinops.org/en/newsletters/2026/05/22/#tcp-hole-punching-for-bitcoin-nodes-behind-nats)), private broadcast (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/private-broadcast), a modern crypto library (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/modern-crypto-library), and mutation testing (https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/mutation-testing), among others.

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/05/29/#eclair-v0-14-0) Eclair v0.14.0 (https://github.com/ACINQ/eclair/releases/tag/v0.14.0) is the latest release of this popular LN node implementation. It includes the final versions for splicing (https://bitcoinops.org/en/topics/splicing/), simple taproot channels (https://bitcoinops.org/en/topics/simple-taproot-channels/), and zero-fee commitments (https://bitcoinops.org/en/topics/v3-commitments/), removes support for non-anchor output (https://bitcoinops.org/en/topics/anchor-outputs/) channels, and adds experimental peer scoring for liquidity and routing optimization.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#core-lightning-26-06rc2) Core Lightning 26.06rc2 (https://github.com/ElementsProject/lightning/releases/tag/v26.06rc2) is a release candidate for the next major version of this popular LN node which includes new graceful, sendamount, and xkeysend RPCs, begins the pay deprecation cycle in favor of xpay, and adds BOLT12 (https://bitcoinops.org/en/topics/offers/) payer-proof RPC support.

Notable code and documentation changes

Notable recent changes in Bitcoin Core (https://github.com/bitcoin/bitcoin), Core Lightning (https://github.com/ElementsProject/lightning), Eclair (https://github.com/ACINQ/eclair), LDK (https://github.com/lightningdevkit/rust-lightning), LND (https://github.com/lightningnetwork/lnd/), libsecp256k1 (https://github.com/bitcoin-core/secp256k1), Hardware Wallet Interface (HWI) (https://github.com/bitcoin-core/HWI), Rust Bitcoin (https://github.com/rust-bitcoin/rust-bitcoin), BTCPay Server (https://github.com/btcpayserver/btcpayserver/), BDK (https://github.com/bitcoindevkit/bdk), Bitcoin Improvement Proposals (BIPs) (https://github.com/bitcoin/bips/), Lightning BOLTs (https://github.com/lightning/bolts), Lightning BLIPs (https://github.com/lightning/blips), Bitcoin Inquisition (https://github.com/bitcoin-inquisition/bitcoin), and BINANAs (https://github.com/bitcoin-inquisition/binana).

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#bitcoin-core-33966) Bitcoin Core #33966 (https://github.com/bitcoin/bitcoin/issues/33966) refactors the way it handles mining block template options for the Mining IPC interface (See Newsletters #310 (https://bitcoinops.org/en/newsletters/2024/07/05/#bitcoin-core-30200) and #323 (https://bitcoinops.org/en/newsletters/2024/10/04/#bitcoin-core-30510)). Previously, startup mining options such as blockmaxweight, blockreservedweight, and blockmintxfee were handled separately from the runtime options passed by IPC mining clients. Now, these options are parsed into a shared BlockCreateOptions object and merged when creating or updating block templates. Invalid combinations, such as a reserved block weight that exceeds the maximum block weight, are now rejected instead of being silently adjusted to a valid range value.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#bitcoin-core-34917) Bitcoin Core #34917 (https://github.com/bitcoin/bitcoin/issues/34917) stops returning the deprecated bip125-replaceable field in wallet transaction RPCs listtransactions, listsinceblock, and gettransaction, though users can still request the field with the -deprecatedrpc=bip125 option. The PR also deprecates the -walletrbf startup option, which now emits a warning and is scheduled for removal in the next release. See Newsletter #403 (https://bitcoinops.org/en/newsletters/2026/05/01/#bitcoin-core-34911) for previous removal of RBF (https://bitcoinops.org/en/topics/replace-by-fee/)-related fields.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#bitcoin-core-35017) Bitcoin Core #35017 (https://github.com/bitcoin/bitcoin/issues/35017) updates the package (https://bitcoinops.org/en/topics/package-relay/) transaction submission process to prevent later transactions from remaining in the mempool after an unexpected validation failure. During package submission, transactions are processed sequentially, allowing later transactions to spend earlier ones that have already been added to the mempool. Previously, if one transaction failed a late validation check (such as a consensus script check), Bitcoin Core would only remove that transaction. Now, it also removes all subsequent transactions in the package, preventing children from remaining in the mempool after a parent has been removed.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#bips-1944) BIPs #1944 (https://github.com/bitcoin/bips/issues/1944) adds BIP449 (https://github.com/bitcoin/bips/blob/master/bip-0449.md), a draft soft fork proposal for OP_TWEAKADD, a tapscript (https://bitcoinops.org/en/topics/tapscript/) opcode for computing a tweaked x-only public key (see Newsletter #370 (https://bitcoinops.org/en/newsletters/2025/09/05/#draft-bip-for-op-tweakadd)). Given a 32-byte x-only public key and a 32-byte scalar tweak, the opcode pushes the x-only key for P + tG. This would allow scripts to directly verify key-tweak relationships, enabling constructions such as tweak-reveal scripts, proof of signing order, and signing delegation (https://bitcoinops.org/en/topics/signer-delegation/) protocols.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#bips-2108) BIPs #2108 (https://github.com/bitcoin/bips/issues/2108) adds BIP450 (https://github.com/bitcoin/bips/blob/master/bip-0450.mediawiki), Formosa, a draft specification for encoding BIP39 (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)-compatible wallet entropy as story-like mnemonic phrases. Instead of using random BIP39 words, Formosa uses theme-defined word lists to encode entropy, producing short, structured sentences. These stories can be decoded back into the original entropy and converted into a standard BIP39 mnemonic before seed derivation, thus preserving compatibility with BIP39.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#eclair-3192) Eclair #3192 (https://github.com/ACINQ/eclair/issues/3192) adds experimental support for zero-fee commitment (https://bitcoinops.org/en/topics/v3-commitments/) (0FC) channels, following the specification covered in Newsletter #404 (https://bitcoinops.org/en/newsletters/2026/05/08/#bolts-1228). The feature is disabled by default and can be enabled with eclair.features.zero_fee_commitments = optional.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#ldk-4584) LDK #4584 (https://github.com/lightningdevkit/rust-lightning/issues/4584) adds payment_metadata maps to BOLT12 (https://bitcoinops.org/en/topics/offers/) blinded message and payment path contexts. This adds the plumbing to carry recipient-side metadata through blinded paths (https://bitcoinops.org/en/topics/rendez-vous-routing/) and recover it when the payment is received, similar to BOLT11 (https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md)’s payment_metadata. Building offers with metadata is not yet supported. The metadata is stored as a map from numeric keys to byte arrays, allowing multiple independent pieces of data to be attached to the same payment.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#ldk-4628) LDK #4628 (https://github.com/lightningdevkit/rust-lightning/issues/4628) starts encrypting BOLT11 (https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) payment_metadata when creating inbound payments, building on the metadata commitment covered in Newsletter #405 (https://bitcoinops.org/en/newsletters/2026/05/15/#ldk-4528). After verifying the payment, LDK decrypts the metadata, enabling applications to access invoice metadata without exposing it to the payer or implementing encryption themselves.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#lnd-10552) LND #10552 (https://github.com/lightningnetwork/lnd/issues/10552) adds a fast initial sync for Neutrino (https://bitcoinops.org/en/topics/compact-block-filters/)-backed LND nodes by allowing them to import prebuilt Bitcoin block headers and compact filters from local files or HTTP(S) sources before resuming normal P2P sync. The new neutrino.blockheaderssource and neutrino.filterheaderssource options must be configured together. Imported headers are validated locally, and then Neutrino fetches any headers after the imported tip from network peers.

• ● (https://bitcoinops.org/en/newsletters/2026/05/29/#lnd-10820) LND #10820 (https://github.com/lightningnetwork/lnd/issues/10820) prevents LND from implicitly selecting simple taproot channels (https://bitcoinops.org/en/topics/simple-taproot-channels/) when opening public channels because taproot channel announcements (https://bitcoinops.org/en/topics/channel-announcements/) are not yet supported. Previously, if both peers advertised support for this type of channel, LND could select it and then reject the open. Now, simple taproot channels must be explicitly requested, while implicit negotiation can still select legacy, static remote key, or anchor (https://bitcoinops.org/en/topics/anchor-outputs/) channel types. The PR also updates lncli openchannel –channel_type=taproot to select the production simple taproot channel type.

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 June 2. The discussion is also recorded and will be available from our podcasts (https://bitcoinops.org/en/podcast/) page.