Funding Bitcoin node security, testing, and maintenance @bitcoinbrink Blocking and tackling at @bitcoinoptech
Joined September 2018
- Tweets2.8K
- Following909
- Followers6.4K
- Likes12.8K
BIP54 updates from the last several months of Consensus Cleanup work
Implementation progress:
Bitcoin Core: github.com/bitcoin/bitcoin/p… (open) implements BIP54's rules without mainnet activation. Needs reviewers.
libbitcoin: github.com/libbitcoin/libbit… (merged)
rbitcoin: github.com/reardencode/rbitc… (draft, signet)
btcd: github.com/btcsuite/btcd/pul… (draft)
Research: Pieter Wuille published a proof, machine-checked in Lean, that BIP54's two timestamp rules together bound chain length for a given amount of work. delvingbitcoin.org/t/bounds-…
64-byte txs: Jeremy Rubin argued they may have legitimate uses (groups.google.com/g/bitcoind…) and wrote up an alternative that invalidates merkle internal nodes instead (groups.google.com/g/bitcoind…). BIP54's rationale now acknowledges that option but still prefers the simple ban.
BIP54 tracker for forward-compatibility for miner coinbase locktimes: mainnet.observer/charts/tran…
Other discussions:
Antoine Riard's response to Mark Friedenbach's objection that fixing timewarp forecloses forward blocks groups.google.com/g/bitcoind…
An idea to split BIP54 into one BIP per fix, which the authors declined github.com/bitcoin/bips/pull…
Testnet5 (BIP95): enforces BIP54 from block 1 groups.google.com/g/bitcoind…
bip54.org/ is updated to reflect these.
@TheBlueMatt had a good chat about BIP54 recently:
xitter.twitterapi.xyz/MARAFoundation_/status…
Bitcoin’s Next Soft Fork: Quantum or the Great Consensus Cleanup? | MATT CORALLO
🔗 YouTube: youtube.com/watch?v=8H95SW7e…
🌿 Spotify: open.spotify.com/episode/6l7…
Following years of community gridlock post-Taproot, there’s growing confidence among experts that Bitcoin's next soft fork will be a low-controversy effort to address four long-standing consensus-level bugs through the activation of BIP 54, a.k.a. the “Great Consensus Cleanup.”
Originally put forward by today’s guest, Matt Corallo (@TheBlueMatt), and more recently revised by Antoine Poinsot (@darosior), the upgrade addresses the “cruft” of Bitcoin’s design — including edge-case vulnerabilities like certain kinds of poison blocks, time warp attacks, and others.
At the same time, developer resources are rapidly moving towards quantum resistance proposals for Bitcoin — including BIP 360 (co-authored by Hunter Beast, Ethan Heilman, and Head of MARA Foundation Isabel Foxen Duke) and the recently circulated “SHRINCs” signature proposal by the @blksresearch team and collaborators like Heilman (@Ethan_Heilman) and @conduition_io.
This episode of MFTV breaks down the Great Consensus Cleanup and the post-quantum output type debate — shedding light on key challenges of Bitcoin governance along the way.
TIMESTAMPS:
🧹 01:33 Introducing the “Great Consensus Cleanup”
🧪 11:08 Bug 1: “Poison Blocks”
⏳ 18:01 Bug 2: Time warp attacks
🌲 26:19 Bug 3: Merkle tree malleability
🪙 34:16 Bug 4: Duplicate coinbase transactions
⛏️ 43:37 The limits of Stratum V1
🌐 52:24 How SV2 influences decentralization
🔑 01:07:11 Deployment of post-quantum cryptography
🏷️ 01:10:44 Comparing P2MR and P2TRv2
🛡️ 01:23:30 P2QR and the post-quantum trade-offs
⚛️ 01:33:45 The impact of Google’s Willow milestone
Optech goes Brady Bunch mode
Elias Rohrer (@_tnull), Greg Sanders (@theinstagibbs), Antoine Poinsot (@darosior), Oleksandr Kurbatov (@olkurbatov), and Nishant Bansal (@nishant282003) joined Optech to discuss Newsletter #429:
News
● Silent payments for multiparty wallets (41:18)
● CLN self-referential channel announcement DoS disclosure (52:57)
● Bitcoin Core security policy update (24:53)
Selected Q&A from Bitcoin Stack Exchange
● Why does Bitcoin use both a transaction ID and a witness transaction ID? (1:02:58)
● How to sign a MuSig with Bitcoin Core (1:07:54)
● What changed in Bitcoin P2P protocol version 70017 compared to 70016? (1:09:11)
Releases and release candidates
● Bitcoin Core 32.1 (35:56)
● Bitcoin Core 31.2 (39:18)
● Bitcoin Core 30.4 (40:42)
● Bitcoin Core 29.5 (40:53)
● Eclair 0.14.6 (1:12:37)
● LND v0.21.5-beta (1:13:36)
Notable code and documentation changes
● Bitcoin Core #36665 (3:43)
● Bitcoin Core #36667 (14:37)
● Bitcoin Core #36669 (19:02)
● BIPs #2130 (1:15:55)
● Core Lightning #9627 (1:17:33)
● Eclair #3417 (1:19:13)
● Eclair #3416 (1:26:02)
● LDK #5314 (1:28:48)
● LDK #5412 (1:31:27)
● LND #11164 (1:33:28)
● LND #11373 (1:36:17)
● BTCPay Server #7744 (1:38:59)
Bitcoin Core v32.1 shipped this week. Over 200 of the changes in the release were testing related (185 PRs “Tests”, 47 “Fuzzing”).
Test related PRs are the most common type of PR in Bitcoin Core. What “testing” covers in and around Core:
- Manual testing where reviewers build and run PRs and think hard while trying to break things
- Unit tests
- Functional tests. Python scripts that drive actual bitcoind nodes.
- Fuzz tests that run around the clock by Fuzzor (Brink’s infra) and by Google’s OSS-Fuzz.
- Sanitizers
- Differential fuzzing. Bitcoinfuzz feeds the same inputs to Core and other implementations and flags anomalies.
- Full system fuzzing. Fuzzamoto fuzzes production binaries over P2P and RPC with no changes to Core.
- Mutation testing. bcore-mutation breaks the code on purpose to check whether the tests notice.
- Network simulation. Warnet can run hundreds of nodes to test how changes behave across a whole network.
- And in the last year, LLM assisted review and security scans.
Additionally, full network simulation using Antithesis that tests multiple nodes interacting under randomized, reproducible conditions.
Bitcoin Core has accumulated over a century of CPU time fuzzing individual functions and critical components.
This all helps Bitcoin Core’s software quality assurance, but it doesn’t just benefit Core. @dergoegge + @macrohead7's fuzzing infra found a chain split bug in btcd. Fuzzamoto has since found three more btcd bugs, and @rbitcoin_org's release notes credit Niklas for findings there.
@brunoerg’s Bitcoinfuzz has reported bugs in libbitcoin, rust-bitcoin, rust-miniscript, LND, Core Lightning, Eclair, LDK and others.
Tests are a lot of the work and also what goes unnoticed when it goes right.
Shoutout to the testers 🧡
More on Bitcoin Core v32.1:
xitter.twitterapi.xyz/bitschmidty/status/211…
Bitcoin Core v32.1: a deeper look
First, why no 32.0?
It was tagged on October 21 but never fully announced or released. A remotely triggerable TCP crash was reported on October 23 and 32.1 shipped on October 27 (yesterday) with that fix and two others.
I'll dig into the security updates, but this release also represents months of testing, maintenance, and work to make Bitcoin easier to verify and use.
What went into these v32.1 changes and what do Bitcoin users get from them?
Bitcoin Security Consortium (@BTCconsortium) member Coinbase helped organize a Post-Quantum Bitcoin Workshop that took place on August 28.
The event took place at Stanford University and was co-organized by Dan Boneh (@danboneh), a professor in applied cryptography, and Localhost Research (@lclhostresearch) a Bitcoin-focused research center.
Attendees included Bitcoin developers, cryptographers, researchers, institutional custodians, and hardware-wallet representatives.
Coinbase provided a summary writeup on their blog:
coinbase.com/blog/moving-bit…
Localhost recently posted theirs as well:
lclhost.org/blog/quantum-wor…
The agenda for the event:
gist.github.com/lclhostresea…
Detailed session notes (by JD from Localhost, thank you!) are on the @btctranscripts website:
btctranscripts.com/quantum-w…
More:
xitter.twitterapi.xyz/lclhostresearch/status…
Two months ago, alongside @Coinbase and @danboneh, we co-hosted a post-quantum workshop for cryptographers, protocol engineers, hardware wallet manufacturers, and institutional voices working on Bitcoin’s preparedness for a CRQC.
Today, we’re sharing transcripts from the event and a blog post summarizing the discussions: lclhost.org/blog/quantum-wor…
A special thank you to our speakers and session leaders: @danboneh, @asanso, @LindellYehuda, Pieter Wuille, @conduition_io, @n1ckler, @P3b7_, and Justin of Localhost, everyone who traveled to attend, and the @MARAFoundation_ for sponsoring our post-event dinner.
We hope this workshop leads to more in-person opportunities to study Bitcoin’s Post-Quantum Problem (PQP).
Finally, thank you to @btctranscripts for hosting the transcripts of every talk and session: btctranscripts.com/quantum-w…
Bitcoin open source contributors aren't granted access to the latest/cyber models for defending open source projects.
While many of us continue to pursue that option, Jeff Lunglhofer (@JLunglhofer) the Chief Security Officer at @coinbase stepped up and used their frontier cyber access to scan Bitcoin Core for vulnerabilities...
Thank you Jeff and Coinbase!
Bitcoin Core is some of the most reviewed code in the world.
We were curious how our frontier AI model would handle it. Last month we ran 16 agents across 5 of the top models for a week to look for issues in Bitcoin Core v32.0rc1
Impressively, they surfaced two minor items - both now disclosed responsibly.
Agentic teams have been a huge unlock so far for our security efficiency. They're also remarkable to watch.
Project Loupe has entered the chat
Finding the 3 'easily discoverable' vulnerabilities in Bitcoin Core v32.1
Although @ProjectLoupe was actually ahead of the curve, announcing they would be doing LLM scans back in May before the ColdCard and other hacks:
"Loupe’s ultimate goal is to find vulnerabilities, report them, and see them eliminated, making bitcoin safer and bitcoin holders more secure."
Great vision by @moneyball and team
xitter.twitterapi.xyz/bitschmidty/status/211…
Why disclose these so soon?
Core's recently updated policy fast-tracks the disclosure of easily discoverable vulnerabilities. LLM-assisted security scans/discovery helped motivate the change. (Note: easy to find doesn't necessarily mean easy to exploit)
All three advisories credit Elias Rohrer's (@_tnull) Project Loupe (@ProjectLoupe) at Spiral (@spiral_xyz), with Greg Sanders (@theinstagibbs) validating and reporting the findings. @L0RINC also disclosed 2 of the findings and Andrew Dorman, 1.
The fixes shipped in 32.1, 31.2, 29.5 and 30.4.
29.x is now end-of-life.
groups.google.com/g/bitcoind…
Bitcoin Core v32.1: a deeper look
First, why no 32.0?
It was tagged on October 21 but never fully announced or released. A remotely triggerable TCP crash was reported on October 23 and 32.1 shipped on October 27 (yesterday) with that fix and two others.
I'll dig into the security updates, but this release also represents months of testing, maintenance, and work to make Bitcoin easier to verify and use.
What went into these v32.1 changes and what do Bitcoin users get from them?
Three vulnerabilities were disclosed on October 28 (today):
Undo-file overflow (Low): extreme miner-crafted block sequences could overflow undo-file limits, corrupt data and stop nodes. Exploitation is considered impractical. The fixes cover 64-bit systems; 32-bit systems and nodes storing blocks on FAT32 remain affected. bitcoincore.org/en/2026/10/2…
TCP memory exhaustion (Medium): a connected malicious peer could bypass receive-queue limits and crash Windows, macOS or BSD nodes. Linux is unaffected by this particular bug. bitcoincore.org/en/2026/10/2…
Paused-peer memory growth (Medium): a peer pretending to use an old protocol could evade timeouts while its announcement queue grew without limit. This is slow memory exhaustion and block-only nodes are much less affected. bitcoincore.org/en/2026/10/2…
An update to Bitcoin Core's security policy
via @darosior on the Bitcoin-Dev mailing list
Video of Michael Ford (@fanquake) presenting about static builds for Bitcoin Core.
He has been chipping away at this for years. Why?
Static builds bundle everything (including libraries) into bitcoind. That same bitcoind runs on basically anything that can execute a Linux program (included older and currently-unsupported operating systems), and every user is running exactly the same code.
More here:
Michael Ford (@fanquake) presented an update on his multi-year effort to ship fully static bitcoind binaries:
- Static vs dynamic linking
- Splitting Guix builds
- Running on older systems
- Open questions
- An experimental LLVM-only toolchain
- Why not macOS and Windows
- Q&A
Discussed:
Bitcoin mining w/@avg_gary
Vulnerability discovery w/Erick Cestari (@iamflops)
Quantum topics w/@conduition_io
Covenants w/Greg Sanders (@theinstagibbs)
Average_gary (@avg_gary), Erick Cestari (@iamflops), Conduition (@conduition_io), and Greg Sanders (@theinstagibbs) joined Optech to discuss Newsletter #421:
News
● Using silent payments for miner payouts in coinbase transaction (2:19)
● Responsible disclosure of a denial-of-service vulnerability in CLN (27:42)
Changing consensus
● Continued discussion of PQC output types (54:03)
● DropKick commit/reveal PQC rescue (1:14:08)
● SHRINCS draft BIP (1:35:48)
● BIP448 and CSFS/CTV demos and applications (37:55)
Releases and release candidates
● Core Lightning 26.06.7 (1:51:35)
● LND v0.21.3-beta (1:55:32)
● LND v0.20.4-beta (1:55:37)
Notable code and documentation changes
● Bitcoin Core #36111 (1:58:21)
● Bitcoin Core #36032 (2:01:17)
● Core Lightning #9435 (2:04:52)
● Eclair #3368 (2:08:10)
● Eclair #3366 (2:10:54)
● LND #11090 (2:14:55)
● LND #11140 (2:20:33)
● HWI #792 (2:23:55)
● BDK #2262 (2:25:48)
Whether you’re a user or developer of open source Bitcoin software, I think this discussion of considerations and tradeoffs around vulnerability handling is worth a listen
Core Lightning maintainer Níckolas Goline (@ngoline) explains the project's approach to mitigating recent vulnerabilities
Those pesky Bitcoin Core developers
If those pesky Bitcoin Core developers set a default option value that you don’t like, change the option value
If those pesky Bitcoin Core developers don’t have an option you want, contribute to the open source Bitcoin Core codebase and add it
If those pesky Bitcoin Core developers don’t accept your proposed change, fork their open source code and use the freedom that comes with it to add whatever you want
If those pesky Bitcoin Core developers are so pesky you want to start your own implementation, you can use their open source Bitcoin Kernel library as a consensus-compatible basis for your implementation
If those pesky Bitcoin Core developers’ consensus compatible Bitcoin Kernel library is not desirable and you want to code up your own entire Bitcoin implementation from scratch… use their pesky test suite, differential testing, and fuzzamoto testing engines
Maybe a pesky Bitcoin Core developer even provides a dozen different suggested fixes on your repository, like here
Keep building.
One man's journey to Bitcoin Core development
Stephan (@stickies_v) on getting in to open source Bitcoin:
Earlier this year we published a special interview with Bitcoin Core developer @stickies_v describing his journey into bitcoin open-source.
Previously this had only been available to participants of the @ChaincodeLabs BOSS Challenge. We are pleased to share it is now publicly available both on our website as well as here.
Happy reading!
More details on CLN next steps
Well, seeing that our @Core_LN pre-announcement caused a bit of a kerfuffle, let me talk about the what, why, and when of the upcoming CLN v26.06.7 point release. 🧵
First of all: no need to panic. We are not aware of any vulnerability being actively exploited. 1/6
We recorded this with Lightning node (Eclair) maintainer Bastien Teinturier (@realtbast) the other day on the Optech podcast.
Tumultuous time for software handling bearer assets.
More on the full podcast:
xitter.twitterapi.xyz/bitcoinoptech/status/2…
Bastien Teinturier (@realtbast), Salvatore Ingala (@salvatoshi), and spacebear joined Optech to discuss Newsletter #419:
News
● Reorg vulnerability in LND channel closes (1:13)
● Draft BIP for `rawtr()` output script descriptor (1:14:36)
Changes to services and client software
● Payjoin Dev Kit (rust-payjoin) 1.0.0 released (55:33)
● Silent payments sender plugin for Electrum (1:21:41)
● Superscalar implementation announced (1:22:34)
● Cofund multisig wallet announced (1:24:57)
● Lexe adds human-readable addresses and LNURL-withdraw (1:25:55)
● Ledger Bitcoin app 2.5.0 adds human-readable policy descriptions (37:17)
● Bark 0.5.0 released (1:27:34)
● Bitcoin-PIR for private UTXO queries (1:28:16)
● OP_TEMPLATEHASH Ark demonstration (1:29:44)
● libshrincs formally verified hash-based signatures (1:34:00)
Notable code and documentation changes
● Bitcoin Core #32784 (1:38:08)
● Bitcoin Core #35797 (1:40:45)
● Bitcoin Core #35531 (1:44:14)
● Bitcoin Core #35889 (1:48:44)
● Bitcoin Core #35605 (1:51:06)
● Eclair #3352 (12:15)
● Eclair #3351 (20:31)
● Eclair #3345 (23:16)
● LND #8754 (1:54:23)
● LND #11065 (1:55:47)
● HWI #842 (1:57:04)
4
394
Draft BIP for SHRINCS post-quantum signatures
Today, we're publishing BIP SHRINCS, the first concrete proposal for a post-quantum signature scheme designed specifically for Bitcoin.
The BIP draft turns what began as a rough idea into exact algorithms with an executable reference implementation.
This is an important milestone: the discussion can now focus on analyzing, criticizing, and improving a concrete proposal.
The BIP makes choices ranging from major design questions, such as whether to support flexible XMSS and how to balance signature size against verification time, to the many smaller decisions involved in saving a byte here or there.
All of these choices are up for debate.
Big thanks to Mike Casey, @conduition, @Ethan_Heilman, @kudinov_mikhail, @olkurbatov, Boris Nagaev, and @remix7531 for their contributions to the BIP.
A lot more work lies ahead:
- The draft BIP specifies only the cryptography. Using SHRINCS in Bitcoin Script will require a separate BIP.
- We are working on a security proof for the exact construction and parameters.
- Wallet integration and user experience, for example around backups and recovery after state loss, are still at an early stage. The design space remains wide open.
SHRINCS is not intended to be Bitcoin's "final" signature scheme, and it is not optimal along every axis.
I do think it is a very good trade-off among the options we have now.
bitcoin-dev post:
groups.google.com/g/bitcoind…
Draft BIP:
github.com/SHRINCS/shrincs-b…
