/ home / newsletters /
Bitcoin Optech Newsletter #378
This week’s newsletter announces four vulnerabilities affecting older versions of the Bitcoin Core full node. Also included are our regular sections summarizing popular questions and answers from the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.
News
-
● Disclosure of four low-severity vulnerabilities in Bitcoin Core: Antoine Poinsot recently posted to the Bitcoin-Dev mailing list four Bitcoin Core security advisories for low-severity vulnerabilities that were fixed in Bitcoin Core 30.0. According to the disclosure policy (see Newsletter #306), a low-severity vulnerability is disclosed two weeks after the release of a major version containing the fix. The four disclosed vulnerabilities are the following:
-
● Disk filling from spoofed self connections: This bug would allow an attacker to fill up the disk space of a victim node by faking self-connections. The vulnerability was disclosed responsibly by Niklas Gögge in March 2022. Eugene Siegel and Niklas Gögge merged a mitigation in July 2025.
-
● Disk filling from invalid blocks: This bug would allow an attacker to fill up the disk space of a victim node by repeatedly sending invalid blocks. This bug was disclosed responsibly by Niklas Gögge in May 2022 and also independently by Eugene Siegel in March 2025. Eugene Siegel and Niklas Gögge merged the mitigation in July 2025.
-
● Highly unlikely remote crash on 32-bit systems: This bug may cause a node to crash when receiving a pathological block in a rare edge case. This bug was disclosed responsibly by Pieter Wuille in April 2025. Antoine Poinsot implemented and merged the mitigation in June 2025.
-
● CPU DoS from unconfirmed transaction processing: This bug would cause resource exhaustion when processing an unconfirmed transaction. This bug was reported to the mailing list by Antoine Poinsot in April 2025. Pieter Wuille, Anthony Towns, and Antoine Poinsot implemented and merged the mitigation in August 2025.
Patches for the first three vulnerabilities have also been included in Bitcoin Core 29.1 and later minor releases.
-
Selected Q&A from Bitcoin Stack Exchange
Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.
-
● Why was -datacarriersize redefined in 2022, and why was the 2023 proposal to expand it not merged? Pieter Wuille provides a historical overview of the scope of Bitcoin Core’s
-datacarriersizeoption in relation toOP_RETURNoutputs. -
● What is the smallest valid transaction that can be included in a block? Vojtěch Strnad enumerates the minimum fields and sizes that would comprise the smallest possible valid Bitcoin transaction.
-
● Why does Bitcoin Core continue to give witness data a discount even when it is used for inscriptions? Pieter Wuille explains the rationale for segwit’s witness discount and emphasizes that the Bitcoin Core software implements Bitcoin’s current consensus rules.
-
● The ever-growing Bitcoin blockchain size? Murch notes the current UTXO set size, storage requirements for pruned and full nodes, and points out the current rate of growth of the Bitcoin blockchain.
-
● I read that OP_TEMPLATEHASH is a variant of OP_CTV. How do they differ? Rearden contrasts the capabilities, efficiency, compatibility, and which fields are hashed, between OP_CHECKTEMPLATEVERIFY and the recently proposed
OP_TEMPLATEHASHproposal (see Newsletter #365).
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.
-
● LND 0.20.0-beta.rc1 is a release candidate for this popular LN node. One improvement that would benefit from testing is the fix for premature wallet rescanning, described in the notable code changes section below. See the release notes for more details.
-
● Eclair 0.13.1 is a minor release of this LN node implementation. This release contains database changes to prepare for the removal of pre-anchor output channels. You will need to run the v0.13.0 release first to migrate your channel data to the latest internal encoding.
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 #29640 reinitializes
nSequenceIdvalues at startup for blocks on competing chains with the same amount of work: 0 for blocks belonging to the previously known best chain, and 1 for all other loaded blocks. This resolves an issue where Bitcoin Core couldn’t perform a tiebreak between two competing chains because thenSequenceIdvalue didn’t persist across restarts. -
● Core Lightning #8400 introduces a new BIP39 mnemonic backup format for the
hsm_secretwith optional passphrase for all new nodes by default, while keeping support for legacy 32-bytehsm_secretson existing nodes.Hsmtoolis also updated to support both mnemonic-based and legacy secrets. A new standard taproot derivation format is introduced for wallets. -
● Eclair #3173 removes support for legacy channels that don’t use anchor outputs or taproot, also known as
static_remotekeyordefaultchannels. Users should close any remaining legacy channels before upgrading to version 0.13 or 0.13.1. -
● LND #10280 now waits for the headers to sync before starting the chain notifier (see Newsletter #31) to rescan the chain for wallet transactions. This resolves an issue in which LND would trigger a premature rescan while the headers were still syncing when a new wallet was created. This primarily affected Neutrino backends.
-
● BIPs #2006 updates BIP3’s specification (see Newsletter #344) by adding guidance on originality and quality, particularly advising authors against generating content with AI/LLMs, and encouraging the proactive disclosure of AI/LLM usage.
-
● BIPs #1975 updates BIP155 which specifies addr v2, a new version of the
addrmessage in the Bitcoin P2P network protocol, by adding a note that Tor v2 is no longer operational.
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 November 4. The discussion is also recorded and will be available from our podcasts page.