From: Hans Stringuer <hans.stringuer@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65
Date: Thu, 12 Nov 2026 09:25:20 -0800 (PST) [thread overview]
Message-ID: <9463348c-b2ec-4c6f-b9ec-2e9e2fc7d105n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2465 bytes --]
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/9463348c-b2ec-4c6f-b9ec-2e9e2fc7d105n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2875 bytes --]
reply other threads:[~2026-11-12 17:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9463348c-b2ec-4c6f-b9ec-2e9e2fc7d105n@googlegroups.com \
--to=hans.stringuer@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox