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?

@BitcoinBombadil @boomer_btc @Rob1Ham @coinjoined @ocean_mining An exploited timewarp attack (which BIP54 mitigates) could result in up to 6 blocks/sec, decades of subsidy mined in weeks, node resource exhaustion, network centralization, timelocks disrupted, funds potentially lost, endless reorgs, etc. This is bad for Bitcoin as money.

Bitcoin Optech newsletter #426# is here: - links to a draft BIP for letting peers choose their own one-byte message type IDs over the version 2 P2P transport - summarizes a discussion about whether BIPs should include their number in tagged hash tags - describes a proposed metaprotocol for private onchain transfers that requires no consensus changes - Optech Newsletter #426# Podcast

Matt Morehouse joined Optech to discuss Newsletter #425#: News ● Disclosure of two DoS vulnerabilities in Eclair (1:01) ● Proposal for wallet label synchronization (15:25) Changing consensus ● Continued discussion of PQC output types (21:36) ● Block-wide signature aggregation via SNARKs (27:17) ● Bounds on chain length with BIP54 time warp fixes (35:19) ● Comparing covenant proposals for vaults (39:23) ● Depots for probabilistic Lightning channels (43:18) Releases and release candidates ● LND v0.21.4-beta.rc1 (48:40) ● LND v0.20.5-beta.rc1 (50:29) Notable code and documentation changes ● Bitcoin Core #29278# (51:55) ● Bitcoin Core #35984# (53:43) ● Bitcoin Core #35301# (56:45) ● Bitcoin Core #36312# (58:51) ● Bitcoin Core #36284# (1:01:59) ● Bitcoin Core #35752# (1:07:47) ● Bitcoin Core #35813# (1:11:46) ● BIPs #2276# (1:13:07) ● LDK #4993# (1:16:39) ● LND #11173# (1:19:40) ● LND #11190# (1:22:12) ● LND #11212# (1:27:37) ● LND #11258# (1:29:58)

Bitcoin Optech newsletter #425# is here: - summarizes the responsible disclosure of two denial-of-service vulnerabilities affecting older versions of Eclair - describes a proposal for synchronizing wallet labels between devices through an untrusted store - recaps continued discussion of PQC output types - describes an approach to block-wide signature aggregation via SNARKs - summarizes bounds on chain length with BIP54 time warp fixes - links to research comparing covenant proposals for vaults - discusses the depots idea for probabilistic Lightning channels - Optech Newsletter #425# Podcast

Ahmet Kurt (@startimeahmet) and Jan B (@_jan__b) joined Optech to discuss Newsletter #424#: News ● Proposal for a post-quantum Lightning Network (1:10) Selected Q&A from Bitcoin Stack Exchange ● What would be a drawback if sum instead of SHA256 of amounts was used in the taproot signature message? (36:18) ● Post-BIP110 fork is it necessary to resync from block 0? (39:32) ● Can a Bitcoin node build a partial UTXO set from only the most recent blocks and use it to validate new transactions? (42:16) Releases and release candidates ● Bitcoin Core 32.0rc2 (21:13) ● Core Lightning 26.06.8 (45:36) ● LDK v0.3-rc2 (47:15) Notable code and documentation changes ● Bitcoin Core #34566# (51:31) ● BIPs #1951# (54:14) ● BIPs #2224# (57:45) ● Core Lightning #9507# (1:02:00) ● Core Lightning #9508# (1:07:35) ● Core Lightning #9509# (1:12:02) ● Core Lightning #9510# (1:16:03) ● Core Lightning #9513# (1:20:01) ● LND #11198# (1:21:47) ● LND #11146# (1:24:15) ● LND #11132# (1:27:20)

Some personal news: ✅ Loupe has produced 26,821 findings across 43 open-source bitcoin repos ✅ Average successful scan took 2H 52M and returned 53.6 findings ✅ Longest scan ran for 36H 58M ✅ 26,809/26,821 findings shipped a proof-of-concept & 12,774 shipped a proposed patch

A new release candidate of Bitcoin Core, v32.0rc2, is available for testing. This is a new major release, and follows v31.1. Work-in-progress release notes are here: Binaries are available here:

Bitcoin Optech newsletter #424# is here: - describes a proposal for upgrading the offchain protocols of the Lightning Network to post-quantum security - summarizes popular Q&A from Stack Exchange - Optech Newsletter #424# Podcast

Davidson Souza (@Erik17192799), Eric Price, and PortlandHODL (@PortlandHODL) joined Optech to discuss Newsletter #423#: News ● Vardiff controllers that strand slowing miners (23:06) ● Improvements in Utreexo initial block download (1:18) ● New BIP draft for unspendable internal keys (1:17:51) Changes to services and client software ● BitBoxApp adds Spark-based Lightning payments (1:24:09) ● script editor (1:28:40) ● EntropyLab offline key calculator (59:46) Releases and release candidates ● Eclair 0.14.3 (1:31:10) Notable code and documentation changes ● Bitcoin Core #35445# (1:33:34) ● Bitcoin Core #36076# (1:38:51) ● Bitcoin Core #36150# (1:42:18) ● Bitcoin Core #36174# (1:44:37) ● Bitcoin Core #34743# (1:46:13) ● Bitcoin Core #36081# (1:48:07) ● Bitcoin Core #35975# (1:48:59) ● BIPs #2241# (1:50:04) ● BIPs #2258# (1:53:09) ● Eclair #3380# (1:56:33) ● Eclair #3376# (1:57:37) ● Eclair #3372# (2:04:34) ● LND #11163# (2:05:57) ● BDK #2246# (2:07:44)

“On one side was Google, the big name, the fancy offices, all of that. On the other side I could work on Bitcoin, which I found both technically fascinating and genuinely important.” - @danielabrozzoni

Bitcoin Optech newsletter #423# is here: - summarizes an analysis of mining pool difficulty controllers stranding slowed miners - describes a proposed improvement to Utreexo’s initial block download - links to a draft BIP for specifying unspendable taproot internal keys - summarizes changes to services/client software - Optech Newsletter #423# Podcast

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

> Bitcoin Core has spent more than a century of CPU time fuzzing individual functions and critical components (though oss-fuzz, Fuzzor, bitcoinfuzz and individual contributors), and decades of CPU time simulating small networks of full nodes under test (Antithesis, Fuzzamoto). I can’t establish causality from this alone, but my strong suspicion is that the sustained testing effort is an important reason these projects have become so robust.

Adam Gibson and Rob Segers joined Optech to discuss Newsletter #422#: News ● A protocol for probabilistic coinjoin and covert betting (1:14) ● Update on silent payments light clients (43:26) Releases and release candidates ● LDK v0.3-rc1 (1:04:06) ● LDK v0.2.6 (1:05:58) ● BTCPay Server 2.4.4 (1:07:44) Notable code and documentation changes ● Bitcoin Core #35949# (1:13:04) ● Bitcoin Core #34931# (1:15:11) ● Bitcoin Core #36048# (1:18:14) ● Bitcoin Core #36123# (1:21:12) ● Bitcoin Core #36176# (1:22:32) ● Core Lightning #9434# (1:24:49) ● LND #11061# (1:26:29) ● LND #11125# (1:27:23) ● LND #11064# (1:28:33) ● BTCPay Server #7561# (1:29:31) ● BTCPay Server #7559# (1:31:03)

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:

Bitcoin Optech newsletter #422# is here: - describes a proposed protocol for probabilistic coinjoins disguised as covert bets - summarizes benchmarks of a silent payments indexing server against compact block filters for light clients - Optech Newsletter #422# Podcast