Bitcoin Core v32.0 is targeted for release in October: - Up to 3x faster initial sync. Block validation now fetches transaction inputs from disk in parallel instead of one at a time - The libevent external dependency is fully removed, continuing Core's push to cut third-party dependencies - Max peer connections raised from 125 to 200 to have more open slots for new nodes to sync from, faster block propagation, and a harder network to eclipse or partition - Mempool-based fee estimation to cut fee overestimation (in progress) - Transaction relay rate limiting is now global instead of per-peer, keeping a node's CPU and memory usage steady when transaction volume spikes - Ships with features from libsecp256k1 0.8.0 with verification up to 11% faster, plus the new Silent Payments module (BIP 352) - PSBTv2 (BIP 370) support, now the default for PSBT-creating RPCs for better coordination of unsigned transactions for multisig and hardware wallet setups - New exportwatchonlywallet command to export a wallet as a watch-only file, no private keys, and restore it on your online node - Core now enables Tor's proof-of-work DDoS defense on the onion service it creates for your node, where the Tor daemon supports it Additional tests, bugfixes, and features included as well. Feature freeze is ~August 20, rc1 ~September 10, final release targeted for ~October 10. (Test the release candidates when they ship!)

In case you missed it yesterday: @KLoaec who helped raise the alarm on the COLDCARD issue: @premai_io announces additional Kimi-K3 support, partially due to Bitcoin researcher demand: Bitcoin researchers using LLMs to pound on Bitcoin open source codebases (many others!) @callebtc : @Rob1Ham : Tokens sponsored by @OpenSats : @ProjectLoupe doing similar AI scanning calling for projects to join: @MARAFoundation_ announces permissionless access of Slipstream for more-private transaction broadcast: @lianabitcoin announcing Slipstream usage: and @unchained using Slipsteam as well: @jamesob puts up honeypots to track hacker sophistication and progress: @HodlDee committing to continue to help support COLDCARD users in migrating:

There sure has been a lot of *talk* about Bitcoin development these last 18 months. Meanwhile, there's been an awful lot of actual development work done. Examples of what Bitcoin Core has been working on throughout this all: - a node that syncs in nearly half the time - a path to 5x faster (SwiftSync) - a new GUI to make running that node easier, maybe even on mobile - a redesigned mempool with better fee bumping and fee estimates - a mining interface so individual miners can build their own block templates (Stratum v2) - a private broadcast so your transactions can't be traced to your IP - a reproducible map of the entire internet for node eclipse attack protection - a better way to relay time-sensitive Lightning and Ark transactions for confirmation - a multisig that's cheaper, more private, and looks like any other payment on-chain (MuSig2) - a private payment address with zero linkable payments (silent payments) - a threshold (e.g. 3-of-5) signature scheme that looks like a single signature (FROST) - a proposal to fix known protocol bugs and current attack vectors (BIP54) - a slew of post-quantum research to be ready for future attack vectors - a first-ever independent security audit for more eyes on the code - a new tool that attacks a live node the way a real adversary would (Fuzzamoto) - a fix that killed an entire class of disk-filling attacks - a replacement for a risky external library - a consensus engine the whole ecosystem can build on (Bitcoin Kernel) Over a hundred contributors and more than a dozen funding organizations around the world. Not without controversy. Not without bugs. But undeniable progress. August will come and go. This work will continue.

Today nine institutions including BlackRock, Fidelity, Coinbase, and Strategy announced the Bitcoin Security Consortium (@BTCconsortium), pledging $15M toward Bitcoin security work over the next three years. I've agreed to help coordinate the group's work as a volunteer. I said yes because supporting Bitcoin's developers and helping people understand their work are the two things I've spent my time in Bitcoin on, through Brink and Optech. This group wants to do both: fund the people already securing Bitcoin, and bring accurate information about that work to audiences it doesn't currently reach. The group's first focus is quantum computing, a potential long-term threat that's reasonable to prepare for. Its true that a sufficiently powerful quantum computer would break Bitcoin's current signatures. What's usually wrong are the loudest "imminent doom" voices. The development community is already working on this. These institutions want to help. I know exactly how "nine giant institutions form a group to 'help' Bitcoin" sounds, I had the same reaction. So before accepting, I spoke one-on-one with each company about their values and priorities, to judge whether this would actually be a productive initiative for Bitcoin. Two things mattered most to me, and I found the members already aligned on both: - No pooled funding. Each member company funds who they choose, independently. The Consortium doesn't hold funds or pick recipients. - No Consortium positions on protocol changes. Members speak for themselves. I'm a volunteer, receiving no compensation from the Consortium. I continue to run Brink, independent of any Consortium member. I've committed to a year in this role, maybe I'd do two, but ultimately I see it as a seat that should rotate to other participants over time. My commitment is to Bitcoin, and that doesn't change. My hope is that this effort results in more funding reaching more developers/researchers, on their own terms, and a measured counterweight to quantum panic, in both directions (no doomerism, but also no dismissal). Quantum is the first focus, but if this group works the way I think it can, there's room to support other security efforts down the road too. More about the Consortium: I expect plenty of skepticism. Ask me anything.

This thread is pretty representative of the poor discourse about Bitcoin development on X. “ship rad stuff”, “ship value” instagibbs was instrumental in shipping ephemeral anchors, TRUC, package relay, and other work that improved Lightning, to the celebration of Lightning node maintainers, Ark implementors, and users. Then wrote a guide to explain it all: instagibbs helped ship Cluster mempool to improve the mempool, fee bumping and other improvements instagibbs has been working on eltoo/LN-Symmetry, a substantial improvement/overhaul of Lightning for Bitcoin payments instagibbs is also working on covenants proposals specifically scoped to improve Bitcoin payment use case improvements for layer 2s like Lightning and Ark, as well as vault features. In addition to authoring these proposals, he is also working on tooling and a variety of proof of concepts. “Hold yourself to some level of standards. 8.5B people are counting on *us* to not drop the ball.” instagibbs has reviewed and provided many 1000s of comments in the last 11 years to help ensure balls are not dropped. You’re welcome to look at GitHub for the quality of these reviews. instagibbs’ work also helped mitigate pinning attacks on the Lightning Network. There are many other examples of hardening Bitcoin software, check the repo or ask your favorite LLM. Yet you claim he has “completely torpedoed quality work”, and should “be sent on your way”. Because you disagree with the rationale for a default mempool policy setting value change? Send away the guy spending 11 years on Bitcoin and some of the most impactful Bitcoin-as-payments work out there. Michael, ARE YOU OK?

@Excellion @hodlonaut @adam3us I’m really curious as to what is meant by captured as well. Namely: Who specifically in Bitcoin Core is captured? By whom exactly? By what mechanism? For what purpose? Preferably with evidence. Perhaps that will come out in the 4th/final article.