BitDevs 32_

Released October 27. Due to "last-minute issues," 32.0 was never announced, so 32.1 is the first release in the 32.x series. Highlights: estimatesmartfee now also runs a mempool-based estimator and returns the lower of the two results; PSBT RPCs default to PSBTv2; new exportwatchonlywallet, addhdkey, and derivehdkey RPCs; send and sendall are no longer experimental; default -maxconnections rises from 125 to 200; libevent is replaced by a custom HTTP server; and inputs are prefetched in parallel for faster block validation. It also fixes a -walletnotify command injection triggered by crafted wallet names. 29.x is now end of life.

The most important process change this month. Core has always preferred long embargoes and shipped fixes in the next major release, because users upgrade slowly. Poinsot writes that there are now more reports of bugs "that can be easily (re-)discovered … largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes." When a bug is flagged as easy to find, for example one "found with a simple prompt to an LLM," Core will now backport the fix to every maintained release, ship as soon as possible, and publish an advisory with it. That is why 29.5, 30.4, 31.2, and 32.1 all shipped within a day of each other. Discussion hook: when anyone can point a model at a security patch and work backward to the bug, how long can any project's embargo really last?

The same trend, seen from a merchant tool. The release fixes 85 findings (1 critical, 13 high, 52 medium, 19 low), and the maintainers thank the OSS Scanner program for "providing reproducers and proposed fixes." Many fixes stop one store from reading or changing another store's data on a shared server, so anyone hosting several merchants should upgrade first. Discussion hook: 85 findings in one pass is good news for BTCPay users, but attackers can run the same scanners. Who scans the projects that nobody volunteers to scan?

The bug was in the Linux kernel, not in LND. The oss-security disclosure showed remote code execution through Multipath TCP (MPTCP). Since Go 1.24, listeners turn on MPTCP by default, so every LND node on Linux was exposed. LND v0.21.6 and v0.20.7 turn MPTCP off. Operators should also patch their kernel, and they can protect older binaries with GODEBUG=multipathtcp=0. Discussion hook: your node software is only as secure as its language runtime and the kernel underneath it.

Medium severity, rated "easily discoverable," and found by an automated LLM scan (Elias Rohrer's Project Loupe at Spiral). Core stops reading from a peer whose message queue grows too large. On non-Linux systems, however, the node kept listening for "exceptional" socket events, and handling one triggered another read. By sending TCP out-of-band data, an attacker could skip the pause and fill memory until the node crashed. Linux was not affected. It was reported October 23, fixed and backported October 26, and every branch was released by October 28. That is five days from report to disclosure, under the new policy.

A peer claiming a protocol version from before ping/pong existed was exempt from ping timeouts, so it could keep a connection open while queued transaction announcements slowly grew. Patched nodes now disconnect any peer whose send buffer stays over its limit for 20 minutes, whatever version it claims.

Undo data (what a node needs to roll back a block during a reorg) used 32-bit file offsets. Past 4 GiB the offset wraps around and overwrites earlier data, so a later reorg could halt the node. The advisory calls exploitation impractical. It is a good example of an "easy to find, hard to exploit" bug that still gets the fast-backport treatment.

The most relatable disclosure of the month, especially if you run a node-in-a-box. Inbound Tor connections appear to come from the local Tor daemon, usually 127.0.0.1 or a LAN address. Popular node bundles ship Core and Tor together with a -whitelist range covering that address, so every anonymous Tor peer got trusted-peer permissions, which "lifts various DoS limits and privacy leak mitigations." The result was "thousands of reachable mainnet nodes whitelisting all incoming Tor connections." It was fixed in 28.3, 29.2, and 30.0 (October 2025) and disclosed November 10, once 29.x reached end of life. Discussion hook: the bug only existed because of a reasonable-looking default in someone else's packaging. Who audits the node bundles?

TRUC (v3) transactions may have only one unconfirmed child in the mempool, but blocks don't enforce that rule. When a reorg puts transactions back into the mempool, mempool rules are meant to be skipped, but "sibling eviction" still ran. It could evict a parent while leaving its children behind, so the mempool held transactions spending outputs that no longer existed. Every block template then failed its validity check until the node restarted. Affected versions were 28.0–28.2 and 29.0–29.1. Credit goes to Niklas Gögge.

Core cleared its download state for a compact block before checking the witness for tampering. A malicious peer could announce a block first, send a malleated version, and then ignore the node's request for the full block, which stalled the node for up to 10 minutes each time. The attack repeats indefinitely if the attacker controls all three of the victim's high-bandwidth peers or the victim runs -blocksonly. Reported by Eugene Siegel and fixed in 29.2 and 30.0.

A good story about parser disagreement. Attackers built BOLT 11 invoices with multiple payment hashes, which LNP2PBot's parser and its Lightning node read differently. That let them collect duplicate payouts. The spec now requires readers to reject any invoice that doesn't have exactly one p and one s field, and LND added the same check (#11357). Discussion hook: when two programs parse the same bytes differently, which one is "right"? The answer is whichever one the attacker picks.

Core Lightning 25.02 through 26.04 crashed on a channel announcement that listed the same node as both endpoints. CLN saved gossip to disk before loading it into memory, so the node crashed again on every restart until an operator removed the record by hand. The only cost to the attacker was onchain fees. It was found with a fuzzer, fixed in 26.04.1 within two days of the report, and disclosed in October.

Both projects had a run of security releases this month. CLN fixed flaws in dual funding, splicing, onchain HTLC handling, and access controls, and is holding back its exploit tests to give users time to upgrade. Eclair 0.14.4 through 0.14.6 patched splicing and on-the-fly funding bugs, including a trampoline fund-theft bug (#3409): a payer could supply route hints with expiry deltas so large that the outgoing HTLC outlived the incoming one. Discussion hook: splicing and on-the-fly funding are where most of these bugs live. Is that the cost of new features, or a sign they shipped too early?

The goal: a Lightning node where a thief has to compromise K of your N devices to steal funds, like onchain multisig. Splitting the signing is the easy part. Revocation is the hard part, because the secrets that cancel old channel states come from a chain that can't be split among signers. This month someone posted working lnd and CLN implementations, and on November 12 another proposal used threshold ECDSA to avoid any spec change. Skip the math and focus on the question: why is "multisig Lightning" so much harder than multisig onchain?

A practical thread anyone can weigh in on. Gem Wallet asked what to do when exchanges still reject valid bc1p addresses. sipa said wallets "should absolutely tell people to use P2TR by default at this point." murch pointed to whentaproot.org for compatibility lists and warned against letting "a few laggards" hold adoption hostage. Others argued that P2WPKH is good enough for ordinary users. Discussion hook: almost five years after Taproot activated, does your wallet default to it? Has an exchange ever rejected your bc1p address?

0xB10C wants two home nodes that can't accept inbound connections to reach each other by opening connections at the same moment. That would make more honest nodes reachable. Anthony Towns and others questioned whether it helps, since it may also make home nodes easier for attackers to reach. Discussion hook: most of the room runs a node behind a home router. Would you want this turned on?

A coda to the BIP-110 fight. satd now lets an operator delete OP_RETURN data from stored blocks once they are at least 288 blocks deep. It doesn't change consensus, and it can be undone by re-downloading the blocks. The author thinks the storage cost is "negligible currently," but argues that letting operators act on their own preferences could head off "future distracting controversies." Discussion hook: if you can just delete the data you object to, was the consensus fight ever necessary?

A coinbase transaction can only pay a limited number of miners directly, so a decentralized pool has to choose who gets paid in each block. The thread asks how to keep a large miner from splitting into many identities to crowd out small ones (the "Rich List Attack"). A former P2Pool operator used historical data to show that growth alone squeezed out small miners. Steven Roose said nothing good works without covenants, while Ark-style payouts could group many users into one output. jungly used Ocean data to suggest P2Poolv2 may cap outputs at around 16.

Without covenants, many projects imitate them with a co-signer that only signs transactions following certain rules. This draft proposes one standard format for those rules, so wallets, co-signers, and oracles from different projects can work together. Reviewers asked for a "finality" flag and policy hashes that pin exact verifier behavior, and the author accepted both. Discussion hook: a standard for "trust me to enforce a covenant" is useful. Does it make an actual covenant soft fork more urgent or less?

Not a debate, just a useful tool. learnbitcoin.com/archive mirrors the whole bitcoin-dev list with one page per thread, folded quotes, permanent links, and indexes by topic, BIP, author, and year. It updates twice a day. Bookmark it before your next "what did Satoshi actually say about…" argument.