Jack, Bitcoin Core shipped a wallet deletion bug last year. Versions 30.0 and 30.1 had a migration failure that could delete your entire wallet directory. The binaries were pulled from bitcoincore(dot)org. After that, Core 31.0 shipped a private broadcast feature that leaked your IP address to any malicious peer who forced a v1 retry. The stated privacy guarantee was that recipients would never know your IP. It was broken on release. This is not a new pattern. CVE-2018-17144 was an inflation bug that sat in production for 18 months. A miner could have created Bitcoin out of thin air, in violation of the 21 million cap. It was never exploited, but not because the process caught it. A high-severity consensus bug, CVE-2024-52911, was fixed in Core 29.0 and publicly disclosed in May of this year. The governance structure that produces these bugs is not incidental. Our quantitative analysis of 25,122 Core PRs shows that 25.5% of maintainer-merged PRs are self-merges. Three people control 81.1% of all merges in the repository's history. Since 2022, one maintainer accounts for roughly half. The "arsonist and fireman" pattern is documented: same contributor introduces a bug and authors the fix, independent verification bypassed. When roughly 99% of Bitcoin nodes run one implementation lineage, that is the attack surface. Every bug in that codebase is a systemic Bitcoin risk, not a software bug with a narrow blast radius. You said Strategy and Strike have incentives to keep Core safe. Here is the actual structure. Five people hold commit access to Bitcoin Core. They are employees and grantees of a small set of institutions whose founders and funders circulate among each other and have direct financial interests in specific protocol directions. Bitcoin was designed to eliminate trusted third parties. Its reference implementation is controlled by them. The people with the most to lose have every incentive to keep that quiet, because the narrative that Bitcoin infrastructure is sound is load-bearing for their business models. Hardware wallet failures are real. But you told people to just buy a laptop and run Bitcoin Core on it. Windows and macOS both ship zero-days on a regular cadence, Microsoft has a decades-long pattern of bundling attack surface directly into the OS, and your browser runs in the same process space as your wallet. Whatever hardware security a laptop has is built for OS integrity and disk encryption, not for Bitcoin key isolation. A hardware wallet exists precisely to take your keys off that machine entirely, into a purpose-built environment with no network exposure and no shared process space. Telling people to abandon that for a laptop running Core is not a security upgrade. It is a step backward dressed up as one. I am completely allocated to Bitcoin. I have spent 12 months and significant capital building the quantitative and governance case for implementation diversity as Bitcoin's ideal security posture. No one has engaged with the risks and incentives of this space more rigorously than this work has. I am not bragging. I am begging. The data is there. The argument is there. If you actually care about Bitcoin, prove it. Engage with it.

Bitcoin Core has shipped one consensus change in the last nine years, and it broke. Taproot activated in 2021, and within 13 months people were using it to stuff arbitrary data into the chain in a way nobody designed for and nobody agreed to. Every attempt to fix that has been rejected or closed, and the one policy constraint that was slowing it down got removed over broad opposition, spurring a significant portion of node runners to abandon Core entirely and rally behind a competing implementation. Meanwhile CTV and BIP-54 have both been sitting for seven years, one trying to add functionality and the other trying to fix bugs that have existed since the beginning. Neither has really moved. And now the same people who shipped a consensus change they did not understand, and refused to clean up after, want to change consensus again. Taproot's consequences came as a surprise because the Bitcoin consensus protocol has never been formally specified. A BIP describes what it intends to do, but it gets layered on top of a protocol that nobody has ever fully written down. When you change something you have not fully characterized, you cannot know what you are actually changing. That is how unintended behavior makes it to mainnet, and it is why the same thing can happen again. I am not against changing Bitcoin. I am against changing Bitcoin blind. Before anyone earns the right to change consensus again, they need to demonstrate two things: that they know how to make consensus changes safely, and that they are willing to fix their mistakes when those changes go wrong. That means a formal specification of the entire existing consensus protocol, formal verification of any proposed change against that specification, and differential testing against independent implementations before anything ships. Alternative implementations exist. What does not exist is any process that treats them as a mandatory check on Core before a consensus change goes live. The bar for changing the monetary base layer of human civilization is not vibes and rough consensus. Build the infrastructure to do this right, or stop asking.