Post-Quantum Bitcoin in 32 Bytes

Bitcoin's Quantum Timeline

Every Bitcoin UTXO is protected by secp256k1 ECDSA or Schnorr. Both are broken by Shor's algorithm. The timeline for practical quantum computers capable of running Shor's at the scale needed is uncertain, but every major standards body agrees it's close enough to start migrating now.

Bitcoin is not migrating now. The governance process for changing consensus rules on Bitcoin is measured in years. A soft fork to add a post-quantum signature opcode requires a BIP proposal, extensive review, reference implementation, testnet deployment, community consensus, and 95% miner signaling. The fastest this has ever happened is about two years (SegWit). The slowest is ongoing (some proposals from 2015 are still being debated).

In the meantime, every Bitcoin transaction is signed with a signature scheme that has a known mathematical vulnerability. There is currently no way for a Bitcoin user to attach a post-quantum proof to their transaction without changing the consensus rules.

Except OP_RETURN.

OP_RETURN: The 80-Byte Window

Bitcoin allows a special transaction output type called OP_RETURN. It creates a provably unspendable output that carries arbitrary data. Standard relay policy limits the data to 80 bytes. Every full node stores OP_RETURN data as part of the blockchain.

OP_RETURN is used today for timestamping services (OpenTimestamps), colored coins, commitment schemes, and data anchoring. No consensus change is needed to use it. No soft fork. No BIP. Any wallet can create an OP_RETURN output right now.

The constraint is size. 80 bytes is not much. A single Dilithium signature is 3,309 bytes. FALCON is 657. SPHINCS+ is 17,088. None of them fit. Even STARK-compressed proofs of these signatures come in at 440+ bytes. Nothing from the post-quantum world fits in 80 bytes.

Unless you don't put the signature in the OP_RETURN.

32 Bytes On-Chain

Our approach puts a 32-byte SHA3-256 hash in the OP_RETURN. That's all. 32 bytes of data in a 34-byte script (OP_RETURN OP_PUSHBYTES_32 <32 bytes>), inside a 43-byte transaction output (8-byte value + 1-byte script length + 34-byte script).

Those 32 bytes are the SHA3-256 digest of a canonical commitment payload that binds to:

• The specific computation or transaction being attested
• The type of attestation (payment, identity, document signing, etc.)
• The exact millisecond the attestation was created
• A unique random nonce preventing replay

The three post-quantum signatures—Dilithium, FALCON, and SPHINCS+—all sign this same 32-byte hash. The signatures are verified, compressed into a 42-byte verification receipt, and the raw signature data is securely erased. The 42-byte receipt lives off-chain and serves lookups in under a microsecond.

Total persistent footprint: 32 bytes on-chain + 42 bytes off-chain = 74 bytes.

The Weight Math

Bitcoin uses a weight system for transactions. Non-witness data costs 4 weight units per byte. Our OP_RETURN output is 43 bytes of non-witness data:

Component	Bytes	Weight Units
Output value (0 sats)	8	32
Script length	1	4
OP_RETURN opcode	1	4
OP_PUSHBYTES_32	1	4
32-byte hash	32	128
Total output	43	172 WU

172 weight units = 43 vbytes. A standard P2WPKH transaction (1 input, 2 outputs) is about 141 vbytes. Adding our OP_RETURN makes it about 184 vbytes. That's a 30% increase—the same order of magnitude as a transaction that already has a small OP_RETURN from an existing service.

At 10 sat/vB (a normal fee environment), the cost of the PQ attestation is 430 sats. At current Bitcoin prices, that's well under a dollar.

Now compare what it would cost to put the raw signatures on-chain:

Approach	On-chain bytes	Weight Units	Fee @ 10 sat/vB
Our 32-byte hash	43	172	430 sats
Dilithium only	3,318	13,272	33,180 sats
Dilithium + FALCON	3,975	15,900	39,750 sats
All 3 families (raw)	21,063	84,252	210,630 sats
All 3 (Taproot witness)	21,063	21,063	52,660 sats

Our approach is 490x less expensive than putting all three signature families on-chain. It's 77x less expensive than Dilithium alone. And it provides the same cryptographic binding—if the on-chain hash doesn't match the off-chain verification receipt, the attestation is invalid.

Chain Growth at Scale

Bitcoin adds roughly 600,000 transactions per day. If every transaction carried a PQ attestation:

Approach	Daily chain growth	Annual chain growth
32-byte hash	25.8 MB	9.4 GB
Dilithium only	1.99 GB	727 GB
All 3 families	12.6 GB	4.6 TB

Bitcoin's current chain grows by about 150-200 MB per day. Adding 25.8 MB (our approach) is a 15% increase. Adding 12.6 GB (raw three-family signatures) is a 6,300% increase. One of these is viable. The other is not a serious proposal.

The Verification Receipt

The off-chain component is a 42-byte verification receipt. It's produced by signing the 32-byte message with all three PQ algorithm families, verifying each signature, computing a SHA3-256 hash that binds to the exact public keys and exact signatures that were verified, and then securely erasing the raw signatures from memory.

The receipt contains a verification hash (32 bytes), a timestamp (8 bytes), a version byte, and an algorithm flags byte recording which families verified. That's it. 42 bytes that prove three independent mathematical families attested to a specific Bitcoin transaction at a specific time.

The raw signatures—all 21,054 bytes of Dilithium + FALCON + SPHINCS+ output—existed in memory for approximately 15 milliseconds during the attestation process. They were verified, compressed into the receipt, and zeroed. They never touched disk. They never went on-chain. They never existed in persistent storage at any point.

