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 for Dilithium keys. Take the 1,312-byte Dilithium public key, apply SHA256, then apply RIPEMD160, and you get a 20-byte key ID — exactly the same size as a Bitcoin ECDSA key ID. The full public key never appears on-chain until the moment you spend from the address. Until then, only the 20-byte hash is stored in the UTXO set.

This has a critical security benefit: the hash provides pre-image resistance. Even a quantum computer running Grover’s algorithm gets only a quadratic speedup against hash functions — reducing RIPEMD160’s security from 160 bits to approximately 80 bits, which is still computationally infeasible. As long as you never reveal the full public key (by spending from the address), a quantum attacker cannot apply Shor’s algorithm because they don’t have the elliptic curve point to work with.

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 distinguishes the two across all address formats as follows:

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.