Bitcoin Thursday — October 29, 2026

Bitcoin Core 32.1 arrives with security fixes, Lightning implementations harden their defenses, and a new layer-two proposal explores enforceable exits.

Welcome back to Bitcoin Thursday!

This week brings a real Bitcoin Core release, three coordinated security disclosures, additional Lightning fixes, and new research into trust-minimized off-chain payments.

The distinction between a tagged version, a release candidate, and a published production release matters particularly this week.

1. Bitcoin Core 32.1 is released—but 32.0 never was

Bitcoin Core 32.1 became available from the official download server on October 27, with the signed GitHub release following on October 28.

The version number requires an explanation. Bitcoin Core 32.0 was tagged on October 21, but last-minute problems prevented it from being fully announced or released. No official 32.0 production binaries were published. The developers moved directly to 32.1, combining the intended major release with additional corrections.

Bitcoin Core 32.1 introduces several operational changes:

• The default maximum number of connections increases from 125 to 200.
• Inbound transaction-relaying peers are limited to 50% of inbound slots by default, preserving capacity for block-relay-only peers.
• Block validation can prefetch previous outputs in parallel.
• A rebuilt transaction index can use less than half its previous disk space.
• Watch-only wallets can now be exported as wallet files.
• Tor services created automatically by Core can use Tor’s proof-of-work defenses.
• A private-broadcast privacy leak involving fallback connections from P2P v2 to v1 has been corrected.

Versions 29.x and older are now considered end-of-life, even though 29.5 received the emergency security corrections described below.

What it means for node operators: Download only from the official Bitcoin Core site and verify signatures or checksums. Operators using a managed platform such as Umbrel should normally wait for that platform’s tested update instead of manually replacing its bundled bitcoind.

Sources: Bitcoin Core 32.1 announcement · Complete Bitcoin Core 32.1 release notes · Official signed downloads

Bitcoin meme of the week

Bitcoin Core 32.0: almost there.
32.1: “Let me fix that before you click.”

2. Coordinated releases fix three Bitcoin Core vulnerabilities

On October 28, the Bitcoin Core project publicly disclosed three vulnerabilities fixed in versions 29.5, 30.4, 31.2, and 32.1.

Remote memory exhaustion on non-Linux nodes

A malicious peer could send specially handled TCP urgent data and bypass Bitcoin Core’s normal memory backpressure.

The vulnerability affected the networking backend used on Windows, macOS, and BSD, but not Linux. According to the disclosure, an attacker connected to a vulnerable node could trivially increase memory consumption until it crashed.

Slow memory growth through obsolete peers

A peer pretending not to support BIP31 ping messages could remain paused indefinitely while Bitcoin Core continued adding transaction announcements to its outgoing queue.

Memory could grow by up to approximately 2 MB per hour for each inbound malicious peer and 5 MB per hour for each outbound peer. Nodes running in -blocksonly mode were less exposed.

Undo-file overflow under extreme conditions

A miner could theoretically create blocks with extremely large undo data, eventually overflowing the file-position format. Depending on the platform, this could corrupt undo data or make a node shut down repeatedly.

The project classifies this issue as low severity and says exploiting it on ordinary 64-bit nodes would be impractical because it would require several thousand specially constructed mined blocks and an extremely specific reorganization.

The fix does not fully protect 32-bit systems or nodes storing block data on FAT32.

All three issues were discovered through automated analysis conducted by Project Loupe, led by Elias Rohrer at Spiral, and were validated and reported to the Bitcoin Core team by Gregory Sanders. The undo-file and paused-peer issues were also independently reported by other researchers, including L0rinc and Andrew Dorman. Antoine Poinsot authored the coordinated fixes.

There is no claim in the disclosures that these vulnerabilities changed Bitcoin’s consensus rules or created bitcoin from nothing.

Why it matters: Nodes exposed to arbitrary internet peers should run a patched, supported release. Windows and macOS operators have the most immediate reason to update because of the TCP memory-exhaustion vulnerability.

Sources: TCP urgent-data memory vulnerability · Paused-peer memory vulnerability · Undo-file overflow disclosure

3. Eclair fixes two vulnerabilities that could put funds at risk

Further details are now public about security fixes included in Eclair 0.14.5.

