In the silence between the block hashes, there is a number that should never exist. It is not the hash of a transaction. It is not the hash of anything at all. It is the integer one, zero-padded into a thirty-two byte tombstone: 0x0000000000000000000000000000000000000000000000000000000000000001. And for the better part of a decade, under one specific, unglamorous, and entirely rational-looking set of conditions, a Bitcoin wallet could be coaxed into producing a cryptographically perfect signature over that nothing. A signature that verifies. A signature that costs real fees to broadcast. A signature that, on every technical level, is indistinguishable from authorization โ and yet authorizes nothing that the human behind the screen ever agreed to.
On September 25, a Bitcoin Core contributor merged a fix into the development trunk that quietly closes one of the last open windows onto this ghost. Bitcoin Optech flagged it on October 2. And as of October 4 โ the anchor for everything I am about to argue โ no release version carries it, and no backport has been confirmed. Which means the ghost is still standing in the doorway of every wallet that coordinates signatures the way the modern ecosystem actually does: through PSBTs.
This is not a crisis story. Bitcoin Core will not let your coins walk away because of this. But it is a story about the gap that the entire industry keeps pretending has been closed โ the gap between what a wallet shows you and what a key actually signs. I have spent the last nine years auditing that gap from the inside. It is wider than anyone wants to admit.
The Format That Broke the Assumption
Tracing the code back to its chaotic genesis means starting with BIP-174, the specification for Partially Signed Bitcoin Transactions. Before PSBT, a Bitcoin transaction was a private, monolithic act. One wallet held the keys, built the transaction, signed it, and broadcast it. The signing logic and the display logic lived inside the same process, sharing the same memory, and โ critically โ sharing the same assumptions about what the transaction contained.
PSBT dissolved that unity on purpose. It is a portable data format that lets a transaction be constructed in one place, signed in another, and finalized in a third. This is the architecture that made hardware wallets usable, that made multisignature custody practical, that made air-gapped cold storage a real security posture rather than a marketing flourish. The software wallet (Sparrow, Specter, or any of their descendants) builds the transaction. The hardware device (a Ledger, a Trezor, a Coldcard) holds the key and signs. A coordinator stitches the pieces together. Each party sees only a fragment of the whole, and the format is the contract between them.
That portability is also its attack surface. When signing logic is distributed across dozens of independent implementations, each with its own parser, its own display layer, and its own understanding of the specification, the specification stops being a guarantee and becomes a suggestion. BIP-174 knows this. It explicitly instructs signers to reject signature modes they find unacceptable, and where no alternative is specified, it recommends falling back to SIGHASH_ALL โ the mode in which a signature covers every input and every output, leaving no room for ambiguity.
The recommendation exists because the alternative, SIGHASH_SINGLE, is dangerous in exactly the way the current fix addresses. SIGHASH_SINGLE is a targeted authorization: it binds the Nth input to the Nth output, allowing a signer to approve one precise movement of value without endorsing the rest of the transaction. It is genuinely useful. It is also, by design, a mechanism that depends on there being an Nth output to bind to.
And when there isn't one โ when a transaction is constructed such that an input's index position has no corresponding output โ the protection does not gracefully degrade. It fails. How it fails depends entirely on what kind of bitcoin that input is spending, and that dependence is the root of everything that follows.
Where the Cryptography Stops Caring
Here is the mechanism, stripped of its politeness. When a transaction carries a legacy input (a pre-SegWit output) at an index where no output exists, the signature hash is not computed over a transaction that omits the output. It is computed over a constant. The signer, following its programming, signs the number one. The resulting signature is valid โ valid for that number, for that key โ and because the underlying message is a constant rather than a commitment to a specific set of outputs, that same signature can be replayed against other unspent outputs controlled by the same key. The authorization leaks sideways. The signer believes it approved one thing; the cryptography approved a category.
For SegWit v0 inputs, the failure is subtler and, in some ways, more insidious. The signature remains bound to the specific coin being spent and its amount โ so the replay-to-other-UTXOs problem largely evaporates. But the target output is still not bound. The signature commits to which coin is leaving, but not to where the value is going. The signer has cryptographically approved a debit with no cryptographic anchor on the credit.
This is not a new discovery. It is the SIGHASH_SINGLE bug, a fossil from the earliest era of the protocol, catalogued publicly as CVE-2020-14199, which cut through the hardware wallet ecosystem like a wire through a fuse โ Trezor, Ledger, Coldcard, all of them forced to reckon with the fact that their signing flow could be steered into producing signatures over a constant. That CVE was patched. The industry congratulated itself. And then, in the specific context of PSBT-based workflows, the same class of problem found a new doorway, because the check that Core had implemented in its raw transaction signing interface โ the path that already rejected this edge case โ was never wired into the shared signing logic that the PSBT path actually uses.
That is the whole story. Not a new bug. An old bug that never finished being fixed because it lived in two different code paths, and only one of them had the guard.
The new patch does the unglamorous, correct thing: it migrates the check out of the isolated interface and into the shared signing creation logic, so that every path โ raw, PSBT, whatever comes next โ inherits the same protection. And it does so with engineering restraint that deserves attention. Rather than rejecting an entire PSBT outright when it encounters an affected input, the fix blocks the signing of the specific legacy and SegWit v0 inputs that are affected while allowing the other valid inputs in the same transaction to proceed. That is a deliberate refusal to break legitimate multisignature workflows in the name of fixing a corner case. One poisoned input does not contaminate the whole batch.
The fix does not touch SegWit v1, meaning Taproot inputs are unaffected โ which is worth noting, because the migration to Taproot was partly sold on the promise of cleaner signature semantics, and here is the payoff, quietly delivered.
And it does not expose private keys. This matters for calibrating the severity. No key material is at risk. What is at risk is intent โ the correspondence between what a user authorized and what the mathematics recorded. That is a category of harm the industry has no good vocabulary for, which is precisely why it keeps underestimating it.
The Gap That No Patch Closes
Where logic meets the absurdity of market hype, this is the part nobody wants to fund. The genuinely interesting thing about this vulnerability is not that it existed. It is that it can be triggered through a wallet that shows the user something entirely reasonable. The display layer says: you are paying this address. The cryptography says: I have signed a commitment that does not name that address. The two statements are both true. They are also incompatible. And the human being staring at the confirmation screen has no mechanism โ none โ to detect the divergence.
I have audited governance proposals and economic assumptions for years, and the recurring failure mode is always the same: the surface looks coherent, so nobody interrogates the substrate. In 2020, when I was dissecting fifty-plus Uniswap and Aave proposals, I found the same pattern โ fifteen of them contained logical gaps that only revealed themselves when you stopped reading the summary and started reading the mechanism. The summary said one thing. The mechanism did another. Everyone voted on the summary.
This is that pattern, elevated to the level of cryptography. PSBT was engineered to coordinate signatures across devices that do not trust each other. Its entire reason for existing is to make cross-device trust verifiable. And yet the failure mode here is a trust gap that lives precisely in the seam PSBT was supposed to seal โ the seam between the device that displays and the device that signs.
Consider what the affected conditions actually are. An attacker needs: a transaction using SIGHASH_SINGLE; a missing output at the relevant index; other UTXOs controlled by the same key for the legacy replay scenario; and โ the hardest part โ the ability to induce a signer to sign a malicious PSBT. That last requirement is not trivial. It means compromising a coordinator, a software wallet, or the supply chain of the tooling that assembles the transaction before the hardware device ever sees it. The threshold is high. This is not a bug that empties wallets on its own.
But thresholds are not walls, and I have watched this industry repeatedly mistake difficulty for impossibility. In 2022, after FTX and Luna collapsed, I spent thirty livestreams arguing that the systemic risk was never in the code โ it was in the institutions wrapping the code. The same inversion applies here, in miniature. The vulnerability is not in the cryptography. The cryptography did exactly what it was told. The vulnerability is in the translation layer โ the software that takes a human intention and renders it into a signing request, and the software that takes a signing request and renders it back into a human-readable confirmation. Those two translations can disagree, and when they do, the human is not in the loop at all. The human only believes they are in the loop.
This is why the author's insistence โ that downstream wallets should not wait for a Core release before hardening themselves โ is the most important sentence in the entire disclosure. Bitcoin Core has done its job. It plugged its side. But Bitcoin Core is a reference implementation, not a police force. It cannot reach into Sparrow, into Specter, into the firmware of a Ledger or a Coldcard, and force them to adopt the fix. It can only publish, and hope the ecosystem reads.
And that hope is doing an enormous amount of load-bearing work.
An Evangelist Who Doubts His Own Gospel
Here is the contrarian turn, and I will steel-man the opposing view before I dismantle it, because the opposing view deserves that much.
The defense goes like this: Bitcoin's development culture is correct to be slow. The conservative release cadence โ merge to master, test, wait, release, backport โ is the single greatest reason Bitcoin has never suffered a catastrophic consensus failure. Every hour of delay is an hour of scrutiny. Every edge case that does not get rushed is an edge case that does not get mishandled. The window between merge and release is not a vulnerability. It is a feature. It is the immune system working.
I find this argument genuinely persuasive. I have defended Bitcoin's conservatism against doomsayers for years, most loudly during the 2022 collapse, when the contrast between the fragility of centralized entities and the resilience of the open protocol was the clearest it had ever been. Slow is not a bug in Bitcoin. Slow is the point.
But here is where the steel-man cracks. The slowness of Core's release is not the variable that determines the actual risk exposure. The variable is the downstream adoption curve โ and that curve is governed by an entirely different set of incentives. Core releases on a schedule measured in months and years. Wallet vendors release on a schedule measured in product cycles, marketing windows, and engineering bandwidth. Hardware manufacturers release on a schedule measured in firmware update fatigue โ the brutal reality that most users never update their device firmware at all, so any fix that depends on user action is a fix that reaches the technically engaged minority and nobody else.
So the window between merge and release is not where the risk lives. The risk lives in the window between release and universal downstream adoption โ and that window can be measured in years, not months, because it depends on a fragmented ecosystem of independent actors none of whom answer to Core, and most of whom answer to their own product roadmaps.
This is the structural critique, and it is the same critique I have leveled at every layer of this industry. The evangelists of decentralization love to point at the absence of a central authority as proof of resilience. But absence of authority is also absence of enforcement. There is no one to make the wallet vendors update. There is no one to make the hardware manufacturers ship the firmware. There is no one to make the multisig coordinators validate their PSBT parsers. The decentralization that protects Bitcoin from capture is the same decentralization that guarantees the last mile of every security fix will be walked unevenly, late, or not at all.
Logic fails, but the narrative persists โ and the narrative here is that Bitcoin Core fixed the bug, so the bug is fixed. That narrative is comfortable and false. The bug is fixed in one place. Everywhere else, it is exactly as alive as it was on September 24.
The deeper critique is about the standard itself. BIP-174 already told signers to reject unacceptable signature modes and to prefer SIGHASH_ALL when no alternative is specified. The standard anticipated this. The implementations did not fully comply. So we are left with the oldest problem in software: the specification is correct, the ecosystem is inconsistent, and the inconsistency is where the harm lives. A patch to one reference implementation cannot resolve an inconsistency that spans dozens of independent codebases. Only ecosystem-wide adoption can โ and ecosystem-wide adoption has no owner.
What the Last Mile Actually Costs
I want to be precise about who is exposed, because precision is the only honest form of urgency. The affected population is not "Bitcoin users." It is a technical subset: users whose workflows route through PSBT and involve legacy or SegWit v0 inputs. That is a real, identifiable, and non-trivial cohort โ it includes the sophisticated multisig holders, the enterprise custody arrangements, the air-gapped cold storage operators, the collaborative custody platforms where the transaction amounts are largest and the tooling is most complex. The people with the most to lose are disproportionately the people most likely to be using exactly the workflow that carries the exposure.
For the ordinary user with a single-key wallet on the latest firmware, the practical risk is close to negligible. I am not going to manufacture fear where the mathematics does not support it. But for the institutional custodian โ the family office, the fund, the treasury that moved into Bitcoin after the ETF approvals โ the calculus is different, because institutional custody lives and dies on verifiable authorization. A signature that does not bind the recipient is not a rounding error in that context. It is an existential audit failure waiting for a reason to happen.
This is where I part ways with the institutional convergence narrative I have been critiquing since 2024. The ETF era brought legitimacy, liquidity, and a wave of capital that Bitcoin genuinely needed. It did not bring security literacy. The reports I reviewed in 2024, the fifty institutional investment theses, overwhelmingly missed the decentralized value proposition โ but more damning, they missed the security model entirely. Institutions buy Bitcoin because the monetary policy is legible. They do not buy it because they understand PSBT signature semantics. And that gap โ between the legibility of the asset and the opacity of the tooling โ is precisely the gap this vulnerability exploits. The institutions are holding the most value with the least comprehension of the mechanism protecting it.
The mitigation, at the individual level, is unglamorous and specific: prefer wallets and hardware devices that have confirmed they reject missing-output SIGHASH_SINGLE requests; prefer SIGHASH_ALL workflows where the tooling allows it; treat any transaction that requires SIGHASH_SINGLE as one that deserves a second look, because the mode is rarely necessary and the edge cases are exactly where it fails. At the ecosystem level, the mitigation is a demand: ask your wallet vendor whether they have addressed this. Ask your hardware manufacturer. The question itself is the pressure. In an ecosystem with no central authority, consumer inquiry is the only enforcement mechanism that exists.
And watch for the real signal, not the noise. The signal is not the announcement that Core merged the fix. The signal is a hardware manufacturer's firmware changelog that mentions SIGHASH_SINGLE validation. The signal is a coordinator's release notes that mention PSBT hardening. The signal is a backport decision landing in a maintained release branch. Those are the events that move the needle from "fixed in theory" to "fixed in practice." Everything else is narrative.
The Ghost in the Doorway
The uncomfortable truth this episode keeps circling is that cryptography does not verify intention. It verifies bytes. Every layer of abstraction we build on top โ PSBT, hardware displays, address verification, the little green checkmark โ is a translation from human intent into machine commitment, and every translation is a place where meaning can drift. The industry has spent a decade hardening the cryptography and barely a year hardening the translations. That asymmetry is the real vulnerability. The SIGHASH_SINGLE missing-output bug is just the specific instance that happened to get a CVE number.
The fix is merged. The ghost is still in the doorway. And the only thing standing between a signed signature and an authorized one is a downstream ecosystem that no one commands โ a network of independent builders who will each decide, on their own schedule, whether the last mile is worth walking.
I believe in decentralization. I have organized meetups for it, written manifestos for it, defended it through two bear markets and a global fraud collapse. But I am an evangelist who doubts his own gospel โ and my doubt here is simple and sharp. If no one is responsible for the last mile, then the last mile does not get walked. It gets talked about, in changelogs that half the users never read and firmware that half the users never install.
So here is the question I am leaving open, the way I leave all the important ones open: if Bitcoin's greatest strength is that no one can force it to change, what happens when the change that matters most is the one that requires everyone to move? The protocol survives without consensus. The security does not. Somewhere between the merge and the release, between the release and the adoption, in the silence between the block hashes, the answer is still waiting to be signed โ and this time, by a key that actually binds what we mean.