Hi all,

I posted an initial draft for a quantum-resistant address format yesterday. After feedback and closer review, I've made several corrections to the specification. The updated draft is at:

https://github.com/Zaenus/btc-safe/blob/main/docs/bip/0001-pq-address-format.md

Key changes:

1. **Witness version 0x03, not 0x02.** Version 0x02 (bc1z...) is allocated to BIP-360 (P2MR). This proposal uses witness version 0x03, as discussed in the April Delving Bitcoin thread on ML-DSA-65 address formats.

2. **HRP is "bc", not "bc1z".** Witness version 0x03 encodes as the character "r" in bech32m, so addresses start with `bc1r...`. The encoding is bech32m (BIP-350), matching Taproot.

3. **Sighash is BIP-143.** Signatures use the same digest as SegWit v0 transactions, adapted for witness version 3, defaulting to SIGHASH_ALL.

4. **Aggregation is a mock prototype.** The signature aggregation module in the repo uses a deterministic hash construction, not a real zk-SNARK circuit. Compression numbers (~192-byte proofs) are illustrative only. A real circuit (Circom/Noir/SP1) with trusted setup is required before any on-chain use.

5. **Test suite updated.** All 43 tests pass with the corrected `bc1r` format.

The reference implementation (Python, ML-DSA-65 via pqcrypto, off-chain only) is at https://github.com/Zaenus/btc-safe.

I'd appreciate review of the corrected draft, particularly on:
- Whether witness v3 is the right choice given BIP-360's allocation of v2
- Whether BIP-143 sighash is appropriate for witness v3 programs
- Whether the community wants to pursue a PQ address BIP at all, given BIP-361's migration framework

Best regards,
Hans
https://github.com/Zaenus
Em quinta-feira, 12 de novembro de 2026 às 14:27:23 UTC-3, Hans Stringuer escreveu:
Dear Bitcoin Development Community,

I'm sharing a draft BIP for a quantum-resistant address format for Bitcoin, developed as part of the safe-btc project (https://github.com/Zaenus/btc-safe).

## Summary

This BIP proposes a new `bc1z` address format using ML-DSA-65 (FIPS 204) post-quantum signatures. The format commits to a SHA-256 hash of the ML-DSA public key, revealing the full public key only at spend time in the witness — similar to how P2WPKH works today.

## Motivation

Bitcoin's ECDSA and Schnorr signatures are vulnerable to Shor's algorithm on a cryptographically relevant quantum computer (CRQC). Once a public key appears on-chain, a quantum attacker can derive the private key and spend the funds. Approximately 6.9 million BTC (~$586B) sits in addresses with exposed public keys.

## Design Highlights

- **Address format:** `bc1z<witness version 0x02><32-byte SHA-256 commitment>`
- **Spend witness:** `<ML-DSA signature (3,309 bytes)> <ML-DSA public key (1,952 bytes)>`
- **Soft fork compatible:** Old nodes see `bc1z` outputs as anyone-can-spend (witness version > 1)
- **Off-chain reference implementation available:** Python library with key generation, signing, verification, migration helper, and quantum canary monitor
- **Signature aggregation prototype:** SNARK-wrapped ML-DSA signatures compress ~33KB of individual signatures to ~2KB for 10 signatures

## Repository

https://github.com/Zaenus/btc-safe

The full BIP draft is in `docs/bip/0001-pq-address-format.md`.

## Request for Comments

I'm looking for feedback on:

1. Address format design (HRP `bc1z`, witness version 0x02, 32-byte commitment)
2. ML-DSA-65 parameter choice (security vs. signature size trade-off)
3. Soft fork deployment considerations
4. Migration path for existing UTXOs
5. Whether the community sees value in pursuing this before a CRQC exists

This is an early draft intended to start discussion. I'm happy to revise based on community feedback.

Best regards,
Hans
https://github.com/Zaenus

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9a435a81-4146-4e9f-b7da-3858fb3ef4f7n%40googlegroups.com.