Anyone arriving from the main piece already knows what this is about: a machine that does not yet exist, but that on the day it existed would be able to derive the private key from a public key. From that day, every coin whose public key is already visible on the ledger becomes a target. The natural question is: how many are there, today? Public estimates on this exist and are often quoted; even so, the data was worked out here as well, which produced both confirmations and a few interesting leads, presented below.
This piece was also taken on as an exercise, to show that with relatively few resources (access to a node, the support of an LLM, and the ability to run a program of a few hundred lines) anyone can reach the public data of the time chain and carry out their own study and thinking: it can be a way to confirm what one has already read, or to test and validate one's own hypotheses.
In particular, the effort went into gathering and processing the information with the precautions needed for the aggregations and the counts to be easily re-runnable: every figure has its fingerprint and its replication contract. What this text presents is the numbers and a short description of the method used. The specific tools, ready to be reused, are public: github.com/amenano/nodsig.
All the numbers that follow hold at the declared snapshot: block 957,301, early July 2026.
The locks, in brief
Before the numbers, the compass. Every coin on the ledger sits behind a «lock», the script that says under what conditions it can be spent; the locks come in a few types, and the type decides when the key shows itself. This table is for consulting, not for studying: coming back to it while reading the figures is the intended use.
| lock | addresses | protocol | protection | vulnerable to quantum computing… |
|---|---|---|---|---|
| P2PK (pay to public key) | — (outputs of the origins) | the origins (2009) | none: the key is in the clear | always, by construction |
| P2PKH (pay to public key hash) | 1… |
legacy (2009) | hash160 of the key | on reuse: the first spend shows the key |
| P2SH (pay to script hash) | 3… |
legacy (2012, BIP 16) | hash160 of the script | on script reuse: spending shows the script and its keys |
| P2WPKH (pay to witness public key hash) | bc1q… |
SegWit v0 (2017) | hash160 of the key | on reuse: like P2PKH |
| P2WSH (pay to witness script hash) | bc1q… (longer) |
SegWit v0 (2017) | sha256 of the script | on script reuse: like P2SH |
| P2TR (pay to taproot) | bc1p… |
Taproot / SegWit v1 (2021) | none: the key (tweaked) is in view | always, by construction |
Outside the table there remains a dust of old bare multisig outputs, exposed by construction as well: a few BTC, counted in the floor of the main piece.
The last column divides the ledger into two families, and the two families come back in every figure of this piece: the locks exposed by construction, which show the key from the first day, and those protected by a hash, which show it only when reuse makes them show it.
And since the question «so what should I do about it?» is a legitimate one, the short answer sits here, before the numbers; the main piece argues it at length.
| lock | conduct for the greatest protection available |
|---|---|
| P2PK | the lock exposes the key by construction: the only protection is to migrate the coins to a hash-protected format, which whoever still holds the keys can do today |
| P2PKH / P2WPKH | never reuse an address: a new one for every receipt (modern wallets do this by themselves), and never receive on an address that has already spent |
| P2SH / P2WSH | as above, for the script: every spend shows the script and the cosigners' keys → a new script for every receipt, periodic rotation for large deposits |
| P2TR | the key is in view by construction: avoiding reuse is not enough, here address hygiene buys nothing. In a quantum computing light, large and still values are better off on a hash-protected format (bc1q… never reused) |
| all | the precaution buys time, not exemption: the real protection will be migration to post-quantum signatures, and it will have to be done anyway |
The three numbers
The census comes down to three numbers. 5.08 million BTC have their key already shown through reuse: this is the new measurement of this piece, counted and not estimated, across 8.78 million locks. 1.93 million BTC are exposed by construction: this is the certain floor, which anyone can reproduce with a single command. The sum is 7.02 million BTC: about 35 per cent of all coins in existence have their key in view. Anyone who knows the public estimates will recognise the landscape: the text of BIP-361 counts more than 34 per cent, Glassnode's analysis of May 2026 puts the floor at 1.92 million against our 1.93, Coinbase's advisory council speaks of about 7 million. Different routes, same place. With one caveat worth giving at once, because it applies to every comparison in this piece: when the perimeters do not coincide, the totals do not coincide, and that is not a disagreement. Glassnode, for example, stops at 6.04 million on the total, 30.2 per cent: it counts a different date from ours and a different perimeter for reuse, where we also count scripts and cosigners. The numbers resemble each other where they measure the same thing (the floor, precisely, where the convergence reaches the decimal) and part company where the definition changes. On these totals our contribution is not a discovery but a confirmation: the public estimates already landed in the right place, and here it can be checked directly instead of taken on trust. Where the census adds something of its own is further on, on concentration per lock and on pace.
The map of the ledger
The map above puts the whole ledger on a single scale: one bar per lock type, the filled part being the value with its key in view. How to read it: the first thing that stands out is an apparent paradox, the old formats seeming better off than the new ones, with the filled bar of «modern» P2WPKH the longest of all. But in proportion the types resemble each other: P2PKH has 26 per cent of its own value in view, P2WPKH 24, P2SH 33. What changes is where the value lives: the P2WPKH type is the largest on the ledger, with 8.16 million BTC, and at an equal exposed percentage it produces far more BTC in view. There are two real exceptions: P2WSH, a small type with almost half its value in view (its character will become clear shortly), and the two hatched bars, P2PK and Taproot, exposed one hundred per cent by construction: there no precaution helps, only migration.
From here on the piece looks at the four hash-protected types, and asks their locks three questions: how much, since when, at what pace.
The character of the types
From here on, tables and figures look at the four hash-protected types exposed by reuse alone: P2PK and Taproot, exposed by construction, stay outside. The reference total is no longer 7.02 million BTC but 5.08.
| lock | BTC exposed (≥) | median/lock | mean | Gini |
|---|---|---|---|---|
P2WPKH bc1q… |
1.92 M | 0.00014 | 0.53 | 0.996 |
P2SH 3… |
1.28 M | 0.00014 | 1.11 | 0.998 |
P2PKH 1… |
1.19 M | 0.00012 | 0.30 | 0.996 |
P2WSH bc1q… (script) |
0.69 M | 0.00036 | 7.60 | 0.999 |
| all | 5.08 M | 0.00013 | 0.58 | 0.997 |
The first thing the table says, and that no average alone would say, is that exposure is extremely concentrated: the typical exposed lock, the median, holds a handful of dollars (a little over ten thousand satoshis), in every type. The mean is far higher only because it is pulled up by a very few enormous locks; the Gini of almost 1 measures this without mincing words: the index is 0 when value is shared out in equal parts and tends to 1 when it is almost all in very few hands. Every type, in other words, is a long tail of dust plus a handful of giants.
Inside this common shape, the types differ in where the giants sit. P2WSH is the vault: few locks, but the highest mean on the ledger (7.6 BTC), the profile of multisig deposits, strongboxes rather than wallets. P2PKH is the historical long tail, the lowest mean, the reuse of all time. The mean should be read this way, «how big is the whale weighing on this type», not «how much does the ordinary address hold»: that, in every type, is dust.
Here the note of caution is needed in full: this data makes no attributions. It does not say who reuses, it names nobody, and it could not: it measures a concentration, not an identity. It does say one precise thing: the exposed value is not scattered across a crowd, it clusters on very few very large addresses, a profile that is not that of personal wallets. And here there is a convergence worth noting: those who have proprietary data and do make the attributions arrive at the same profile by routes entirely their own. Glassnode's analysis assigns 1.66 million of the reuse-exposed BTC to exchanges alone, four in ten; Coinbase's advisory council describes the roughly 5 million from reuse as belonging to «active users, including large cold wallets of known exchanges»; the Chaincode Labs study points to exchanges and institutional wallets among the most exposed precisely because of reuse. Three independent analyses, with different methods and different data, draw the same profile. The difference in role should be stated clearly. Those analyses have proprietary data and get to the names, but they are not reproducible from outside. Our count takes the opposite path: it does not reach the names, but the concentration that makes them suspected is measured on an ordinary node and re-runnable down to the fingerprint. We show the signal in a verifiable way; the names, for those who want them, are supplied by those who sell them.
The locks, band by band
The distribution in full: every exposed lock placed in its value band, by count and by BTC.
| band (BTC) | locks | BTC exposed | % of value |
|---|---|---|---|
| 0 – 0.001 | 6,300,308 | 941 | 0.0% |
| 0.001 – 0.01 | 1,318,119 | 4,668 | 0.1% |
| 0.01 – 0.1 | 718,614 | 24,873 | 0.5% |
| 0.1 – 1 | 342,278 | 106,460 | 2.1% |
| 1 – 10 | 87,920 | 232,838 | 4.6% |
| 10 – 100 | 13,072 | 357,429 | 7.0% |
| 100 – 1000 | 3,439 | 1,058,748 | 20.8% |
| ≥ 1000 | 614 | 3,298,768 | 64.9% |
How to read it: the first three bands, over eight million locks (almost all of the exposed ones), are together worth 0.6 per cent of the value; the 4,053 locks above one hundred BTC are worth 85.7 per cent. It is the same shape seen type by type, now across the whole ledger: an endless tail of dust and a handful of giants.
Statistics like these are not a verdict, they are tools. They serve to give substance to a hypothesis, to strengthen it or to refute it with numbers instead of impressions. And here is the point that counts more than any single figure: computing them requires no private archive and no permission, an ordinary node and a program of a few hundred lines are enough, with the pipeline and the replication contract in the appendix. Already today the contract says exactly what has to come out, and if a number does not convince, if a hypothesis seems stretched, anyone will be able to redo the count and push it wherever they want. Everything written on the chain is public, and what is public is verifiable by anyone, not only by us. The limits remain the declared ones: what the chain does not show, the keys shared off chain, nobody can count, and this holds for us as much as for anyone else.
And it holds beyond today's case: this way of proceeding concerns not only the quantum computing threat we are dealing with, but any question about data or aspects of the protocol that are written in public. Where the information is exposed, the analysis can belong to everyone.
Since when: the curve by epoch of revelation
This curve answers the question «since when»: it takes the value exposed today and distributes it by the epoch in which the key showed itself. How to read it, in three steps. First: the recent slope. Almost half the value now in view, 48.1 per cent, revealed its key after the start of 2024, and 34 per cent after the start of 2025; the line dominating the climb is P2WPKH's. Exposure through reuse is not an inheritance from Bitcoin's naive past: it is recent, and for the heaviest part very recent indeed. Second: the steps. The curve does not rise smoothly, it rises in jumps, and the individual jumps are visible to the naked eye: in November 2018 the P2SH line rises by 444,504 BTC within an interval of ten thousand blocks, with barely 12,867 locks involved: thirty-four and a half BTC per lock, the signature of a few large players, not of a crowd. The five steepest intervals, on their own, are worth a third of all the exposed value; the first twenty, three quarters. Third: what this curve does not say. It is today's exposure distributed by epoch: coins revealed in the past and then spent are no longer there. It is not the history of behaviour; it is the inventory of the warehouse, with the year labelled on every shelf. The history of behaviour is in the figure that follows.
And the freshness is not uniform across the types: of the exposed P2WPKH value, eighty per cent revealed itself after the start of 2024; of P2WSH almost half; of P2SH a third; of P2PKH a sixth. The gradient follows the age of the formats, and it is another way of saying that reuse is not a fossil, it is a practice still often in use.
| lock | BTC exposed (≥) | locks | share of the type's value | of which after start of 2024 |
|---|---|---|---|---|
| P2WPKH | 1,924,332 | 3,612,318 | 23.6% | 79.7% |
| P2SH | 1,283,224 | 1,155,896 | 32.6% | 32.8% |
| P2PKH | 1,185,752 | 3,925,128 | 25.8% | 15.3% |
| P2WSH | 691,417 | 91,022 | 48.7% | 44.7% |
| total | 5,084,725 | 8,784,364 | 28.1% | 48.1% |
At what pace: behaviour, year by year
This figure changes the question: not «how much is exposed today», but «how much reveals itself, year by year»: the habit, not the inventory. The series counts the new fingerprints the chain sees for the first time, each in the year of its first appearance, averaged per block. How to read it: the pace rises for over a decade, peaks in 2021 at almost eight thousand new fingerprints per block, and falls every year since: in the first half of 2026 we are a little above four thousand six hundred, more than forty per cent less. Inside the fall there is a migration legible from the colours: P2SH scripts collapse (from the twenty-six hundred of the 2020 peak to fewer than three hundred per block: the network is moving out of them), P2WSH peaks in 2024 and comes down, keys fall more slowly, from almost three thousand five hundred to around two thousand. The habit, in other words, is improving.
Series of this family already exist, and it is right to say so: BitMEX Research published in 2022 the share of outputs that reuse addresses; an academic paper from 2026 (Stütz et al.) counts, by quarter and up to March 2025, the events of first key reuse. Ours is not the first series of the kind and does not claim to be. What it adds, concretely:
- it counts scripts too, not only keys. Alongside P2PKH/P2WPKH keys it places the P2SH/P2WSH scripts revealed when spent: without them the migration away from P2SH, the sharpest fact in this figure, would remain invisible.
- it reaches mid-2026, a year beyond the most recent academic series, and shows that the decline continues.
- it can be redone: the appendix at the end contains the commands to rebuild the same series, fingerprints included. It is not a figure to be taken on trust.
In short: not a new fact about whether reuse is declining, but the same question measured across more locks, over a longer span, and in a way that lets anyone redo the count.
What remains: the age of the exposure
The figure that follows is the sister of the pace one, and the two look at the same phenomenon from two sides that are easy to confuse. The behaviour one counts events: how many new fingerprints the chain saw for the first time, year by year, and every revelation weighs one: a lock emptied the next day counts as much as one holding thousands of BTC. This one weighs the state instead: it takes the value that sits behind keys in view today and dates it to the year in which the lock first revealed itself. That is why they can diverge, and the divergence is what makes them interesting together: a year thick with revelations may leave almost nothing in today's exposure, if those coins have since moved; an unremarkable year may dominate it, if the value stayed put. One tells a habit; the other, what the habit has left on the table.
How to read it: the exposure is young. A little over a third of the value exposed today, 34.3 per cent, revealed itself in 2025-26: 1.74 million BTC, of which 1.23 in 2025 alone; from 2023 onwards the share passes half, 55.4 per cent. Only 6.2 per cent has been in view for more than ten years. The isolated 2018 peak, 11.3 per cent, is the P2SH event already noted under the epoch curve. The comparison with the sister is immediate, same axis: 2018 appears in both; 2025, a year of decline in the pace series, here alone is worth almost a quarter of the total, because recently revealed value is still almost all in place. And the perimeter is the same, the weighing is not: the pace figure counts locks that are empty today as well, this one only what holds value today.
The double reading
The last two figures seem to contradict each other, and it is worth saying so openly: the pace series improves from 2021 onwards, less reuse every year; the age of the exposure, just seen, is instead dominated by value revealed recently, and the epoch curve says the same. How can «reuse is falling» and «exposure is recent» hold together? Reconciling them is, in our view, the most instructive reading of the whole census: the series cited measure the flow, whereas here the flow is read together with the exposed stock and with concentration per lock, and it is this crossing that dissolves the contradiction.
The difference is between two quantities:
- a flow — how many revelation events happen each year (the pace series): it is slowing;
- a stock — how much revealed value is still spendable today (the curve by epoch): it is not falling, because it records only what has been spent in the meantime.
The key is the survival of outputs. The value revealed in distant years has largely been spent already and, in leaving the ledger, has left the count; recent value is still sitting there. So improving behaviour does not empty the exposed stock: it makes it grow more slowly and, as the first table says, with ever richer locks, fewer events but more value per event. For the quantum computing threat what counts is the stock, not the pace; and the stock is growing.
What the numbers allow us to say about the threat
The concentration seen above allows a step that estimates alone do not, and it is worth taking with caution, because it is a hypothesis, not a measurement. The shape of the exposure is sharp: a few hundred giant addresses hold most of the value in view. The hundred largest exposed locks are worth 47 per cent of the 5.08 million exposed by reuse; the first thousand, 70 per cent; 614 locks, those above one thousand BTC, are enough for almost two thirds of the total. The rest is a tail of millions of locks that, added together, weigh almost nothing.
Value that concentrated does not have the profile of small savers: it looks like a few large entities (exchanges, custodians, treasuries), the same profile the analyses cited arrive at, with data we do not have. And actors of that size have a property the distracted individual does not: they are informed, or they can be. If the threat went from remote to concrete, they would be among the first to know, and there is a concrete fact: moving a few hundred addresses would cover a large part of the value at risk; the defence, for the heaviest part, is within reach of a few.
This cuts in two directions, and it is the reason data is an antidote to slogans. On one side it tempers the alarm: the bulk of the exposure is not dust scattered among millions of unaware people, it is concentrated where whoever can move is able to move fast. On the other it does not license minimising: the same concentration makes the loot attractive (a few broken locks would be worth a great deal), nothing guarantees the reaction arrives in time, and, a warning not to be left unsaid, not all those giants are watched over: a huge address with its key in view may be a forgotten treasure, coins lost for years that nobody will ever migrate. Concentration of addresses is not concentration of vigilant custodians.
It is a small example of something more general. The public ledger, which for an attacker is an advantage (the exposed keys are there to be read), is also a resource for those who want to understand: it makes the threat measurable instead of merely narratable. And here the method turned against its own temptations: the mean per lock suggested «large actors who reuse»; the distribution, actually looked at, says something more precise and less convenient: very few giants on an ocean of dust. The main piece separates the two fears and warns against the two symmetrical errors, alarm and the smile of dismissal; these numbers give that middle ground a footing of facts, not of adjectives.
The boundaries of these numbers
Every figure in this piece is a minimum, and the direction of the error is a single one: too low. The count sees only what the chain shows; public keys shared off chain, the xpubs handed to services, watch-only apps, custodians, leave no trace on the ledger and do not enter the count. The perimeter is declared: four hash-protected types, reuse of keys and of scripts, cosigners included; the exclusions (unconfirmed transactions, P2SH scripts never spent) are listed in the appendix. The dates in the figures come from block timestamps. And the behaviour series counts each fingerprint once, in the year of its first appearance: it measures how many locks reveal themselves, not how many times they are reused afterwards.
Appendix: redoing the calculations
The principle is the site's own: what is verifiable belongs to everyone. Here is where the count starts from, what route it takes, and which fingerprints whoever redoes it has to find.
It starts from a photograph: the snapshot of the set of unspent coins, taken at a declared height. From it the «locks» are distilled, that is the UTXOs of that moment with the type of each: they are the yardstick against which every key found will be measured. Then the chain is read again from the beginning, block by block, in search of the keys already revealed.
That reading we did twice, and the two readings are deliberately different, because they produce different things.
| pass 1 | pass 2 | |
|---|---|---|
| while it goes through the chain | compares every key with the locks and keeps the count | archives every revelation with its provenance |
| what it leaves behind | the numbers and the curve: a few megabytes | a queryable archive: tens of gigabytes |
| what it gives us here | how much is exposed, of what size, since when | how the pace of reuse changed over the years |
| and after that | it ends there | it answers questions not yet asked, too |
Provenance is where the key was seen: in the signature of whoever was spending, in the witness, or inside a revealed script, which is the case where the cosigners' keys appear as well. Recording it serves this purpose: the perimeter of the count (whether to include cosigners, which types to take in) is applied when reading, once the question arrives, without having to go through the chain again.
The first pass is the cheap way to reach those counts, and it ends there. The second, while it goes, counts nothing: it archives, and derives the numbers afterwards, by reading the archive back. It costs a great deal more, and in this piece it pays for itself with the pace series, which is read from the archive and not from the first pass. That the two routes must then arrive at the same number is a check that, once the two passes are done, costs nothing extra: since they do not share the aggregation, an error in one would not repeat identically in the other, and the cross-check requires that they coincide down to the fingerprint. It is the counter-proof, paid for once, of the trust in everything else.
Whoever redoes the calculations does not have to pay for it again: the documented route is the single pass (the scan that archives, the numbers derived by reading the archive), and the counter-proof remains available as a check.
An idea of the cost, so that «re-runnable» does not read as «free». The long step is reading the chain again, and it does not depend on the power of the computer: it depends on how fast the blocks arrive from the node. On a mid-range laptop, with the node reachable on the local network, the single pass takes a couple of machine-days, and can be interrupted: the scanner resumes from the last checkpoint. It cost us more, because we made two passes.
from the node ──► utxos.dat the photograph (dumptxoutset)
from the node ──► block_dates_<h>.csv block timestamps, for the
dates in the figures
utxos.dat ┬─► census ───────► census_<h>.csv
│ the floor: P2PK and Taproot
│
└─► reuse prepare ───────► locks_<h>/
the «locks»: the UTXOs unspent
at that height
│
┌─────────────────────┴─────────────────────┐
│ │
PASS 1 PASS 2
compares as it goes archives everything and
and archives nothing derives the numbers later
│ │
▼ ▼
reuse scan archive scan
blocks from the node blocks from the node
│ │
▼ ▼
checkpoint/ utxo_reveal/
├ curve.csv └ runs/… ──► merge
└ hits_<type>.bin │
│ │ ▼
│ └─► reuse stats manifest.json
│ └ reuse_stats_<h>.json (canonical fingerprint)
│ concentration, bands │
└──────────► crosscheck ◄──────────────────┘
PASS / FAIL
The node is needed at four moments only: the photograph of the set of coins, the block timestamps, and the two readings of the chain. Everything else (the census, the locks, the distribution, the merge, the cross-check) is computed on the artefacts already obtained, without going back to query it.
| The piece | What it is | What it is for |
|---|---|---|
UTXO snapshot (utxos.dat) |
the photograph of all coins unspent at that height, taken from the node with dumptxoutset |
it is the common starting point: whoever starts from the same photograph must arrive at the same numbers |
the timestamps (block_dates_…csv) |
the date of 96 heights, asked of the node with getblockheader and interpolated in between |
it is what puts the years under the two time figures |
the census (census_…csv) |
how many coins exist for each lock type, read from the snapshot alone, without a node | it gives the floor: what is exposed by construction, that is the original P2PK and Taproot |
the locks (locks_…) |
distilled from the snapshot: what is «closed», and by what type of lock | it is the yardstick: every key found on the chain is compared against these |
the curve (curve.csv) |
how much value turns out to be reused, block after block | it gives the history and not just the total: it is the figure of exposure by epoch |
the archive (utxo_reveal) |
the keys and scripts the chain has already revealed, with their provenance; the periodic merge (merge) fixes its canonical form |
it is the queryable archive: from here the numbers are derived without rescanning the chain |
the distribution (reuse_stats_…json) |
how the exposed value is spread across the locks: it is obtained from the locks and the hits of pass 1 (hits_…), without rereading the chain |
it is what holds up median, mean and Gini, the treemap bands and the shares of the largest |
the cross-check (crosscheck) |
reads the archive back against the locks and redoes the count by the other route | it is the proof: two independent routes must give the same number, down to the fingerprint |
And since the point of all this is that the counts can be redone, it is worth saying which number in this piece rests on which part of the chain.
| comes from | what it holds up in this piece |
|---|---|
| the census, from the snapshot alone | the floor of 1.93 million, that is P2PK and Taproot |
| pass 1 | the 5.08 million exposed by reuse, the filled bars of the map of the ledger, the curve by epoch |
pass 1, read back by stats |
the sizes per lock: median, mean, Gini, the treemap bands, the shares of the largest |
| pass 2 | the pace of reuse year by year |
| the block timestamps | the dates under the two time figures |
| pass 1 against pass 2 | the cross-check |
The replication contract has two levels, checked in different ways.
The first is the input, and anyone can verify it already today, with an ordinary node and without our code. What is needed is to start from our identical photograph of the chain:
- cut-off height 957,301: its block hash is obtained with
getblockhash 957301; - the same snapshot of the set of unspent coins:
txoutset_hash ec79aed99b8d22d7315c76488fe09975ef9258039ee5583c7e8c7b6dc8d4cc58. This hash Bitcoin Core computes by itself (gettxoutsetinfo, ordumptxoutset): whoever redoesgettxoutsetinfoat block 957,301 and finds the sametxoutset_hashhas our identical starting photograph, and nobody has to trust that we did not pick convenient data; - the same perimeter, declared in the scanner's flags: the four hash-protected types, reuse of keys and of scripts, cosigners included.
The second level is the result, and it is reproduced with the code, which
is public: github.com/amenano/nodsig. From
that input, the processing produces the two canonical fingerprints everything
read here rests on. Nothing in the recipe is ours: whoever redoes the build to
the same height, with the code of tag v1.0.0, has to land on the same
strings down to the last byte — same chain, same height, same fingerprint, on
any machine and whoever runs it. There is no room to adjust a result after the
fact: one different byte changes the whole string.
- fingerprint of the burnt locks:
5fd579dbc6190f5bf08e35947ab77a55e067aa366acd13bd49fa30d3ba9d0ee7 - canonical fingerprint of the revelations archive:
aacaf02dca2fc5ba8532e54fa75159041fc99051efa68eb63e59bc9537369ced
A third fingerprint, kept apart, and no figure in this piece depends on it.
The same scan can co-emit a transaction graph, switched off by default because
it costs hundreds of gigabytes; we did emit it. We publish its canonical
fingerprint
a014f787256e1831c90290e04c2adbcf1fe00cfc3f2d26bb668bff491aa54190
not because anything above rests on it, but because it is a commitment made
today on material that will serve later, when exposure can be re-derived epoch
by epoch. Whoever redoes the calculations of this piece has no need to
generate it.
In short: the input can be checked at once, with a node; the two fingerprints of the result are reproduced with the code.
References
- BIP-361, Post Quantum Migration and Legacy Signature Sunset, status Draft, February 2026 (the «more than 34%» figure as of 1 March 2026): github.com/bitcoin/bips/blob/master/bip-0361.mediawiki
- Deloitte, Quantum computers and the Bitcoin blockchain, analysis 2019-2020 (about 4 million vulnerable BTC, a quarter of the supply at the time): deloitte.com/nl/en/services/consulting-risk/perspectives/quantum-computers-and-the-bitcoin-blockchain.html
- Glassnode, Measuring Bitcoin's Quantum-Exposed Supply, 20 May 2026 (proprietary data: structural floor 1.92 million BTC, total 6.04 million with its own perimeter, attribution by exchange — 1.66 million traced to exchanges, four tenths of what is exposed through reuse): research.glassnode.com/measuring-bitcoins-quantum-exposed-supply
- Coinbase Quantum Advisory Council, position paper of 21 April 2026 with an update of June 2026 (about 7 million BTC: ~1.7 in P2PK, ~5 from reuse by active users, including cold wallets of known exchanges): coinbase.com/blog/coinbase-quantum-advisory-council-publishes-position-paper…
- A. Milton, C. Shikhelman (Chaincode Labs), Bitcoin and Quantum Computing: Current Status and Future Directions, May 2025 (4-10 million BTC, 20-50%; about 69% from reuse, with exchanges and institutional wallets among the most exposed): chaincode.com/bitcoin-post-quantum.pdf
- BitMEX Research, Bitcoin Address Re-use Statistics, February 2022 (the share of outputs reusing addresses, by count and not weighted by value): bitmex.com/blog/bitcoin-address-re-use-statistics
- R. Stütz, N. Stifter, M. Dragaschnig, B. Haslhofer, A. Judmayer, Reuse of Public Keys Across UTXO and Account-Based Cryptocurrencies, 2026 (quarterly series of first key reuse events, with code; data as of 31 March 2025): arxiv.org/abs/2601.19500
- The reasoning this piece carries the numbers for is in the main piece, «Bitcoin and quantum computing».
- Code and tools for this piece: a dedicated follow-up will come later.