Quantum-Safe Addresses

The Hash160 Trick

One of the most common misconceptions about post-quantum Bitcoin addresses is that they must be enormous — after all, if the public key is 1,312 bytes, wouldn’t the address be correspondingly large? The answer is no, thanks to a design decision Satoshi made in 2009.

Bitcoin addresses are not public keys. They are hashes of public keys. The standard construction applies two hash functions in sequence: RIPEMD160(SHA256(public_key)), producing a 20-byte key ID. This 20-byte hash is then encoded with a prefix byte and a checksum to create the address you see in wallets.

The same construction works on a Dilithium key. Take the 1,312-byte public key, apply SHA256, then RIPEMD160, and you get a 20-byte key ID — exactly the size of a Bitcoin ECDSA key ID. BTQ’s original Dilithium address format did precisely this, and testnet still carries outputs of that shape.³

That format is now historical. Dilithium was consolidated into P2MR(Pay-to-Merkle-Root, witness version 2), where the output commits not to a 20-byte hash of one public key but to a 32-byte Merkle root of a script tree — which is what lets a single address stand for a single-key check, a multisig policy, or a threshold accumulator.³ So Hash160 is the right mental model for ECDSA addresses and for the deprecated Dilithium Base58 form; it is not how a Dilithium address you generate today is built. The P2MR section covers the current construction.

What survives the change is the property that matters: an address is a commitment, not a key. Whether it commits to a 20-byte key ID or a 32-byte Merkle root, the Dilithium public key itself never appears on-chain until you spend. Twelve bytes of difference does not change the economics — both are trivially small next to the 1,312-byte key they stand in for.

The commitment also carries a security benefit: it provides pre-image resistance. A quantum computer running Grover’s algorithm gets only a quadratic speedup against hash functions — roughly halving the effective bits, which leaves both constructions computationally infeasible to invert. As long as the full public key stays unrevealed, a quantum attacker has nothing to run Shor’s algorithm against.

Dual Address Prefixes

A quantum-resistant chain that supports both ECDSA and Dilithium must distinguish between the two address types. Sending funds to the wrong address type could result in lost coins if the recipient’s wallet doesn’t support the corresponding signature scheme.

The BTQ implementation uses distinct prefixes for each key type across all address formats:

The distinction still serves as a visual safety check, but it is carried by the witness version character rather than by a separate prefix. On testnet an ECDSA SegWit v0 address reads tbtq1q... and a Dilithium P2MR address reads tbtq1z... — same human-readable prefix, and the character after the “1” separator tells you which scheme will authorize the spend. Wallet software should key off the witness version, not the prefix string.

The legacy Base58 Dilithium format remains decodable so history and block explorers still render it, and it stays a valid payment destination on testnet only while P2MR-only enforcement is unscheduled there. It is deprecated: new wallets and mining payouts should use getnewdilithiumaddress, which returns a P2MR address.

Bech32m Encoding

Modern Bitcoin addresses use Bech32 or Bech32m encoding (BIP-173, BIP-350), which provides error detection, is case-insensitive, and avoids visually ambiguous characters. Bech32m (the improved variant) is used for SegWit version 1+ outputs, including Taproot and P2MR.¹

A Bech32m address has three parts: a human-readable prefix (HRP), a separator (“1”), and a data section including a version byte and the witness program. For ECDSA SegWit v0 addresses, the witness program is a 20-byte Hash160 of the public key. For P2MR addresses — the only bech32m form Dilithium uses — the witness program is the 32-byte Merkle root of the script tree.

The error detection properties of Bech32m are especially important for Dilithium addresses because the consequences of sending to a wrong address are the same as in Bitcoin — the funds are permanently lost. The encoding guarantees detection of up to 4 character errors and provides a high probability of detecting random errors beyond that.

Why Address Reuse Gets Worse

Address reuse has always been discouraged in Bitcoin for privacy reasons. In a quantum world, the reasons become existential.

When you spend from a Bitcoin address, your full public key appears in the transaction input. If you receive more funds to the same address afterward, those funds are now sitting behind an exposed public key. A classical attacker cannot exploit this (reversing ECDSA from the public key is infeasible classically). A quantum attacker can.

With Dilithium, the same dynamic applies: the public key (1,312 bytes) appears in the witness when you spend. If you reuse the address and receive more funds, those funds are protected only by the Hash160 — which remains quantum-safe — but the full Dilithium public key is now in the blockchain history. A future quantum computer capable of breaking Dilithium (if MLWE turns out to be weaker than believed) would have the key available to attack.

The recommendation is the same for both ECDSA and Dilithium, but with higher stakes: use a fresh address for every receive. This keeps the public key hidden behind its Hash160 until you spend, maximizing the number of cryptographic barriers an attacker must overcome.

P2MR: The Quantum-Safe Address

Pay-to-Merkle-Root (P2MR) addresses, as proposed in BIP-360, use SegWit version 2 — qbtc1z... on mainnet, tbtq1z... on testnet. Unlike P2PKH or P2WPKH (which store a hash of the public key) or P2TR (which stores the tweaked public key directly), P2MR stores only the 32-byte Merkle root of the script tree.²

No public key of any kind appears on-chain until the output is spent. Even then, only the specific script branch used in the spend is revealed — other branches remain hidden, preserving privacy about alternative spending conditions (just as in Taproot’s script path).

For quantum resistance, P2MR provides the strongest possible guarantee: the Dilithium public key is hidden until spend time, and the Dilithium signature scheme itself is believed secure against quantum adversaries. There is no key-path bypass, no exposed public key to attack preemptively, and the on-chain footprint (32-byte Merkle root) is identical to a Taproot output — no storage penalty for the additional security.

References

1. Bitcoin Improvement Proposals. BIP-173: Base32 address format (Bech32) and BIP-350: Bech32m format for v1+ witness addresses. bip-0173, bip-0350.
2. Beast. BIP-360: Pay-to-Merkle-Root (P2MR), originally drafted as P2QRH. bip360.org
3. Chambers, O. & Chambers, B. A Field Guide to BTQ Transaction Types, BTQ Core, 28 July 2026 (network v0.4.2-testnet). Documents P2MR as the single home for Dilithium, the retirement of the Dilithium witness-v0 format, and legacy Dilithium Base58 as historical, each with a confirmed testnet transaction on the public explorer.