What is quantum computing? How is a quantum computer different from a regular computer? What relevance does this have to Bitcoin?
New Bitcoiners have been inevitably bumping into these questions and having to confront the issues they dredge up regarding Bitcoin’s exposure to what is very much an existential threat to its existence if a viable quantum computer were to be developed.
The ability to own bitcoin rests on the foundational assumption that without directly leaking a copy of it, no one but the person who possesses a private key can sign to transact with coins secured by that key. Quantum computing calls that assumption into question.
Quantum computers are not just “computers, but faster.” They function in a very fundamentally different way from a classical computer, and as such they are much more efficient than classical computers at very specific kinds of computations. Now obviously, I’m not going to actually explain how quantum computers work in minute detail within four pages, but I will give you the core intuition of how they are fundamentally different from a classical computer.
So let’s take a look at how both kinds of computers interact with things like large cryptographic keys.
Classical Computers
Everything stored in a classical computer (or just computer from here on out) is stored as a series of 1s and 0s. Each bit (1 or 0) is precisely a 1 or 0; there is no ambiguity. When a piece of data is stored, it’s 1s and 0s. When a piece of data is manipulated or modified, it is done bit by bit, step by step, on each 1 or 0.
That is how a computer works. It linearly, one step after the other, modifies the discrete unambiguous pieces of data that it is storing. It can’t skip ahead, or shortcut (in terms of the steps it’s taking, not more efficient ways to do things mathematically), it has to go through the steps of whatever computation it is doing one by one.
When you generate a private key using a computer, it acquires a random value (you inputting dice, general user input, randomness from device hardware, etc.) and stores that in memory as 1s and 0s. From there it has to multiply this value by the elliptic curve’s generator point to get a public key. This is accomplished with an algorithm, that boiled down to its most basic level, is literally instructions on what bits to take, how to modify them, what circuits to “push” them down on a physical level to accomplish that, and in the end put the new value that has been modified bit by bit back into memory.
There are other steps to arrive at an actual valid address, but for the purposes of this article those are not necessary to go into (but they are just like the above step, just step by step instructions on how to modify 1s and 0s in memory).
So what if someone wanted to use a computer to guess someone else’s private key?
There are 2256 possible private keys. That’s 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 different possible keys.
A computer would have to try every single one of those possible private keys, one after the other (or however many at a time it can do in parallel), step by step following the exact instructions above for generating keys. The more of them you try to check in parallel, the more computing power you need, with no ability to find any shortcuts around that cost.
The less computing power you want to use, the more time it will take, the less time you want it to take, the more computing power you need.
This is an impossible task to accomplish with a computer. On one side you have a computation cost that every computer on Earth is not enough to pay, and on the other side you have a cost in time that is so high every star in the universe would die before you checked them all.
To actually accomplish your goal, you need another option besides checking one by one linearly or in parallel. That’s where quantum computing comes in.
Quantum Computers
Quantum computers don’t work with discrete states. Everything is precisely a 1 or a 0. The most basic piece of information in a quantum computer is a qubit (the quantum version of a bit). Unlike a bit, a qubit is in a superposition where it is both simultaneously a 1 and a 0. It only settles into one or the other discrete states when it is observed.
This is one of the key building blocks that allow a quantum computer to compute differently. The other is entanglement. Qubits aren’t just stored in isolation, the physical atoms representing them and collapsing to a discrete state when observed are entangled together. This means when entangled atoms are observed and collapse to a single state, the entangled atoms collapse to the same state, no matter how far apart they are.
Now here’s where things get weird, and I’m going to have to get a little hand-wavy; you should still walk away with an intuitive understanding of why quantum computers are fundamentally different from a classical computer. An algorithm on a classical computer is a set of instructions to take a specific set of bits, and step by step modify them according to the algorithm’s instructions, until finishing and outputting the finished set of new bits. So the algorithm step by step takes one discrete state and turns it into another.
Qubits don’t store discrete states until they are observed and collapse to one. They store probabilities. When you have a set of qubits entangled of any given size (like in this hypothetical case 2256), each given possible state that it collapse to has a certain probability of collapsing to that given state.
Quantum algorithms, rather than being step by step instructions to operate on discrete states, are a set of instructions on how to operate on those entangled qubits in a way that alters the probabilities of different outcomes. Constructive interference is used to increase the probability of a correct outcome, and destructive interference to decrease the probability of incorrect outcomes (note that this is NOT the noise or interference that makes it difficult for physical quantum computers to function accurately, that is a different concept).
So while a classical computer would have to check each individual private key one by one to find the one matching a specific public key, a quantum computer can simply run a few times using the right algorithm and arrive at the correct answer. It does not do this by “checking all the possibilities at once.” It simply modifies the probabilities of what a superposition will collapse into.
This is why a quantum computer could break the assumptions underlying elliptic curve cryptography, and a classical computer could not (and it is also why quantum computers are only useful for certain types of computations with a massive possible space of answer candidates to check).
Don’t Panic
This fundamental difference between classical and quantum computation means, that yes, if a viable quantum computer is actually produced, that functions correctly, then the underlying assumption that secures all Bitcoiners’ individual bitcoin is broken. All of those funds are insecure.
Yes, this is a serious risk if such a device is actually manufactured, and it works, but we are not entirely unprepared. We understand the problem, we understand the exposure, and a good number of possible solutions to many different facets of the problem are coming together.
Breathe, and relax. Through the rest of this issue we are going to walk you through the whole problem.
This piece is featured in the latest Print edition of Bitcoin Magazine, The Quantum Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.
The “White hat” party that withdrew nearly 4,000 bitcoin from the Liquid Network federation wallet on Sunday returned 3,400 BTC to the wallet on Monday. About 598 BTC, or 15% of the consolidated pile, stayed at the same holder address as an implied bounty fee worth 48 million dollars.
The return transaction (bc49a46d), confirmed at 16:09 UTC on September 7. It returned exactly 3,400 BTC to the labeled Liquid peg script address and sent the 598.5 BTC change back to the “White hat” hacker address as change.
The transfer followed a day of messages written into Bitcoin blocks. The White hats first published transaction on chain with a message in the OP_RETURN arbitrary data field “contact us on chain”; the message came from the address holding the 4000 BTC taken from the Liquid Network.
A Blockstream-linked address answered with “Please contact security@blockstream.com”. Later notes from that sender carried Electrum-encrypted payloads and PGP signatures that can be verified against Blockstream’s published security key.
In block 965869, the White hats asked in the clear text whether sending “most” back to the federation script was acceptable. The 1,000-sat output on that transaction was only a message carrier.
Soon after, the White hats wrote “Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix.” followed by an encrypted blurb of text to Blockstream’s PGP key.
In the same block, a clear-signed reply from the Blockstream sender said “Yes, thank you.” Hours later, the same Blockstream posted another clear-text note: “Bridge nodes are patched, safe to return the funds”.
Minutes after the 3,400 BTC landed. The white hats sent back 85% of the funds, keeping 15% as an implied finder’s fee. The choice was celebrated by some on X as ‘better than keeping 100%’ while others were a bit shocked at the amount. While 15% might sound reasonable, the total sum is so large that it nears $50 million at today’s prices. Blockstream was clearly not happy about the finder’s fee, as four encrypted messages followed onchain a few hours later, likely after the main fires had been put out at the office and the lawyers had a chance to have a say in the matter. An hour later, one more encrypted message was posted from Blockstream.
The White hats replied with two encrypted messages. Blockstream replied once an hour later. Then the White hats published a simple yet meaningful “ ” sad face emoji. This emoji does a lot of work. It suggests that negotiations did not go well over reducing the size of the bounty. Blockstream wizards are clearly ‘big mad’ about the size of that finder’s fee. What exactly was said in those encrypted messages is not known and Blockstream has made no public statements on the matter. But we can only assume the saga is not over.
Liquid’s Sunday statement is still the network’s last official account post: purported whitehats withdrew about 4,000 BTC through the SideSwap peg-out path, the PAK itself was not compromised, other issued assets were unaffected, and the sidechain was paused. Liquid and Blockstream had not posted a new statement on the 3,400 BTC return as of this writing. SideSwap had said the L-BTC in the original peg-out “came from an Elements bug.”
The Liquid Network said Sunday that purported white-hat hackers withdrew about 4,000 bitcoin, worth about $320 million, from the federation wallet that backs L-BTC. Bridge nodes were disabled, and the sidechain was paused. Other issued assets, including USDT, DePix and RWAs, were unaffected, the official account said on X.
The Liquid Network is a federated sidechain of Bitcoin, founded by Adam Back’s Blockstream. The Liquid chain issues a variety of assets such as LBTC, which it backs with BTC on the Bitcoin main chain, held in a large multisig of 15 corporate and known members. 11 of the 15 members need to sign a valid multi-signature transaction to move coins from the treasury. Before the hack, the treasury held over 4200 BTC; after the hack, Blockstream’s proof of reserves page reports a little over 207 BTC left.
The hackers withdrew 4,019.4 BTC from the reserve address in a peg-out transaction using the SideSwap Peg-out Authorization Key. SideWap is a bridge exchange and a member of the Liquid Federation. While details on the mechanism of the hack are not confirmed yet, it appears an inflation bug on the LBTC side chain was exploited by the hackers to create over 4,000 LBTC that did not exist before, and cash them out for on-chain bitcoin from the federation. Because the transaction appeared as valid, given the consensus bug, the federation members’ HSM security servers signed the BTC withdrawal transaction, worth roughly 320 million at the time.
The hacker moved the funds to an address ending in 6gyqjlte, from which they quickly signed a new transaction with a message on the OP_RETURN arbitrary data field saying “we are whitehats. contact us on chain.” Those coins were still at that address at the time of writing.
A small mainnet transaction to the hacker address followed by an OP_RETURN saying “Please contact security@blockstream.com”, presumably from a Blockstream public address, though that remains unconfirmed. A later OP_RETURN spend from the hacker address carried “Please contact us on Signal @m671aw.70”, however, this may be spam and does not share a link to the address with the stolen funds.
In response to the breach, exchanges were told to pause L-BTC deposits and withdrawals. Bridge nodes on the Liquid Network have been paused, limiting access to the side chain, which continues to produce blocks.
JAN3 CEO Samson Mow said Aqua’s Liquid features were affected and that on-chain bitcoin still worked. Other wallets in the industry that use the Liquid Network are expected to be affected. Users holding LBTC now effectively have their savings at risk, since the underlying BTC is currently not redeemable. Given the private nature of the Liquid chain, user onchain analytics are scarce and not much public information is known about how much LBTC is held by retail users versus corporations of Blockstream itself. Nevertheless, should the funds not be returned, it would be a heavy blow to the Liquid Network’s user base.
Users of LBTC don’t have many options but to wait for conversations with the hackers to resolve. Given the size of the hack, it would be difficult for the hackers to get away with stealing all that bitcoin, though perhaps not impossible. What may happen is that the hackers ask for a finder’s fee and return the majority of the funds.
Quantum this, quantum that…who put a stupid cat on-chain!?
Ahem.
Alright, let’s be serious. The threat that a viable, actually functioning, quantum computer would pose to Bitcoin if it were to be built is very serious. It is the concrete example of an existential threat, in every sense of the word.
One of the bedrock foundations that Bitcoin rests upon is the assumption of a functioning cryptographic system that can be used to produce unforgeable signatures, i.e. that if you follow that system’s protocol properly when signing things, there is no way that anyone but a bitcoin’s rightful owner could produce a signature needed to spend it unless the rightful owner failed to secure their private key from theft.
Quantum computers toss that right out the window. There goes the integrity of the entire mechanism that is used for owners of bitcoin to authenticate their ownership for the protocol to process their legitimately authorized transactions, and ONLY their legitimately authorized transactions. There’s no way for anyone to actually own anything in the context of the Bitcoin protocol if that assumption breaks.
Bitcoin breaks if that assumption breaks.
Thankfully, there are many different cryptographic systems that exist, and not all of them rest on assumptions that a quantum computer breaks. That’s the good news. The bad news is that its all a set of tradeoffs, none of them are ideal, and there are going to be some hard choices that have to be made.
But there are solutions to just about every one of the problems that a viable quantum computer would create…except the problem of choosing which solutions to use. So in light of that, here is The Quantum Issue.
This issue is a lot more structured than most past issues, and that is to ensure that it guides a reader through the entirety of the problem space and solution space without assuming any prior understanding (this is a very deep and technical subject).
The first set of articles goes through the general issue of quantum computing itself, how it differs from classical computing, why that matters, how likely it is one is developed soon, etc.
The second set examines Bitcoin’s exposure. How is it exposed? How badly is it exposed? How can that degree of exposure change?
The third set examines concrete (or developed enough to not be too hard to get to a concrete place) solutions to securing your bitcoin in a quantum safe way, and handling a network wide migration to those solutions.
This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Quantum Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.
In the wake of Coldcard’s catastrophic entropy bug, self-custody advocates and experts have begun recommending a new standard, multi-vendor multisignature wallets, an approach that looks to minimize —among other threats— dependency on any single hardware wallet manufacturer.
The Coldcard entropy bug that went undiscovered since at least 2021 has taught a hard lesson to the Bitcoin self-custody advocates and users. No matter how legitimate or competent a wallet provider might seem, how well recommended and reputable, a major bug may be possible. As a result, Bitcoiners are questioning old recommendations and assumptions, including many declaring the ‘death of single sig’ the popular self-custody method of trusting the private key pair generation to one wallet alone.
The Threat Model
Self-custody by any measure is an advanced practice in Bitcoin. Advocates recommend it as a way to protect user funds from exchange malfeasance like that seen in the cases of FTX and MtGox, among many others. But recent events have driven a revaluation of custody practices, with many bitcoin owners moving coins to exchanges — at least temporarily — while others upgrading or changing their self-custody setups altogether. Nick Neuman, CEO of Casa, claimed that 233k bitcoins moved to safety in reaction to the Coldcard hack.
To understand when self-custody makes sense and for whom, it is essential to understand your personal threat model. A threat model is the careful analysis of threats to an individual, for the purpose of designing security practices and structures ahead of time.
A simple threat model practice can be to take a step back and think about all the possible things that worry you about self-custody, and add them to a list. Then think about all the things that advocates caution users about, and append them to that same list. Next, sort or rate items on that list based on which are most likely to happen to you, and which are most likely to happen in general. Finally, you can rank each item in the list by how catastrophic it would be if it occurred; can your current setup and plans survive the realization of that threat?
Two of the most likely causes of loss of funds in Bitcoin self-custody are user error related to backups or forgotten passwords, and of course theft. Many of the wallets believed to be lost bitcoins that have not moved come from bad backups of private keys in the early days, resulting in data loss after a computer failed. Others simply used passwords too difficult to brute force, and then forgot them, encrypting their private keys forever.
On the theft dimension, bad entropy attacks likely rank among the most successful attacks on self-custody to date, with Coldcard joining a significant list of other wallets that have suffered bugs of the sort, intentional or otherwise, such as Trust Wallet, and many lesser-known and possibly malicious mobile wallets. In some cases, fake wallets like the iOS Sparrow Wallets simply stole user funds by keeping a copy of the user-generated private keys and sweeping the funds once deposited. In all of these examples, more thoughtful user behavior before trusting random software with your life savings is the solution.
Once users have a clear threat model in place and a good enough understanding of the technology, designing security practices becomes more a science than an art. And while every individual has specific circumstances they need to take into account, some structures have emerged as the most resilient to most threats. One such practice becoming widely recommended and adopted among long-term self-custody Bitcoin holders is a carefully formed multisig setup.
Multi-vendor Multisig
The term “Multi-vendor Multisig” is relatively new in the self-custody niche. The term “multisig” has nevertheless gone viral in 2026, clearly triggered by the Coldcard hack that saw the loss of over 100 million dollars worth of bitcoin, mostly from single seed wallets. Most single-seed Coldcard users appear to have generated their private keys on the device without adding an extra passphrase, extra words that add custom entropy to the private keys, nor without extra dice rolls, which do the same in a different format.
The weak entropy from the Coldcard firmware — which users had no reason to distrust, given the company’s strong brand — in turn made guessing the related private keys easy, with a bit of custom work, which hackers eventually figured out.
The resulting viral interest in multisig is warranted. Multisig Bitcoin wallets protect users from such hardware manufacturer errors by letting users construct a Bitcoin address that requires signing from multiple private keys and thus multiple devices, in what is known as a Bitcoin script.
Bitcoin scripts are contracts of sorts that set spending conditions for a bitcoin wallet. All Bitcoin wallets can be thought of as having some kind of script involved, with the simplest and most popular being that anyone who can sign a valid transaction can spend all or any funds therein. Multisig scripts instead require a threshold of valid signatures from different keypairs to result in a valid withdrawal. These scripts are enforced by the Bitcoin consensus rules.
Multi-vendor multisig theory posits that users should make sure every keypair used to construct a Bitcoin multisig is generated from a different wallet vendor.
One example that is likely popular today might be the use of a Trezor Safe 7 hardware wallet with one key, a second key generated by a Ledger Nano, and a third key generated by a multisig wallet provider, considered a recovery key. A script of this sort would require any 2 valid signatures out of the three possible signatures in the setup.
By using two different hardware wallet providers, the user minimizes trust in any single wallet vendor, protecting them from an entropy failure like the one seen in Coldcard.
Other Multisig setups can add more keys, with a 3-of-5 threshold also being common and a standard offering of a multisig-specialized wallet like Casa. It is at this point that the terminology commonly used and understood to describe Bitcoin spending software starts to break down, and as a result merits clarification.
Wallets like Casa are software interfaces that let users combine partially signed transactions from different private key pairs. In this scenario, it becomes more useful to describe ‘hardware wallets’ like Trezor or Ledger as ‘key signers’ since no single keypair in the set holds enough of the key material to spend all the Bitcoin held in the Multisig script address.
So Casa is a Multisig wallet that lets you use a threshold of hardware signers to secure and send bitcoin funds. Fundamentally, they help users interact with Bitcoin script and create consensus-valid transactions easily. Other examples of such multisig wallet providers include Nunchuck, Sparrow desktop wallet and Unchained Capital.
In cases like Casa and Unchained, the wallet provider offers users a recovery key controlled by the company, which some users find useful. Nunchuck and Sparrow, on the other hand, are designed for full user autonomy in this regard, though Nunchuck does offer a premium recovery key-related plan as well.
The Upsides of Multivendor Multisig
Another benefit of a multisig wallet is its potential resistance to the infamous wrench attacks. Countries like France, which make Bitcoin and crypto ownership a matter of public record as a consequence of tax filings, have become focal points for crypto theft-related kidnapping. Self-custody or not, targets of this kind of crime are vulnerable to theft, particularly when the funds can be moved in full quickly, be it from a custodial exchange the user can access from their phone, or some self-custody setup.
Advanced forms of multisig, like multi-jurisdictional or time-locked multisig, make it so that users have to travel, ideally through an airport, in order to reach other key signers needed to construct a valid bitcoin transaction. Or perhaps the recovery key involved in the multisig has the condition that it will not sign for two weeks after the user submits the request and corresponding transaction data. The result is the removal of the final central point of failure in Bitcoin custody: the user’s own willingness to send the bitcoin, particularly when under duress.
While best practices in the case of wrench attacks broadly try to avoid ending up in that situation in the first place, making it difficult to spend your coins actually protects users from a wide range of attacks as well, including phishing schemes and other forms of social engineering that use pressure tactics to fool users into sending funds quickly.
Multisig has also begun to enable novel forms of Bitcoin insurance, as demonstrated by AnchorWatch, a multisig wallet and insurance company that offers bitcoin theft protection denominated in BTC. The company’s services today are primarily offered to Americans through the Lloyd’s of London insurer.
The Downsides of Multisig
One critical downside of Multisig is that the user does not only need to have access to the threshold key material needed to sign, be it two hardware wallets as in our example, or one of the hardware wallets and a recovery key from the wallet company. The user also needs to store a copy of the Multisig script or template, so that they can recreate the smart contract and thus the valid withdrawal conditions for spending. Most Multisig wallets store this information for clients, but they will also send a copy to users so they can recover independently of the Multisig wallet, should it one day go offline.
Closed versus Open Source code has divided the Bitcoin and broader crypto industry for well over a decade. Bitcoin advocates have long argued that the financial infrastructure of the world should be built in public. Transparency and auditability, they say, are non-negotiable when real money is at stake. Yet the app and legacy layers of finance often disagree.
Yet the recent Coldcard hack, a popular self-custody hardware wallet where users lost over $100 million worth of bitcoin (more than 1,500 BTC), cast doubt over what “Open Source” actually means. It revealed that perhaps most people, even many hardcore bitcoiners, are poorly educated on the Open Source software development philosophy and when it fails.
The Principles and Terminology
The language around Open Source can be complicated. Free and Open Source Software (FOSS) and Free/Libre and Open Source Software (FLOSS) refer to software that meets formal definitions of user freedom.
Freedom 0: The freedom to run the program as you wish, for any purpose.
Freedom 1: The freedom to study how the program works, and change it so it does your computing as you wish (access to the source code is a precondition for this).
Freedom 2: The freedom to redistribute copies so you can help others.
Freedom 3: The freedom to distribute copies of your modified versions to others (access to the source code is a precondition for this).
The FSF emphasizes that “free” refers to liberty, not price, in a common quote heard from FOSS advocates: “‘free’ as in ‘free speech,’ not as in ‘free beer.’”
The Open Source Initiative’s Open Source Definition adds ten practical criteria. These include free redistribution without royalties, availability of source code in the preferred form for modification, the right to create and distribute derived works, and no discrimination against persons, groups, or fields of endeavor — including commercial use. A license must meet all ten criteria to qualify as Open Source under the OSI standard.
“Source available” or “source viewable” is different. Code may be publicly readable while the license restricts the right to sell it. Coldcard’s firmware, for example, is released under MIT terms plus the Commons Clause. The Clause specifically removes the right to “Sell” the software — defined as providing it to third parties for a fee or other consideration in a product or service whose value derives entirely or substantially from the software itself. In other words, Coldcard’s firmware could not be used commercially.
The Commons Clause’s own FAQ states the difference explicitly: “Is this ‘Open Source’? No.” It notes that applying the clause means the software meets many elements of the Open Source Definition but not all of them, and therefore should not be called Open Source.
These distinctions matter. Publishing source code creates the possibility of inspection. Granting the full set of rights defined by the Free Software Definition or the Open Source Definition is what makes software FOSS or FLOSS. But having the badge of approval, being able to wave a FOSS or FLOSS flag, is not the point. Commercial liberty in FOSS unlocks third-party incentives to test and review code that might otherwise not be there, critics argue.
The four freedoms form the philosophical core of Open Source. In practice they rest on an economic assumption: that enough motivated people will actually examine the code. When that assumption fails, the system produces a classic tragedy of the commons, a situation where a shared resource is overused or neglected because individual users act in their own short-term self-interest rather than in the long-term interest of the group.
Each person has an incentive to take more (or contribute less) than is sustainable, and the resource degrades as a result. This happens when there is misalignment between the short-term self-interest of the individual and the long-term interest of the group. Sometimes alignment exists; sometimes it does not.
One Bitcoin developer put the problem bluntly: “Using mocks and stubs of Open Source code in tests is irresponsible and shortsighted. Open Source code is considered safe because anyone can verify it. If you aren’t willing to do the bare minimum of testing the features you actually depend on, then you are behaving like a leech.”
As a result, Open Source does not create safety by itself. It creates the possibility of verification. Whether that verification occurs depends on incentives, skill, and attention. Historical FOSS is believed to harden over time as vulnerabilities are discovered, disclosed and patched, creating solid foundations others build on top of. The Linux kernel is a great example of such hardened FOSS; it powers the vast majority of the world’s servers, cloud infrastructure, Android devices, and embedded systems, making it one of the most widely deployed pieces of software in history.
Open Source as Demonstrated by Bitcoin Core
Bitcoin Core, the reference implementation of Bitcoin, is another prescient large-scale example of pure open-source functioning in the wild. The software, which runs behind most Bitcoin-related infrastructure, is released under the MIT license. Its development process is broadly public by design.
Anyone can open a pull request. Code review is the primary filter and the recommended entry point for new contributors. Reviewers use a formal vocabulary—Concept ACK (acknowledgment and agreement with the goal), Approach ACK (agreement with the goal and method), ACK with a specific commit hash (tested and approved for merge), or NACK (disagreement, which should be accompanied by technical reasoning).
Maintainers weigh consensus among contributors and the technical merits of a change before merging. Consensus-critical changes face a still higher bar and usually require a Bitcoin Improvement Proposal and extensive multi-year discussions on the bitcoin-dev mailing list and IRC.
There is no privileged caste of “Bitcoin Core developers.” Trust is earned through demonstrated competence over time. Maintainers exist for practical reasons—auditing and merging code, managing releases, and basic moderation—but the work produced is pure open-source code that anyone can inspect, build, fork, or run. Developers who get code ‘commits’ merged into Bitcoin Core are broadly called Bitcoin Core Contributors.
Calle, a long-time open-source Bitcoin developer, summarized the reality recently: “People who think that core is some sort of intransparent institution operating in the shadows are either too lazy or too dumb to go have a look for themselves. Literally everything they do is public, anyone can chime in, and the result of their work is pure Open Source code.”
Funding for this work comes largely through nonprofit and grant structures such as Brink, OpenSats, Spiral, and others rather than a traditional company product roadmap. Technical discussion and debate take place publicly on the bitcoin-dev mailing list and in the #bitcoin-core-dev IRC channel on Libera Chat, where proposals are scrutinized before and during the pull-request process. GitHub issues and pull requests often carry comment histories stretching back a decade. The result is a development culture optimized for correctness and auditability rather than speed or commercial feature velocity.
The Economics of Open Source
Most users of open-source or source-available software never read the code themselves. They rely on the assumption that others are examining it. In the Coldcard case, a critical entropy flaw remained in publicly available firmware for roughly five years before it was exploited and thus discovered.
The bug entered the codebase during a major 2021 rewrite that also removed remaining GPL-derived code from Trezor, the first hardware wallet and now the second largest in the self-custody industry. The library at the center of the entropy failure, which replaced trezor-crypto, is called libngu and had minimal external scrutiny, with only 7 stars and fewer than 20 forks in over 5 years of being used in production. Compare that to the 512 stars worn by the trezor-crypto library alongside 212 forks, or the 793 forks and 1.8k stars of the more modern trezor-firmware. Source availability alone did not produce the review that mattered, because other for-profit, well-funded companies were restricted from using it, or so critics would argue.
The stakes are higher in Bitcoin than in most software domains. A critical flaw can be converted directly into liquid funds on the open market. While the first half of the Coldcard funds stolen are still held in a handful of addresses and the hacker may one day be caught, copycat hackers that followed were more careful, and some have stolen more bitcoin and laundered it successfully, per Galaxy Research. Bitcoin’s censorship resistance and immutable transactability create both a powerful incentive for attackers and a Darwinian filter; only projects that continuously attract competent review, and users and companies that take serious precautions, tend to survive long-term.
Licensing choices shape those incentives according to FOSS advocates who criticized Coinkite’s licensing decisions for years. Pure open-source licenses maximize the pool of potential reviewers and forks. Restricted “source available” licenses can reduce commercial free-riding but also shrink the circle of people with both the legal right and the economic motive to invest deep attention. Alas, the burden of code review falls back on the company under a restrictive license, placing it in some sense closer to closed source than open.
How AI Changes Open and Closed Source Development
Artificial intelligence is now also altering the balance between FOSS and Closed source.
After the Coldcard incident, a volunteer effort known as the Bitcoin Red Team—led by developers including Calle and Rob Hamilton of AnchorWatch, and supported by OpenSats—used frontier AI models to scan hundreds of open-source Bitcoin repositories. In one intensive period, the team filed thousands of findings, including dozens classified as critical or high severity, across hundreds of projects. Responsible disclosures were made to maintainers before broader publication. The exercise demonstrated that systematic AI-assisted review can surface issues at a scale and speed previously impractical for purely human teams.
On this front, it is worth noting that the Red Team found Chinese open-weight models far more reliable than closed-source American models, which, even with cyber permissions and top-line access, refused to answer Red Team queries, a trend that the American developers lament.
At the same time, the flood of AI-generated code has created a new denial-of-service pressure on FOSS maintainers. Reviewing AI output often takes longer than generating it. Some open-source projects outside Bitcoin have restricted issue trackers or imposed strict anti-AI contribution rules simply to stay functional.
On the closed-source side, the traditional advantage of security through obscurity is eroding. Modern AI models can read, de-obfuscate, probe endpoints and reason about code at high speed. The practical difference between open and closed source is now mostly relegated to back-end code that never gets shared online. Closed-source code, as a result, stands only on the quality of professional audits, the speed of patch deployment, and the incentive structure that keeps competent people with access looking.
Bitcoin and the broader crypto industry are applying unusual pressures to free and open-source software. The combination of real monetary value at risk, adversarial economics, and now AI-scale analysis is forcing the software models to evolve. Returning to analog pre-digital systems is hardly an option for infrastructure that holds up modern society. Only the most audited projects are likely to survive the pressures of AI-aided hackers and the weight of digital-first finance.
Law enforcement may already know who emptied more than a thousand Bitcoin from Coldcard wallets in the first and largest wave of the July 2026 drains. Block’s investigation believes they traced the attacker’s on-chain sweeps to a paid account at a major blockchain data provider whose internal logs matched the theft pattern with “extraordinary specificity.”
PSA: The attack is ongoing, targeting weak private keys generated on devices as old as the MK2 with firmware 4.0.1 onwards. If you may have one, double-check and move funds asap. See Coinkite advisory and status page.
The coins from that wave—1,082.65 BTC—still sit untouched in the attacker’s address, leaving hope that a clawback may be possible to the victims and rightful owners of that first wave of stolen bitcoin. The question now is, who is the hacker and whether the same lead points to a sophisticated outsider, or whether the five-year-old entropy bug that made the theft possible was something closer to the insider “retirement attack” Coinkite itself once warned about.
What We Know
On July 30, 2026, an attacker began systematically draining Bitcoin from Coldcard hardware wallets that had generated seeds under vulnerable firmware, a bug that was undiscovered for years. The first and largest wave alone moved 1,082.65 BTC. Subsequent waves followed, with estimates over 2k BTC. Alex Thorn at Galaxy Research has tracked the activity through a combination of on-chain pattern analysis and voluntary victim reports. As of early August, confirmed and estimated losses across multiple waves exceeded 1,800 BTC from more than 5,000 addresses, though exact final totals continue to be refined as new reports arrive. In dollar terms, roughly $118 million has been confirmed stolen.
Thorn has publicly discussed the possibility that law enforcement already holds a concrete lead on the operator behind the largest tranche. In a Bitcoin Policy Institute segment hosted on the Bitcoin Magazine YouTube channel, Thorn stated: “Wave one’s identity, attacker identity, may be known to law enforcement.” He added that Wave 1 remains the biggest single chunk identified so far, with the coins still sitting in the attacker’s address, and noted that Wave 2’s pattern looks similar enough that it could involve the same actor. Wave 2 adds another 76 or so bitcoin to the total.
The primary source for the claim that the hacker’s identity might be known is Clay Garrett, engineering lead at Block working on Bitkey. On July 31, 2026, Garrett posted the findings from Block’s investigation:
“During our investigation of the Coldcard drain yesterday, we identified an unusual pattern in the sweeps. That pattern led us to a hypothesis that has since been confirmed: the operator used a paid account at a well-known blockchain-services provider to query the source addresses and perform other related activity during the sweeps.”
“We contacted the provider directly. Their internal logs matched the suspected workflow with extraordinary specificity, including the number, timing and sequence of requests. The provider was supplying its standard services in response to requests that did not reveal their broader purpose. We have seen no evidence that the provider knowingly participated in or facilitated the suspected theft.” Garrett said, and added that; “We are sharing the relevant information with the appropriate authorities. We will provide further updates when doing so will not interfere with the investigation.”
Thorn and others have noted that later, smaller waves show different operational patterns—some rapid, opportunistic drains followed by quick laundering—suggesting additional actors may have reverse-engineered the same weak seed space after the initial public disclosure. Self-reported confirmed drains appear to have slowed sharply after August 6, though many potentially vulnerable seeds generated on the affected firmware between 2021 and the July 2026 patch remain at risk until users migrate.
A Retirement Attack?
The nature of the failure has led to conspiracy theories about insider attacks that Coinkite itself once discussed publicly. In October 2021, the official COLDCARD account defined a “retirement attack” as the scenario “when the project makers could have a ‘bug’ in the entropy generation for later retrieval.” The post is still available here. The 2026 vulnerability produced exactly that outcome: seeds generated with far less entropy than intended, leaving them searchable years later. Some in the Bitcoin space now believe that the hack may have been an inside job at Coinkite, though others disagree and the evidence in the public record remains too scarce to know anything definitive. Further evidence will likely not come out for years, until litigation exposes it.
It’s when the project makers could have a “bug” in the entropy generation for later retrieval.
The critical change entered the codebase on March 1, 2021, in a commit titled “First pass w/ libNgU” (b18723dd). That commit replaced remaining Trezor-derived cryptography and BIP-39 code with a new library, libngu, and rewired seed generation. The intended result was that the call for randomness resolved to the STM32 hardware’s true random number generator. However, the bug redirected the call to MicroPython’s software Yasmarang PRNG instead, resulting in an effective entropy collapse to roughly 40 bits on older models and around 72 bits on newer ones. That meant the Bitocin private keys generated were effectively guessable by modern computing hardware. This swap of cryptographic libraries was pushed to the codebase by Doc-Hex, also known as Peter Gray, the Chief Technical Officer of Coinkite.
The move was arguably driven by licensing pressure, according to Foundation Devices CEO and founder Zach Herbert, though Coinkite has denied this as a primary motivation for the code change, saying, “COLDCARD had to make this change to move to libsecp256k1; the license change is irrelevant to this. libsecp256k1 is the standard library used by Bitcoin Core.”
Coldcard had been using Trezor-derived code under the GPLv3 open source license. After Foundation Devices forked related material, Coinkite sought to move remaining components to a more restrictive MIT + Commons Clause arrangement that limited commercial reuse. The rewrite was large and carried complex engineering goals; it was this integration that arguably left the silent failure in the entropy path.
Skepticism about the migration away from the Trezor crypto library emerged as early as April 7, 2021, by a member of the Coinkite Telegram group, who wrote: “do we really want to replace the many-years-old TrezorCrypto code that has been heavily scrutinized by white hatters like Johoe and penetration tested by wallet.fail”, adding “switch may be a talented pseudonymous coder, but their commit history sucks.” The criticism, however, was insufficient and quickly waved away by NVK, who criticized the Trezor library as a “shitcoin shitshow.” Ironically, sharing that codebase with the broader crypto market, under an open license meant that Trezor’s crypto library had much deeper code review than Libngu would ever get, even years later.
Switch and Peter Gray aka Doc-Hex
The swap of cryptographic libraries that introduced the bug was pushed to the codebase by Doc-Hex, the Chief Technical Officer of Coinkite, also known as Peter D. Gray. He replaced the GPLv3 Trezor cryptography library with Libngu, a little-known codebase created by so-called “Switch”, a nym that, up until the creation of Libngu, had no obvious previous history. The Switch account appeared on X on August 3, 2019 with a mention of DEFCON, the international hacker’s conference, an event normally attended by cybersecurity engineers of all kinds.
However, here is where it gets weird. According to research by Bitcoin core contributor James O’Beirne, Switch and Peter D. Gray have signed code commits with the same GPG keys. O’Beirne demonstrated through GPG commit signatures that dozens of commits authored as switck were signed with the personal key of Peter D. Gray, Coinkite co-founder and CTO, who also operates as DocHex. Zach Herbert also claimed that phone numbers ending in the same two digits were tied to both the DocHex and switck X accounts (post). Additional researchers pointed to matching DNS registration patterns.
Neither Gray nor Coinkite has publicly addressed the GPG-signature findings as of this writing, and they did not respond when asked to comment on the topic. The Switch account is still active to this day, having merged code changes to Libngu as recently as August 17th, 2026.
Many in the Bitcoin industry are taking this as some sort of tangential evidence of wrongdoing. Why go out of your way to create a nym just for a particular cryptography library? This has been taken as some kind of evidence of malintent; however, a deeper analysis begs to differ. Had Gray really intended to rug Coldcard users with this RNG bug, would he really have been signing commits with his personal GPG key? Could someone be so cunning that they would hide a bug for years, waiting for its adoption to spread; yet at the same time forget to create a dedicated GPG signature for the throwaway nym? I don’t think that tracks.
It is more likely that this was a random identity created at DEFCON by Gray, probably in a random bout of paranoia. An identity which he continued to use for certain projects over the years. Pseudonymous identities are not unusual in Bitcoin developer circles after all. Satoshi himself remains the most famous example. And so on its own, this connection between Gray and Switch arguably does not amount to much in the hunt for the Coldcard hacker.
MicroPython Contributors
A handful of other open source developers have also been recently identified as having touched or influenced code that played a role in the Coldcard RNG bug.
Data Analyst LaurentMT has examined the MicroPython side of the RNG path. MicroPython is a lean and open-source implementation of Python 3, designed to run on microcontrollers and resource-constrained computers. The Coldcard firmware ultimately called MicroPython’s Yasmarang pseudo-random number generator (PRNG) fallback as a result of the bug, leading to low-entropy generation.
The code changes to the PRNG logic in MicroPython began on August 20, 2020, with issue (#6347) opened on GitHub by a user named ‘mirko’. He complained that his ESP32 hardware was always returning the same result when calling the ‘random.choice()’ function in the code in a certain way. Mirko expected random results instead. The GitHub issue logs a discussion over the following months about the proper way to handle the related logic and expected behavior, which Mirko revealed to have a counterintuitive design.
Laurent points out that “robert-hh initialized a [Pull Request] implementing the PRNG seeding change” on August 22, 2020. Dpgeorge, a maintainer of MicroPython, later on October 29, 2020, merged a slightly modified version of that pull request to the master repository, implementing “the (UID+SysTick+RTC) to address some limitations in robert-hh’s solution.”
The changes to this critical RNG-related code were thus on the master repository of MicroPython when Coldcard forked it to be used by Libngu, yet before MicroPython had made an official new version release of the library. Apparently, it is considered risky to build on top of the master version of a software repository, which is likely to be evolving with code changes, rather than build on top of an official, stable release version. The new release of MicroPython did not come until February 3, 2021, with version v1.14. To top it off, the RNG logic change was only briefly mentioned in the release announcement, saying “the urandom module will randomize its seed on import on stm32, esp8266, esp32 and rp2 ports.”
In an interview with Bitcoin Magazine, Laurent concluded in no ambiguous terms that “without this modification the bug in Coldcard code would have been immediately detected.” Commenting on the series of events that led to the bug, he also said that “there are a lot of ‘coincidences’ in this timeline,” adding that “while they don’t prove anything, I don’t see how an official investigation may completely ignore them.”
It is important to note that there is no evidence any of the developers mentioned above were intentionally trying to introduce the Coldcard RNG bug with these changes, and ultimately, it is Coinkite, the hardware wallet company, that is responsible for their implementation of the critical code. MicroPython is a large, widely used open-source project. Nevertheless, there are likely many lessons to be learned from what we might as well call — for the time being anyway — a tragic comedy of errors.
Why an Inside Job Appears Unlikely
Several factors cut against a deliberate, long-planned insider retirement attack. The ‘switck’ identity was poorly compartmentalized; the shared GPG key and other overlaps made attribution to Doc-Hex aka Peter Gray, relatively straightforward once researchers looked. The account had been largely abandoned for years. The MicroPython contributors operate in the open on a high-visibility project.
Hodlonaut’s Citadel21 investigation and other technical reviews find no clear evidence that the entropy failure was intentional. Engineer Alekos Filini’s technical report on the bug explicitly tracks the technical facts, stating that “My goal is to purely present facts and NOT make any conclusions.” Wizardsardine detailed on their Technical autopsymultiple failed safeguards and describes the failure as sitting “across a submodule boundary, which is precisely where reviewers stop looking.”
If the drains had been a classic insider retirement attack, or a long con as some might call it, the conversation today would be quite different. The last time we saw a major long con hack in the Bitcoin industry was probably QuadrigaCX, a centralized Canadian exchange whose founder, Gerald Cotten, was reported “dead in India” in 2018 amid mysterious circumstances, not long after the missing funds were discovered. The founders are accused by the Ontario Securities Commission of having misappropriated the exchange users’ deposits totaling almost 170 million CAD, over many years, before disappearing.
Instead, Coinkite’s leadership remains publicly active, responding to the incident, shipping patched firmware, assisting user migrations, and engaging on the technical details. Coinkite’s founders and operators are fairly well known and are still operating the company as of the time of writing; they have not disappeared at the same time as the funds went missing.
Meanwhile, the wave 1 funds, totaling over 1000 BTC, are still collected in three addresses, watched by hundreds of engineers and likely law enforcement such as the FBI. Were Coinkite trying to do a 5D chess-style retirement attack, they would have been far more careful in their theft of the coins. They would not have pooled them all to a handful of addresses that are easy to track, and its founders would probably be ‘mysteriously dead in India.’
While there are no conclusions and investigations will likely be ongoing for years, so far, evidence points to a cultural failure in the Bitcoin maximalist and self-custody community, a failure to broadly educate the users and influencers about good or bad etiquette in open-source culture, and frankly, arrogance on the part of Coinkite OG’s who, in hindsight, were overconfident about their own capabilities.
Last week on August 14th DMND, the Stratum V2 mining pool, announced an integration with Mempool Accelerator to introduce new transaction acceleration functionality to Stratum V2 miners. This will put individual miners in control of transaction acceleration and prioritization.
This is a fundamental shakeup to the legacy model of a transaction accelerator. These products have been historically offered by mining pools, rather than actual miners, and as such the pools have traditionally been the ones to both decide which transactions to prioritize in their templates and pocket the additional revenue for accelerating them.
Now, individual miners at DMND can handle the prioritization selection using Stratum V2, and when a block template containing such accelerated transactions is mined, the individual miner who found that block collects additional revenue for the acceleration.
“Our premise is simple: when miners build their own blocks through DMND’s Stratum V2 implementation, they unlock revenue streams that were never available to them before,” said Alejandro De La Torre, CEO of DMND. “Accelerated transactions are one of those streams. The pool used to prioritise them and the pool used to collect for them. On DMND the miner does both. It is a paradigm shift in how miners earn.”
This is a first of its kind integration of a transaction accelerator system, and opens the door for new revenue streams for individual miners. Now that this type of direct revenue sharing with additional streams of income has been demonstrated, it begs the question of why are other mining pools that own or integrate with accelerator services not doing similar revenue sharing?
This type of design and revenue sharing was made directly possible by Stratum V2.
“Mempool Accelerator lets anyone get their stuck transaction confirmed by paying an out of band fee, which prioritizes their transaction with over 80% of the network hashrate. DMND’s integration is the first of its kind, Stratum V2 miners using Job Declaration can now earn their share of that revenue.” – Orange Surf, Head of Strategy & Research at mempool.space
Bitcoin company leaders and open-source developers are publicly stating that Chinese AI models are currently outperforming restricted American frontier systems in defensive cybersecurity work, forcing researchers to rely on them to secure critical Bitcoin infrastructure.
Rob Hamilton, CEO of AnchorWatch, a Bitcoin self-custody insurance company, reported cripling American AI restrictions. After integrating OpenAI’s trusted cyber program (having already completed KYC months earlier), he was blocked from further analysis on a codebase he had already responsibly disclosed. “It absolutely guts me as a patriotic American to have to do this, but I will be going back to using Chinese open source models to conduct my research to protect Bitcoin infrastructure,” Hamilton wrote. “Black hats will not hit these issues. The white hats will.” Days later, he gained access to OpenAI’s “Daybreak Blue” cyber model and was blocked again within 19 minutes while red-teaming Bitcoin infrastructure.
Francis Pouliot, founder of Bull Bitcoin, a Bitcoin-only exchange focused on self-custody infrastructure, described the situation bluntly. “I have never seen OpenAI this cucked. It’s cucked beyond belief now. Not even for security, for anything related to Bitcoin,” he posted. “USA AI industry is completely cooked if they don’t change this path,” he concluded, adding “Open-source Chinese LLMs. [orange heart emoji],” meaning that open Chinese models like Kimi K3 are actually helpful to Bitcoin. In a follow-up, Pouliot detailed how a Chinese open-source model identified a money-stealing exploit in a project he was auditing, demonstrated it on regtest, and helped patch it. When he asked the American models he pays for to review the same patch, they refused.
PortlandHODL, a Bitcoin Core contributor who builds for AnchorWatch, publicly highlighted the performance gap. “US-based Frontier AI Model – ‘You’re absolutely right!’ Chinese Open Model – ‘78 critical vulnerabilities found.’ The implications of this are unfathomable,” he posted. In a follow-up, he added that he felt he was “basically asking Xi to not get my software hacked at this point,” calling for OpenAI and Anthropic to create proper access programs for U.S. citizens doing defensive security work.
Alex Thorn, Head of Firmwide Research at Galaxy, signed a recent Bitcoin Policy Institute open letter demanding trusted access to frontier models for open-source defenders. “Americans should not have to rely on Chinese AI to defend themselves, their projects, companies, or clients from cyber-attacks,” he wrote. “RED TEAM NEEDS THE MODELS.”
On August 10, the Bitcoin Policy Institute — a Bitcoin and, of late, AI-focused policy think tank — published an open letter signed by more than 70 organizations across the digital-asset ecosystem, including major custodians, exchanges, mining firms, and open-source development groups. The letter calls on frontier AI labs to establish clear trusted-access programs for qualified open-source and digital-asset defenders. It argues that current restrictions and safety guardrails leave legitimate security researchers without access to the strongest models, forcing them to rely on less capable open-weight alternatives while sophisticated attackers face no such limits. The signatories request early access to cyber-capable models, sufficient compute, secure environments for reviewing code, and direct channels with lab security teams, stating that frontier AI could become one of the most powerful defensive technologies available if defenders are given fair access.
These statements reflect a broad pattern among Bitcoin security researchers: American models from OpenAI and Anthropic frequently refuse or restrict legitimate defensive work, even to users who are supposed to have been granted explicit access, while Chinese models such as Kimi K3 operate without the same guardrails and are delivering confirmed results. Concerns about hosting infrastructure of Chinese models being an attack vector can also be mitigated, since they are open source and can be run on American-hosted data centers, a trend that is likely to threaten the U.S. AI market if it continues.
Coldcard Exploit Triggers Ecosystem-Wide Response
The cybersecurity pressure became acute in the Bitcoin industry after a firmware flaw in Coldcard hardware wallets was exploited beginning July 30, resulting in the theft of well over $100 million in bitcoin from seeds generated with insufficient entropy. Bitcoin Magazine published an urgent advisory urging affected users to migrate funds: COLDCARD SECURITY RISK: IMMEDIATE ACTION REQUIRED.
In response, a volunteer effort known as the Bitcoin Red Team formed, led by open-source developer Calle (creator of Cashu and the Android version of Bitchat) and Rob Hamilton. The group has conducted large-scale AI-assisted audits of Bitcoin open-source repositories, using models including Kimi K3 as the primary workhorse alongside limited access to Western systems. Early results, covered by Bitcoin Magazine, showed thousands of findings across hundreds of projects, including dozens of critical issues, with spending covered largely by OpenSats.
By August 8, after more than 100 hours of work involving dozens of contributors, the team reported scanning 501 projects and producing 7,958 findings, of which 1,280 were rated high or critical severity. The majority of compute spend continued to go to Chinese open-weight models.
Lessons from the Red Team Campaign
Most recently, Calle shared lessons from the intensive red-team period. The effort has essentially completed a basic scan of virtually the entire Bitcoin open-source landscape; low-hanging fruit is largely exhausted, the developer wrote on this X account. Maintainers across projects have validated many of the critical and high-severity reports, while response times from projects vary widely and serve as a signal of overall health.
Key takeaways include the need for every project to maintain its own permanent AI audit pipeline going forward. Projects that began such reviews months earlier are in a markedly stronger position. Unmaintained repositories should be treated as likely broken and unreliable.
Calle also warned that the human-only era of open-source security review is over; verification is now effectively free, and information overload must be handled with AI rather than complaints about PR slop. Multiple concurrent and diverse human approaches remain the strongest method for finding vulnerabilities, and external red-teaming will likely be required indefinitely.
Calle also repeatedly emphasized that developers should stop writing security-critical code in C. In a follow-up post he explained: “we’re finding memory-safety vulnerabilities in c projects that are prevented by default in many other languages. In the past, finding a simple buffer overflow wasn’t enough. You’d need a highly skilled hacker to turn the vulnerability into a working end-to-end exploit. Today, that’s a single prompt.”
Bitcoin was the first major open-source ecosystem to confront this collision between accumulated human code and frontier AI capability. The rest of the software world is expected to follow.
Author’s note: In my view BIP110 is both useless and harmful, and I do expect it to fail (see scenario 1). Despite this I tried to write this article as factually as I could, entertaining different possible scenarios, as I do hope it may provide some clarity on this soft fork attempt.
The OP_RETURN debate has escalated to the point where Bitcoin Knots implemented BIP110: a consensus protocol change that temporarily limits the size of OP_RETURNs and intends to reduce other types of data on Bitcoin’s blockchain as well.
However BIP110 does not have consensus: not everyone agrees there’s a problem that requires solving in the first place, nor that BIP110 solves it in any meaningful manner, while it restricts Bitcoin in potentially harmful ways. Most obviously, Bitcoin Core — still by far the most-used Bitcoin implementation — has not adopted BIP110, while only some 1-2% of hash power has been signaling support for it in recent weeks.
Nevertheless, BIP110-nodes like Bitcoin Knots will soon — starting from block 961,632, to be mined on or around August 8 — reject blocks that don’t signal support for the upgrade.
Here are the three main scenarios for how that could play out.
Scenario 1: (almost) no miners signal
If current miner signaling is any indication, this is the scenario to expect.
From the perspective of anyone running Bitcoin Core or other non-BIP110 enforcing nodes and wallets (the vast majority of the Bitcoin ecosystem) blocks will be mined as usual, and transactions will be processed like normal too. Anyone who’s not actively tracking these events on social media or elsewhere may not even be aware that anything unusual is going on, and in a practical sense for them there really won’t be; BIP110 does not affect them.
The same is not true for anyone running Bitcoin Knots or other BIP110-enforcing nodes, however. Since their software will reject non-signaling blocks, they basically wouldn’t see any new blocks at all (or perhaps a few per week), and incoming and outgoing transactions won’t confirm (or incredibly slow). In practical terms, these nodes would stall and become unusable.
If this happens, BIP110 proponents will have to decide between waiting to see if things improve for them (see scenario 3), giving up (switching back to non-BIP110 software), or deploying a next protocol change, like hard forking to a different proof-of-work mining algorithm.
Such a hard fork would possibly allow for mining with GPUs again, therefore letting more people mine new blocks to generate a blockchain with the BIP110 rules enforced. However this would also mean that BIP110/hard fork nodes permanently split off from the rest of the Bitcoin ecosystem to essentially create a new cryptocurrency. (More on this below)
Scenario 2: (almost) all miners signal
This is the scenario several prominent BIP110 proponents predict.
In this scenario, when the mandatory signaling window starts, all miners will suddenly signal for BIP110. Or at least, a majority of miners will signal AND reject any non-signaling blocks, so that all blocks that end up in the blockchain include a BIP110 signal.
If this happens, all Bitcoin nodes (Knots and Core alike) remain compatible, and the signals in the blocks indicate that miners plan to start enforcing the BIP110 rules another two weeks later. BIP110-violating transactions should by early September no longer end up in blocks.
In essence, this is the success scenario for BIP110; although only a small faction of developers, miners and users pushed for it, the upgrade goes into effect across the entire network.
…However even in this scenario there is an important caveat.
Blockchain signaling is a useful coordination mechanism for soft fork deployment, but it technically does not guarantee that the new rules will be enforced. Miners can signal support for the upgrade without actually using BIP110 software, which they for example could elect to do simply to ensure their blocks aren’t rejected by Bitcoin Knots nodes during the mandatory signaling window.
Bitcoin’s protocol rules are ultimately enforced by economic nodes however, and nothing currently indicates that most of these will enforce the BIP110 rules even if all blocks include a signal. So if BIP110-violating transactions are later accepted by most miners regardless, these economic nodes would accept blocks that include them, while BIP110 nodes would not. The blockchain would split between nodes that do and do not enforce BIP110 after all.
Scenario 3: a sizable minority of miners signal
This is the scenario that would immediately split the chain.
Currently some two percent of miners signal support for BIP110, which is probably too little to be meaningful (see scenario 1). But let’s imagine this quickly increases tenfold or so. We also have to imagine that this sizable minority itself rejects any non-signaling blocks— else it would still be indistinguishable from scenario 1 where BIP110 nodes stall (since they require ALL blocks to include a signal).
If the sizable minority is both signaling and rejecting non-signaling blocks, they’d start to build their own minority blockchain with only signaling blocks in it. Blocks on this minority chain would confirm significantly slower than usual — maybe just one or two per hour — but BIP110 nodes remain reasonably usable. And after a few months the mining difficulty would adjust, so blocks are found (closer to) six times per hour again. Another couple of weeks later the BIP110 rules would go into effect.
Meanwhile, Bitcoin Core and other non-BIP110 enforcing nodes would still operate fairly normally as well. Their blocks will confirm a little bit slower for a while — maybe about four or five per hour — but after a couple weeks mining difficulty adjusts here too, to also bring this back to six per hour on average. The BIP110 rules would never go into effect on this blockchain.
As a result, a BIP110 blockchain and a blockchain with the original rules would then exist side by side as two different cryptocurrencies, indefinitely.
There is one notable caveat to this scenario as well, however. If the BIP110 chain were to overtake the original chain in length later on (due to miners moving to the BIP110 chain), all nodes — Core and Knots alike — would accept the BIP110 chain as the only chain. The original chain would in this case be discarded, or wiped out.
This one-sided wipe out risk is in fact why BIP110 proponents expect all miners to signal preemptively, preventing a split. Miners won’t want to mine on a blockchain that can later be discarded, they argue, as that would also mean losing all block rewards they earned on it.
In actuality, users and miners that want to prevent that the original chain can get wiped out could do so however: they can manually invalidate any block on the minority BIP110 chain while it still is the minority chain. This way their nodes would reject switching to it even if it becomes longer at any point in the future, making the split permanent also.
So what exactly happens if the chain permanently splits? If and when the Bitcoin blockchain permanently splits, it essentially marks the creation of a new cryptocurrency, or forkcoin. Everyone who owns BTC at the time of the split automatically receives the equivalent amount of coins on the new blockchain, not unlike what happened with Bitcoin and Bitcoin Cash in 2017.
However in reality these things aren’t necessarily as straightforward, and if BIP110 does cause a chain split under any of the scenarios above there will likely be some complications.
For one, there’ll almost certainly be disagreement over which side of the chain represents “Bitcoin” (“BTC”), and which side is the new forkcoin. It seems likely however that the blockchain with the original rules will by most people be considered “Bitcoin”, whereas the blockchain with the BIP110 rules will be called something else; we’ll call it “BIP110 coin” for now.
Accessing the BIP110 coins then, will require BIP110-specific software like, indeed, Bitcoin Knots. The new coins won’t show up on Bitcoin Core nodes or most wallets.
However, BIP110 does not currently include replay protection. This means that transactions on one chain can be copied (“replayed”) on the other chain. Instead of just sending BTC, users could unknowingly also send the equivalent BIP110 coin to an identical address on the BIP110 chain— or vice versa.
It’s difficult to estimate at this point how much the forkcoins will be worth, or even if they will be worth anything at all. The lack of interest in buying BIP110 coins via fork future contracts does suggest there may not be much interest to buy them after a split either. But if you nevertheless want to be sure you’ll receive BIP110 coins if there are any, it’s probably best to self-custody your BTC (have access to your private keys), and don’t send any transactions until the dust settles and there is more clarity on how to proceed.
Over the last few days, people who were trying to do everything right lost their Bitcoin. They bought a respected hardware signer, generated a seed offline using that device, and trusted the device to do the one thing a signer exists to do: produce a number no one else can guess. The Coldcard did not. A preprocessor guard that checked the wrong thing had quietly routed seed generation to a weak software PRNG (pseudorandom number generator), MicroPython’s Yasmarang, instead of the hardware entropy source. On some models the effective entropy collapsed to around 40 bits. The flaw shipped in March 2021 and sat in publicly readable firmware for more than five years. Attackers swept 500 addresses before anyone understood why; within days Galaxy Research’s tally reached 4,585 addresses and nearly $90 million; the attack is ongoing as of the date of this article.
Coinkite’s working assumption, with wide agreement on X, is that someone used AI to comb the publicly available firmware to find the bug. Whether or not that’s how this attacker found it, the next one will. While an AI-assisted audit was run weeks before the theft, it found nothing (potentially due to the capabilities of the model, potentially due to the specific construction of the search). Since the attack started, researchers have shown several frontier models locating the same flaw in minutes from a single prompt. The code sat open to human review for five years and no human caught it.
In the age of highly skilled AI, everything that is distributed is readable, or soon will be. Strip a binary of its symbols, run it through a decompiler, and out comes the pseudo-C that greets anyone who has opened Ghidra: nameless variables, flattened control flow, functions labeled FUN_00401a20. Unreadable to most people. That high barrier to human understanding was the entire security premium of “closed source.”
A compiled program has no choice but to tell the truth. Code that stays encrypted cannot run. At the moment of execution the processor must receive the actual instructions, so whatever the program does, it hands the machine a complete and exact account of how to do it. The information is all there in the machine code. Obfuscation does not, and cannot, remove it.
If reading a binary sounds too hard for a machine to master soon, weigh it against what machines are already doing to problems far harder. Reading a binary is analysis: every fact you need is in front of you, and the work is extraction. Mathematical invention is another order of difficulty, because it demands an object no one has ever seen. At 02:19 UTC on July 20th, Levent Alpöge, a mathematician working with Anthropic’s Claude Fable 5, posted a counterexample to Keller’s Jacobian conjecture, a problem open since 1939 and hard enough to sit on Stephen Smale’s list of challenges for the twenty-first century. Generations had tried it. The disproof is three polynomials in three variables. Lean verified it within hours, and it is short enough for anyone to confirm in a computer-algebra system in about a minute.
Set that pace beside the modest task of reading machine code already sitting out there on the Internet. Today’s models handle source and decompiler output better than raw bytes, so a fully closed binary keeps a thin margin. That margin is a cost speedbump, and it is eroding at the speed you are watching everywhere else. Betting security on how long it lasts means betting against a clock that is only speeding up.
The same capability that finds your entropy bug reads your proprietary method. This is the quieter casualty, and it impacts companies that never thought of themselves as exposed to open-source anything. Trade secrecy in shipped software was always just obscurity in a suit. The law has said so for as long as trade-secret law has existed: reverse engineering a product you lawfully possess is fair play, and therefore a secret survives only while that reverse engineering stays expensive. When the cost of extraction falls to a subscription and a prompt, the secret embodied in the code you hand your customers stops being one. Your clever algorithm, your undocumented format, your edge in the binary: legible to anyone who cares to look, on a timeline increasingly measured in minutes.
None of this necessarily makes open source safe. Heartbleed hid in the most widely deployed TLS library on earth for two years, because visibility without funded attention finds nothing. The xz backdoor showed that the open contribution model is itself an attack surface, one a patient adversary can walk through with a friendly face and two years of good commits. While openness once was a shield, it is no longer. What it does buy is reviewers who are permitted to look, builds which can be independently reproduced and verified, an exit when a vendor dies or turns, and acknowledgment that this all will happen whether you like it or not.
Now we must assume every line shipped will be read by someone who wishes harm, because it will be. The defender holds one structural advantage the attacker never will: time. You can turn the same frontier models on your own code before release, in the space between commit and ship, while the attacker waits for a binary that does not yet exist. Make your builds reproducible, so it ties back to the source and the source can be checked. Design to fail closed, and keep the trusted core small enough that one bug cannot take everything. For the specific business of holding Bitcoin, learn the lesson Coldcard is teaching in real time: own the entropy you cannot afford to have guessed, keep the secure element minimal and behind a published interface, and spread your keys across independent implementations, so that no single device, and no single vendor’s mistake, is the whole of your exposure.
For Bitcoin the stakes are unforgiving in a way they are not elsewhere, since mere knowledge of the private keys grants possession. The entropy bug has left permanent scars. Patching the generator does nothing for the seeds it already produced; a weak keyspace stays sweepable forever, and disclosure hands the attacker the recipe. We have watched this before. The Milk Sad vulnerability in the libbitcoin explorer tool, bx, seeded private keys from a 32-bit value, and attackers were draining the wallets it produced before the flaw was ever made public. Attackers keep their own schedule, invited or not. For money that cannot be clawed back, “findable eventually” is a synonym for “gone eventually.”
Bitcoin never trusted obscurity. The protocol is open, its rules checkable by anyone, its security resting not on secrets but on mathematics and incentives that hold in full view. The hardware and software we build around it deserve the same standard, because the alternative is no longer on the table. The choice was never open or closed. It was disciplined or exposed.
The broader lesson of this Coldcard situation is that having closed source software is like having a seed generated by a broken Coldcard; it looks good but it’s fundamentally built on sand. Everyone can read the code — the only question left is whether you acknowledge that fact, or you and your users learn it the way Coldcard’s users did, one drained address at a time.
This is a guest post by Colin Crossman, who is the Wyoming Deputy Secretary of State. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
Rallied by the recent, catastrophic vulnerability in Coldcard hardware wallets, exploited to the tune of over $100 million, the Bitcoin community has rallied to prevent future critical bugs in the industry’s open source software.
Led by Calle, software engineer, avid vibe coder and creator of the Android version of Bitchat, and Rob Hamilton, the CEO of Anchorwatch a Bitcoin self-custody insurance company, the Bitcoin Red Team has now secured funding, with over $40,000 spent in AI tokens to audit over 390 Open Source repositories across Bitcoin.
Colloquially called the “Bitcoin Red Team”, with memes about Rob Hamilton and Calle now being the CEO and CTO of Bitcoin, this AI-driven security audit is having a serious impact across the industry. Just a few days ago, buried in the news of ongoing thefts of bitcoin from MK3+ Coldcards due to an RNG bug, Boltz exchange announced it would be pausing operations to catch up with AI-driven hacking attempts.
“27.5 hours in, we’ve filed 4,962 findings across 390 projects. 85 critical and 635 high severity issues. We’re at 2.31 h+c findings per person per hour,” said Calle in the most recent update on Red Team efforts to shore up the industry’s cybersecurity.
The Red Team security review effort is using models like Kimi K3, GPT Sol, Fable, Opus and GLM5.2, some of the most expensive and cutting-edge models in the market. At first, access to OpenAI and Anthropic models was limited, leading to an over-reliance on Chinese open-source models, a fact which many in the industry lamented and saw as a bad omen for U.S. AI dominance. But as the Red Team project grew in influence since last week’s Coldcard hack, connections have been established and confirmed with OpenAI, giving Red Team access to GPT Sol. Hamilton’s mention of Fable in his August 4 tweet suggests access to Anthropic has also been established.
Expenses which were last tallied at over $40,000 have been covered by OpenSats, a non profit 501c3 organization dedicated to funding open source Bitcoin development projects. The Bitcoin Red Team does not currently have a website or a GitHub repository to link to, but the team is made up of many individuals within the Bitcoin industry. Individuals publicly thanked for their support include but are not limited to danielabrozzoni, lylepratt, stutxo, benthecarman, thesimplekid.
Hamilton shared that a custom harness has been built and is evolving quickly. Made up at one point of 171,599 lines of code, the harness is designed to identify and test critical Bitcoin software libraries and high-load-bearing code, identify and document vulnerabilities, reproduce them and package the proven data into useful reports. Ultimately delivering the information responsibly to engineers in the industry. Hamilton also shared that Red Team intends to open source the harness such that Bitcoin companies can run it against their closed-source code.
Red Team is actively reaching out to relevant open source projects with critical vulnerabilities discovered, leading to a broad sense of dread from engineers in the industry when they receive cold direct messages from Hamilton or Calle, as seen in various humorous screenshots shared on social media.
Among the key insights shared by Red Team publicly as this AI-driven security update of Bitcoin FOSS takes place, Hamilton shared that engineers with specific subject matter could sometimes yield high-value results from the Harness, which might otherwise “smell out something is wrong,” but might be missing niche context. An insight which speaks to the importance of having human intelligence and experience work hand in hand with the AI to efficiently identify critical vulnerabilities.
Hamilton also ended a multi-day Red Team effort after the Coldcard hack with some personal notes. He said that the discovered vulnerability in Coldcard random number generators and consequent exploitation of the bug by hackers had been a “spiritual attack” on Bitcoin and the self-custody ethos of the industry, “I mean that in the literal sense of the words”. After expressing grief for the losses experienced by many Bitcoiners during this now historic hack, Hamilton closed his tweet with a tone of hardened resolution:
“While things are not easy right now. I have the highest conviction ever in my life that the idea and technology of Bitcoin is worth fighting for. To that end. There is no Bitcoin without self-custody. This is non-negotiable.”
The Coldcard hack last week dealt a low blow to certain elements of the Bitcoin industry. A somber introspection has begun to question many of the practices and assumptions involved in securing bitcoin at a retail level. The consequences of this process might not be visible for many months.
Some are saying that self-custody is dead. Some reports estimate that over 11,000 bitcoins were moved to custodial exchanges last week as users fled one of the most popular hardware wallets in the Bitcoin industry. The hack, which is ongoing and users can still save themselves from, has seen north of 1,300 bitcoins stolen, with some estimates as high as 2,000 coins.
Coinkite in particular and its most vocal founder, NVK, had very strong opinions about what it took to secure bitcoin private keys from hackers. Its hardware wallets were airgapped to make sure malware could not exfiltrate data through USB cables. It used low-resolution, LED screens to avoid the complexity of touch screens. It developed protocols like BBQR and integrated NFC so that information could be transferred between the device and a computer without them touching or sharing SD cards. The list of paranoid design choices that made Coldcards iconic is long.
Yet the hackers involved in the theft of bitcoins held in Coldcards last week did not use any methods you might see in a modern spy movie. They exploited the one feature Coldcard should have had absolutely locked down. The generation of keys with high enough randomness, also known as entropy. In other words, secrets securing that are actually, mathematically hard to guess. While the devices were intended to use high-quality sources of entropy, the firmware had a bug which did not, resulting in Bitcoin private keys that were, in turn, easy to guess. The bug went undiscovered for years, and the product only grew in popularity in the meantime, until last week.
“Just buy the ETF bro”
Despite this loss, which wounded a cohort of Bitcoiners who were among the most committed. Bitcoin can not give up on self-custody and expect to retain its integrity. At least that is what many in the industry believe, and the case for that is clear.
Satoshi Nakamoto’s white paper clearly intended Bitcoin to be a solution to trusted third parties and intermediaries. It eloquently made the case against trusted hierarchies of finance, as the 2008 financial crisis revealed the deep systemic risks and flaws legacy finance has led to. Many believe the 2008 crisis was never escaped, its consequences haunting us to this day.
This may be unpopular, but we never escaped the 2008 financial crisis. We just shifted the pain.
Going further back to the birth and proliferation of the modern banking system and its fiat currency. The 6102 executive order signed by President Franklin D. Roosevelt in 1933 saw the persecution and confiscation of gold from centralized trusted third parties and citizens alike. $300,000,000 in gold was returned after the executive order threatened gold owners with heavy fines and jail time if they did not sell their bullion to the banks at $20,67 per ounce. Over 14 million troy ounces worth of gold were turned in as a result. Another 200 million troy ounces are estimated to have been held in the American banking system at the time. The banking system, not just in the U.S. but worldwide at the time, was built atop the gold standard.
The U.S. was the largest economy of the world at the time, with the biggest concentration of gold inside its borders. Its abandonment of the gold standard was a death blow to gold as a free market pricing mechanism for goods and services as a whole. Governments throughout the world, now free from the chains of sound money, quickly fed and fattened from the hidden tax of inflation. At the time of the EO, the price of gold was artificially fixed to $20.67 an ounce; not a year later, it was repriced to $35 with the passing of the Gold Reserve Act in 1934, a 69% devaluation in the dollar.
The fiat standard was thus delivered to governments throughout the world on a silver platter, by an unholy alliance between the banking system and politicians. It granted central banks the legal right to counterfeit money, to print it at will. It was soon followed by World War Two, which was of course funded by fiat currency. Tens of millions of people sacrificed in this war at the altar of state power.
Confiscation of gold in a rising power like the United States murdered the gold standard. It, however, could not have been possible if civilian custody of gold had been wider and more distributed. Many of the civilians who returned millions in gold after the 6102 EO had just taken it out of their accounts in a bank run. Their names were known, the amount of gold they held, tallied.
If gold was easier to move in large quantities. If private gold ownership totals had been more ambiguous. If removing the free flow of gold had not been so easy for the state to do, by knocking on the doors of bankers and pointing a gun, then perhaps the economies of the world would not have been able to withstand such a vast and destructive war, as was WWII for so long, in the following decade.
Bitcoin is Gold, Engineered To Survive a 6102 EO
Bitcoin poses an alternative to gold, designed to learn from its inadequacies. Bitcoin has better properties to resist and survive such a confiscation. Bitcoiners envision and aspire to unlock a world that adopts Bitcoin as a global monetary standard. Where a large minority or even a small majority of the global economy uses Bitcoin as their primary store of value. In such a future, Bitcoin would take the place of gold and return sound money to the so-called capitalist order.
To reach global reserve currency and defend this position, Bitcoin will need to be better than gold, and it can be better precisely because of its digital nature. The control of private keys, as difficult as it seems now in the shadow of the Coldcard hack, nevertheless can be far more powerful than any physical vault. Multi-signature scripts alone unlock distributed storage of Bitcoin private keys, such that a threshold of them must approve to move coins. This means that multi-jurisdictional, multinational vaults can exist and escape or resist the greedy hands of a large state that might attempt a new kind of 6102 takeover.
The digital nature of Bitcoin means large amounts of value can be moved easily as well, without having to send the navy on a mission to pick up the gold. Without having to build a trusted hierarchy of banking custodians to transfer it. Civilians, with tools available today and better tools that are yet to come, might be able to hide their Bitcoin ownership as has been done in war-torn countries like Ukraine already, escaping a fearsome state’s grip over the public’s wealth.
Ultimately, a major hardware wallet manufacturer has failed the Bitcoin industry. The fundamental qualities of money remain the same, and among them all, as identified by Aristotle and others beyond him, Bitcoin remains king.
Over a thousand bitcoins are believed to have been stolen so far in a hack that started to be discussed on social media in the afternoon of July 30th. Coinkite, one of the most reputable hardware wallet manufacturers, was revealed to have a critical bug in the way it generated secure private keys for its Bitcoin hardware wallets. Industry experts believe AI was used in the breach.
Coldcard MK3 devices with firmware version 4.0.1 (March 2021) through 4.1.9 are the worst affected. 12- or 24-word seeds generated by the device that did not include user-generated dice rolls or a BIP 39 extra passphrase are vulnerable.
The vulnerability was a specific line of code in the firmware, a low-level software codebase that controls the hardware. This firmware appears to be upgradable. The Coinkite advisory was updated this morning, advising users to upgrade device firmware for all three chips, MK3, MK4 and MK5 devices, including the Coldcard Q:
Coinkite also explained in their advisory that updating the firmware does not mean that the private and public keys generated by the vulnerable firmware before it are now secure; those keys remain vulnerable as they were effectively created with a weak password. After the firmware is updated, a new wallet needs to be created, and the funds need to be sent onchain to the new addresses to secure the funds. Coinkite wrote:
“Updating the firmware does not change or repair an existing seed. If your seed was generated before the fixed firmware version for your model, follow the migration guidance below unless the independent dice-entropy exception applies to you.”
Some Multisignature Wallets May Be At Risk
Peter Todd, Core contributor and cybersecurity engineer, today addressed specific edge cases for multi-signature wallets that use a threshold of Coldcards to secure funds. “Example case: you have a 2-of-3, with 2 Cold Cards, and a 3rd uncompromised device. If you move your funds, the moment your script is revealed for the first time – previously hidden behind the address hash – the attacker now knows enough to use the compromised 2 cold card keys to steal your funds.”
The transaction that reveals the multisig script might be unconfirmed, giving hackers enough time to create a competing transaction with a higher fee. Fortunately, such cases have a solution: the MARA mining pool can help in this case with their private mempool mining service, Slipstream; “because they promise to keep your transaction – and thus pubkeys – secret until they’re already in a block. Dramatically reducing the ability of the attacker to steal the funds,” said Todd. He added that “If you’ve already reused addresses, this isn’t relevant, and you should just try to move your funds ASAP. But if you haven’t, MARA may be able to help.”
Beyond The Immediate Crisis
NVK, one of the co-founders of Coldcard, published a long post on X with an initial analysis beyond the basic security steps needed to secure funds. In it, he wrote that the company is “committed to working with affected users who want to pursue a police report, insurance claim, or their own investigation”, including “a written incident summary specific to your loss and any transaction data we can share”.
Beyond the immediate crisis, NVK pointed to a broader tech shift as the hacking capabilities of AI begin to change previous cybersecurity dynamics and expectations. In the blog post he wrote:
“To every other developer: we believe this is a sober reality of the new AI paradigm. AI-assisted code review can now find latent bugs at a speed that is outpacing even the industry’s most seasoned experts. If your firmware is open-source or has ever been public, assume it’s already being read by attackers and defenders alike.”
The hack and over 70 million dollars in estimated stolen funds in the past 24 hours are an effective bounty paid to hackers who are now likely auditing every wallet codebase available for vulnerabilities. While the Bitcoin and broader crypto industry has generally operated under the assumption that hackers will test their code, the development of AI models optimized for cybersecurity accelerates these processes.
Industry experts gathered in a long X Spaces public call last night, discussing the topic for many hours. Beyond the immediate recommendations and answering questions to Bitcoin users throughout the long Spaces, analysis of what is likely to follow in the coming weeks was also discussed. Other wallet providers are likely to get probed, and especially open source projects which generate private key material will be tested.
The X Spaces was not recorded, likely to preserve the privacy of everyone in the call; however, initial sentiment suggests companies will need to be auditing their code with the latest frontier models, as a matter of survival. The latest cybersecurity-oriented AI models by Anthropic, OpenAI, Moonshot’s Kimi K3 and others are already available to the public. Many companies in the Bitcoin industry already use these to test the integrity of the code, but some might not be, and the race to find vulnerabilities in wallet-facing code will certainly continue, especially in the following weeks.
Ultimately, today we grieve lost coins, and a state of introspection and careful review occurs. Beyond this now historic hack will be an open source self-custody industry and infrastructure that is likely to be orders of magnitude more secure, with very hard lessons learned. After all, every hacker with an AI agent is likely testing defenses now.
Multi-vendor, Multi-key Wallets and Covenants
Future high sovereignty wallets, be it at the retail or corporate level, are likely to not depend on any single vendor. Multisignature wallets, when well done, can distribute vulnerability risks across different code bases, teams and hardware.
User-generated entropy was also a major theme in the X Spaces discussed earlier, with dice roll-generated entropy brought up regularly as a solution. Coldcards, as well as other hardware wallets like Foundation Devices, guide users on how to add their own entropy properly; many dice need to be rolled, ideally north of a hundred individual rolls. Once done, however, dice rolls represent a non-software source of randomness for wallets that also separates users from the edge-case risks in software- or hardware-generated entropy.
Covenants a popular soft fork among a certain niche in the Bitcoin industry have also started to be brought up as further step to strengthen the self-custody industry. This upgrade to the Bitcoin consensus which might be hard fought if achieved at all, could give users important smart contract capabilities, such a wallet that can only send to a white list of addresses, something not possible in Bitcoin script today.
TLDR: Coldcard MK2, MK3, MK4, MK5 and Q are being drained. A bug lets attackers find your seed phrase without any action on your part. Only wallets generated using the dice roll method are safe, assuming you rolled at least 50 dice. If you don’t know, don’t remember, or aren’t sure, move your funds immediately.
This is a critical issue that requires immediate action. If you used a Coldcard to generate a word seed and did NOT use the recommended 50+ dice rolls to provide your own entropy after the end of 2020, your word seed is not secure. It was generated without a sufficient amount of randomness, and can be brute forced by a malicious attacker. Wallets are actively being drained now. This issue also affects any ephemeral keys and session keys for Clone Coldcard or Key Teleport features, and BIP 85 seeds generated from a compromised seed. YOU MUST STILL MOVE YOUR FUNDS.
This attack is being actively exploited, with around 1000 BTC seen moving on-chain connected to the vulnerability.
Breath, and relax. You must move your funds to a new word seed, or a word seed generated by a different device, in order to secure your funds.
– If you have another hardware wallet that is not a Coldcard, send your funds there. This is the quickest and simplest way to get them someplace secure.
– If you do not have another hardware wallet, and only have a Coldcard, generate a passphrase using at MINIMUM six seed words from the BIP 39 word list. Use this guide to select your words for the passphrase,do NOT pick them yourself. Check your wallet fingerprint (or an address), power down your device, restart it and re-enter the passphrase. Confirm that the fingerprint (or address) matches, and send your funds to the passphrase wallet. This is not a permanent solution. This is simply giving you enough security that an attacker will not be able to brute force your keys in a matter of days, and you can generate a new seed without being in a state of panic. Make sure your passphrase is written down securely.
– If you have no other options, or are uncomfortable with using the device at all, Nunchuck wallet available on mobile and desktop. Take your time, don’t rush yourself too fast, and make sure that all of your backups are done properly. After you have verified backups, send your funds to this wallet. If you are managing significant sums, Nunchuck has support for multisig. You can create one using multiple devices. Blockstream Green and Bluewallet are two other options for software wallets.
Once your funds are secure, take a minute and relax. Coldcards are still safe to use as long as the word seed is generated securely. A firmware patch has been released here. Any word seed generated after this firmware update should be secure (and you can use the dice roll option too). If you have transferred your funds to a hot wallet, or something less secure, your Coldcard is safe to use after applying the firmware update and generating a new seed.
Once you have secured your own funds, stop and take stock. Reach out proactively to anyone you know who might be using a Coldcard that was vulnerable when they generated their seed. Inform them of the issue, and if needed (and you are capable) help walk them through migrating their funds. Everyone doesn’t pay attention to Bitcoin news on a regular basis, so many people might be unaware that they are even vulnerable.
Disclaimer:This article is for informational and educational purposes only and does not constitute financial, legal, or technical advice. Readers are solely responsible for managing their own private keys and executing fund transfers. Bitcoin Magazine and the author assume no liability for any loss of funds, technical errors, or operational missteps resulting from actions taken based on this content. Always independently verify security alerts directly through official project channels before taking action.
Bitchat, Jack Dorsey’s censorship-resistant, Bluetooth-enabled messaging app, has gone viral again, this time due to the Indian Government trying to get it banned from GitHub. In this latest round of authoritarian measures versus decentralized technologies, Bitchat has won.
In July 2025, Jack Dorsey announced a new messaging application he described as a weekend project. The app, called Bitchat, was designed to work without internet access, phone numbers, user accounts, or central servers. It relied instead on Bluetooth mesh networks for local communication and the Nostr protocol for wider reach.
A year later, that same application became the subject of a formal takedown request from India’s cybercrime authorities during a period of student protests. The episode offers a clear illustration of how cypherpunk ideas—building systems that function without permission from intermediaries—continue to shape tools used in moments of political tension.
Calle, one of the main developers behind the Android version of the app, took the statements from the Indian government as a positive review of Bitchat’s effectiveness, tweeting:
“India forces GitHub to take down Bitchat
‘Bitchat enables anonymous communication without mandatory user registration, phone number verification, or centralized logging of communications.
The technical architecture of the application significantly impedes interception, attribution, and investigation by law enforcement agencies.’ – Government of India”
What Bitchat Is
Bitchat is a peer-to-peer encrypted messaging application. Devices form local mesh networks over Bluetooth, automatically discovering nearby peers and relaying messages across multiple hops. When internet connectivity is available, the app can fall back to Nostr relays. Users can join public local channels, send private end-to-end encrypted messages, and access location-based channels organized by geographic zones.
The application requires no registration and includes a panic feature that clears stored data. The code is open source, with the primary repositories hosted under the permissionlesstech organization on GitHub. The iOS version is available on the App Store; the Android version is on Google Play and distributed via GitHub releases, as well as many other app stores like Nostr’s Zapstore. Recent updates added the ability for Android devices to share the installation file directly with nearby phones over Wi-Fi or Nearby Share, letting new users join the mesh easily without the need for internet access.
Key figures associated with the project include Jack Dorsey and open-source developer Calle, known for work on Cashu ecash. Bitcoin Magazine has previously noted experimental demonstrations of offline Bitcoin-related payments moving across the same mesh.
Earlier Deployments
Bitchat first saw significant real-world use during periods of government-restricted connectivity. In September 2025, during unrest in Nepal, the app recorded nearly 50,000 downloads from that country in a single day, according to data shared by Calle and reported by Bitcoin Magazine. Similar spikes occurred during blackouts in other regions. In January 2026, Iranian users turned to Bitchat and a localized fork during internet restrictions, as covered in Bitcoin Magazine.
These earlier cases established a pattern: when conventional mobile networks or social platforms become unreliable or restricted, tools that operate independently of those networks see rapid adoption.
The India Events
In May 2026, India’s National Eligibility Entrance Test (NEET-UG) for medical school admissions was canceled after evidence of a significant leak of the test’s questions. The controversy, involving millions of candidates, undermined the fairness of the exam and was linked to student suicides, contributing to the growth of a youth-led satirical movement known as the Cockroach Janta Party (CJP). Protests centered on demands for accountability from Education Minister Dharmendra Pradhan and broader reforms to the examination system.
By mid-July, demonstrators had gathered at Jantar Mantar in New Delhi and attempted marches toward Parliament. Reports indicated blackouts on mobile data or internet access in areas around the protests. On 24 July 2026, the Indian Cybercrime Coordination Centre (I4C), issued a notice directing GitHub to restrict access to three Bitchat repositories within three hours. The notice cited the application’s ability to function during network restrictions and internet shutdowns, arguing that this architecture could impede lawful interception and attribution.
On 24 July, Dorsey posted the notice on X with the statement: “the government of India does not like technologies like bitchat and wants it taken down.” Market data from Sensor Tower, according to TechCrunch, reported across multiple outlets, showed that India accounted for approximately 85 percent of the app’s global downloads between 17 and 23 July, with more than 91,000 downloads in India over five days and daily active users exceeding 330,000 at the peak.
The GitHub repositories remained accessible in the immediate aftermath, despite the takedown attempt by the Indian government. Developers and users circulated mirrors, including on decentralized platforms such as Radicle. The application itself continued to function on devices that already had it installed, and the offline file-sharing feature reduced reliance on app stores or GitHub for further distribution. Pradhan resigned on 25 July.
Historical Context
The use of messaging tools during protests is not new, nor is Dorsey’s role in support of technologies useful during tense democratic protests. During the Arab Spring, platforms such as Twitter and Facebook were widely credited with helping coordinate demonstrations and amplify information, leading some observers to describe the events as “Twitter revolutions” or “Facebook revolutions.” Those centralized services, however, remained dependent on internet access and corporate intermediaries that could be pressured or blocked and in some cases were.
A closer technological predecessor appeared in 2014 during Hong Kong’s Umbrella Movement. Protesters downloaded FireChat, a mesh-networking application that allowed devices to communicate directly over Bluetooth or Wi-Fi without internet. The app saw hundreds of thousands of downloads and millions of chat sessions in a short period as mobile networks became congested or as users prepared for possible disruptions.
Bitchat continues this line of development, though more closely integrated with Bitcoin-associated technologies. It combines mesh networking with an open protocol (Nostr), stronger cryptographic defaults, and fully open-source code. The response to the Indian GitHub notice, which saw rapid mirroring and peer-to-peer distribution of the application itself, illustrates a further step: the tool is no longer dependent on a single company or platform for its survival; once it has been distributed, it self-replicates.
Cypherpunk Principles in Practice
In 1993, Eric Hughes published A Cypherpunk’s Manifesto. It opens with the statement: “Privacy is necessary for an open society in the electronic age.” The manifesto argues that individuals cannot rely on governments or corporations to protect privacy and that the practical response is to write and deploy code that makes surveillance and control more difficult.
Bitchat is an application of that approach to communication. It does not require user information to function; identities are purely based on cryptography. Users do not need to trust a central operator. It continues to function when conventional infrastructure is restricted. When an intermediary such as GitHub is asked to remove the source code, the popularity and the offline distribution methods of the project limited the effectiveness of the request.
This does not make the technology inherently aligned with any particular political outcome, but this is now the third time it goes viral in the context of democratic demonstrations as a solution to government-driven internet censorship. From FireChat in Hong Kong to Bitchat in Nepal, Iran, and now India, the same underlying demand appears: communication that does not disappear when the network does. Bitchat servers that demand by giving people tools to communicate and coordinate without centralized infrastructure.
I scanned the Bitcoin blockchain for images; what I found will shock you. Much has been said online about the arbitrary data and content that can be found on the Bitcoin blockchain. Not only has this possibility spawned a niche art scene, but it has also led to a movement against ‘non-monetary transactions’ on the Bitcoin network. Were you to hear from one of its proponents or detractors, you’d figure the blockchain is basically a wall filled with graffiti.
Well, I decided to put the question to the test: are there actually images on the blockchain? And what does this actually mean for Bitcoiners simply trying to run their own full node and maximize their financial sovereignty?
My methodology was simple: I was to buy a fresh hard drive to store the blockchain on, and then I was going to run classic image recovery software over the data, something used to rescue images from broken hard drives, something designed to find raw image data.
I chose PhotoRec to do the image recovery work, an open source image recovery program that’s been around for over 20 years. The software is designed to find image files in raw data. This can be used to recover images and other file formats from hard drives that have failed or been corrupted. It is actually often used to recover lost wallet.dat files from the early days of Bitcoin wallets, before the proliferation of the seed word format.
Syncing The Full Bitcoin Node
For storage of the full Bitcoin blockchain, I decided to buy a 4-terabyte disk drive for a couple hundred dollars. I then installed the latest version of Bitcoin Core on it and started to sync the chain. The process, which involves downloading and verifying the accounting integrity of all transactions in Bitcoin history, took about 72 hours or three days, automated and running in the background by the Bitcoin Core software.
I did this with an otherwise powerful gaming machine; the main bottleneck in terms of time was the disk drive, which is slow to read and write data as needed when syncing Bitcoin’s blockchain. The slow part of the process involves the unspent transaction output set, or UTXO. When a user syncs the blockchain, every unspent transaction value (output) or positive balance is organized into the UTXO set, and as those values are spent, they are removed from the set, while the new address to which those satoshi were sent is added.
On the disk drive, this UTXO indexing process could have taken three weeks according to some estimates, so to speed it up, my clanker (AI agent) suggested we index the data in RAM instead, then move the data back to the 4-terabyte disk drive. While the whole process took three days, running in the background, an SSD could have done the whole job in about a day. SSD drives are much faster than disk drives; they are more modern, but they are also easily four times the price, or more.
Once the blockchain was fully downloaded and validated, we moved the UTXO index from RAM back to the disk and booted the Bitcoin software; the chain was fully synced and the wallet ready to go. Now it was time for the next step: recovering the images stored on the blockchain.
Image Recovery on the Blockchain with PhotoRec
With the full Bitcoin blockchain on my disk drive, I turned off Bitcoin Core and asked my clanker (Cursor AI agent) to run PhotoRec 7.2 on the drive. The default PhotoRec process looks for jpg, png, gif, tif, bmp, ico, psd, and raw formats. The process ran for over 11 hours on the blockchain data and ultimately found … (drum roll) … nothing.
Over a terabyte of blockchain data and half a day of scanning and no images turned up. The PhotoRec wiki page gives a simple example of how the software works: “PhotoRec identifies a JPEG file when a block begins with: 0xff, 0xd8, 0xff, 0xe0, 0xff, 0xd8, 0xff, 0xe1, or 0xff, 0xd8, 0xff, 0xfe.” In other words, the program looks at the data on the disk for bytes that signal that there’s an image file.
The program is capable of false positives; it saved 8 ICOs and 4 identical PNG files that don’t show any images when opened, as seen in the picture below. So, effectively no meaningful images of any kind were found.
Where Did the Jpegs Go? XOR Magic Tricks
How is this possible? For years, crypto people have been talking about NFTs and how to engrave image data on the Bitcoin blockchain. Millions of dollars have moved in this niche, and a whole culture war is being fought on the matter as we speak. Can there really be no images on the chain?
Turns out the risks involved with arbitrary data have been discussed and planned for in Bitcoin Core development circles for a long time, as early as 2011. XOR, a simple data obfuscation technique, is used to scramble all the blockchain data while it is at rest on a hard drive.
You might have heard that the fundamental language of computers is made up of 0’s and 1’s. Well, in a nutshell, XOR compares two digits or bits and returns 1 if the bits are different or 0 if the bits are the same. In the case of Bitcoin, XOR compares every bit of the blockchain data to a random key generated during initial install, resulting in data at rest that other programs can find no meaning in. However, when the Bitcoin software runs, it has the key to unscramble that data and use it at will. XOR is also very fast, so it does not meaningfully impact performance. Here’s an example of the Bitcoin genesis block before and after an XOR.
XOR is currently applied to both the blockchain data and the UTXO set. XOR was initially discussed in 2014 when anti-virus software started getting tripped up by blockchain data it interpreted as virus code. The anti-virus software would then quarantine a block, corrupting the blockchain data and crashing Bitcoin, making sync impossible. By the end of 2015, XOR had been implemented on the UTXO set data at rest and in 2024 it was implemented on all blockchain data at rest.
Incidentally, the XOR process means that no arbitrary data can be identified or extracted from the blockchain without intentionally bypassing the XOR, a process that is not necessary for monetary use of Bitcoin. Since the Bitcoin Core software keeps a simple database of the location of each scrambled block, it can get its data, unscramble it and use it in a targeted manner easily.
Syncing Bitcoin in an unscrambled way is a custom process that can take as much time as syncing from scratch, since it basically has to re-write the full terabyte of data in a new order, and there’s not much point in that for someone that just wants the normal privacy and security benefits of running a Bitcoin node. So when it comes to the vast majority of copies of the Bitcoin blockchain data, resting on the computers of normal Bitcoiners throughout the world, there’s effectively no arbitrary data or images that can be identified. Shocking, I know. Feel free to run the PhotoRec test yourself on your own node!
Login