One vulnerability allowed a malicious payer to manipulate the expiry timing of a trampoline payment. Under the right conditions, the payer could reclaim an incoming HTLC after it expired while the recipient still claimed the outgoing HTLC, leaving the forwarding Eclair node with the loss.

Another vulnerability affected splicing of simple Taproot channels. A malicious peer could provide false information about a transaction input and convince Eclair to sign a splice transaction that could never confirm. The peer could then exploit the mismatch between the old and supposedly new channel states to claim a payment after Eclair’s matching incoming HTLC had already been refunded.

Eclair now preserves the required HTLC expiry ordering and verifies claimed Taproot inputs against its Bitcoin backend before signing.

These findings explain why ACINQ strongly recommended upgrading to 0.14.5 in last week’s release. They describe exploitable conditions, but the reviewed sources do not report confirmed widespread theft.

Why it matters: Eclair operators should run 0.14.5 or newer. These are implementation vulnerabilities; they do not apply automatically to LND, Core Lightning, or LDK.

Sources: Eclair 0.14.5 release · Eclair trampoline-routing fix · Eclair Taproot-splicing fix · Bitcoin Optech Newsletter #428

4. New LND maintenance releases enter testing

LND 0.21.5-beta.rc1 and 0.20.6-beta.rc1 were announced as release candidates for upcoming maintenance versions.

The candidates contain fixes for commitment feerates, fee-update handling, excessive memory allocation when parsing TLV data, channel-message limits, and SQL database deadlocks.

Version 0.21.5 also includes a fix for auxiliary HTLC-signature validation in Taproot Assets channels and improves wallet synchronization during blockchain reorganizations.

These are release candidates, not final production releases.

What it means: Experienced operators can help test them. Everyone else should monitor the final releases and the update process provided by their node platform. Operators still running the 0.20 branch should note that a corresponding 0.20.6 maintenance update is being prepared.

Source: Bitcoin Optech Newsletter #428

5. LND experiments with local protection against channel jamming

LND has added an experimental local reputation system intended to reduce the impact of channel-jamming attacks.

The system evaluates outgoing channels using their previous forwarding behavior and advertised fees. Accountable HTLCs that take unusually long to resolve can lower a channel’s reputation.

For now, the feature operates in observation mode: it records whether an HTLC would receive protected resources but does not change forwarding decisions. Reputation is also reset whenever the node restarts.

Why it matters: Channel jamming remains a difficult Lightning problem. Running the system in observation mode allows developers to collect operational evidence before it begins affecting real payments.

Source: LND PR #10919 · Bitcoin Optech’s explanation

6. Lichen proposes a layer two with enforceable exits

Adam Gibson has published a paper and proof-of-concept for Lichen, a proposed single-issuer layer-two system.

Users would lock bitcoin in individual 2-of-2 contracts with a hub and receive matching tokens on an off-chain ledger. If the hub cooperates, exiting is a normal joint settlement. If it refuses or disappears, a user could attempt to enforce the exit on-chain using a cryptographic proof and a BitVMX dispute process.

The proposal improves on Gibson’s earlier LN-GAP design by removing its honest-majority attestation committee. However, it does not remove all trust. A dishonest sequencer could omit a user’s returned tokens or sign an invalid state, potentially costing the user or hub money. Tokens received above a negotiated liquidity cap also lack the same guaranteed redemption.

Why it matters: Lichen is research and proof-of-concept code—not a live Bitcoin service, fork, or consensus proposal. It explores how a centrally operated payment system might offer stronger exit guarantees without requiring changes to Bitcoin.

Sources: Adam Gibson’s original Lichen announcement · Bitcoin Optech Newsletter #428

This week’s perspective

The most practical action this week is straightforward: check which Bitcoin Core version your node platform currently supplies and watch for its supported update.

The wider lesson is that responsible disclosure works. Researchers found serious edge cases, developers coordinated fixes across maintained versions, and details were published once updates were available.

Research projects such as Lichen remain interesting, but they should be judged by their remaining trust assumptions—not only by the word “layer two.”

Are you already running Bitcoin Core 32.1, waiting for your node platform’s update, or staying on a patched older branch for now?

---

Bitcoin Thursday follows the technology behind the headlines.

There is no order without chaos!

^{Vote for the BBH Witness}

^{[email protected]}


Images and screenshots are from me or AI generated

_{Posted via HiveSuite}