The 42-byte receipt lives off-chain and serves lookups in under a microsecond. It's keyed by the same 32-byte hash that sits in the OP_RETURN. Query the receipt by the on-chain hash, get 42 bytes back, and you know whether Dilithium, FALCON, and SPHINCS+ all signed off on this transaction.

At 600,000 Bitcoin transactions per day, the off-chain receipts accumulate at 25.2 MB per day—9.2 GB per year. A decade of every Bitcoin transaction PQ-attested fits in 92 GB. One machine. The storage cost is functionally zero.

What the Verifier Sees

A wallet, exchange, or block explorer that wants to verify a PQ attestation does the following:

1. Read the 32-byte hash from the OP_RETURN output of the transaction.
2. Query the off-chain verification layer with that 32-byte hash as the key.
3. Receive a 42-byte verification receipt.
4. Confirm the receipt is internally consistent and matches the on-chain hash.
5. Read the algorithm flags in the receipt to see which PQ families verified (Dilithium, FALCON, SPHINCS+, or any combination).

The lookup takes under a microsecond. The verifier never touches the raw 21KB of signatures. Those were verified once and destroyed. The receipt is the persistent proof.

The Honest Limitations

This approach has real limitations and we should be direct about them.

This is not consensus-enforced

Bitcoin Script does not check our 32-byte hash. A quantum attacker who breaks secp256k1 can still spend a UTXO. The OP_RETURN attestation doesn't prevent the spend. It provides evidence that the legitimate owner had PQ-attested the UTXO, which enables PQ-aware infrastructure (wallets, exchanges, monitoring services) to flag unauthorized transfers.

Think of it as a security camera, not a lock. It doesn't stop the break-in, but it provides immediate, cryptographically verifiable evidence that one occurred.

Off-chain availability matters

The 42-byte receipt lives off-chain. If the off-chain layer is unavailable, the attestation can't be verified in real time. However:

• The receipt is only 42 bytes. It can be mirrored trivially—IPFS, multiple providers, the verifier's own cache.
• The on-chain hash is permanent. As long as the receipt is recoverable from any mirror, the attestation is verifiable.
• The receipt is deterministic. Given the same inputs (public keys + signatures + message), anyone can regenerate it.

This complements a soft fork, not replaces it

The right long-term answer for Bitcoin is a consensus-level PQ signature scheme. That change is worth pursuing. Our 32-byte approach is what works today while the governance process runs its course—and what continues to work afterward, because 32 bytes of on-chain data is less than any PQ signature will ever be.

Three Families, Not One

Most PQ Bitcoin proposals pick one algorithm. Dilithium is the usual choice because it's the NIST primary recommendation. But single-algorithm PQ is a single point of failure.

Dilithium's security rests on the hardness of the Module Learning With Errors problem. If a mathematical breakthrough weakens MLWE, every Dilithium signature ever produced is at risk. This is not hypothetical concern—it's the exact scenario that happened with RSA (which was considered unbreakable until Shor's algorithm was discovered) and that could happen with any specific hardness assumption.

Our attestation covers three families from three independent mathematical foundations. MLWE lattices (Dilithium), NTRU lattices (FALCON), and hash functions (SPHINCS+). Breaking the attestation requires breaking all three simultaneously. The probability space is vastly different from breaking one.

And the cost of covering three families instead of one? Zero additional on-chain bytes. The 32-byte hash is the same whether it binds to one signature or three. The off-chain receipt is 42 bytes regardless. The weight is identical. You get three families of protection for the same on-chain cost as one.

The Fee Market Impact

One concern with any proposal that adds data to Bitcoin transactions is the impact on the fee market. More bytes per transaction means more competition for block space, which means higher fees for everyone.

At 43 bytes per OP_RETURN output, the impact is minimal. In a 4 MB weight limit block, our attestation outputs would consume about 0.001% of block capacity per attested transaction. Even if 100% of transactions carried attestations, the block capacity reduction would be about 2-3%—well within the normal variance of block sizes.

Compare this to inscription-based approaches that embed large data payloads in witness space. A single Ordinal inscription can consume kilobytes to megabytes of block space. Our 43-byte output is four orders of magnitude smaller than a typical inscription.

Existing Infrastructure Compatibility

Because the PQ attestation is a standard OP_RETURN output, it works with every existing piece of Bitcoin infrastructure:

• Wallets: Any wallet that can create OP_RETURN outputs can attach PQ attestations. No wallet upgrade required for basic functionality.
• Block explorers: OP_RETURN data is already displayed. Parsing the 32-byte hash requires minimal additional logic.
• Node software: Bitcoin Core already relays and stores OP_RETURN outputs. No patches needed.
• Mining: OP_RETURN outputs are standard transactions. No special mempool handling.
• Lightning: The OP_RETURN attestation applies to the on-chain funding and closing transactions. Lightning channel operations are already secured by the channel's cryptographic state.

This is the advantage of working within existing protocol boundaries rather than proposing new ones. Everything works today, with the software that's already deployed.

For Bitcoin Developers

If you're building a wallet, exchange, or custody solution and you want to add PQ attestation to your transactions:

1. Compute the 32-byte PQ attestation hash for your transaction.
2. Add an OP_RETURN output to your transaction: 6a20 + 32 bytes.
3. Broadcast the transaction normally.
4. The 42-byte verification receipt is available via API for any verifier.

Your transaction is now PQ-attested with three independent mathematical families at a cost of 43 vbytes and under a dollar in fees. Your users' UTXOs now carry a cryptographic record proving PQ authorization that will be verifiable for as long as the blockchain exists.

This is the bridge. The soft fork is the destination. You don't have to wait for the destination to start the journey.