* [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65
@ 2026-11-12 17:25 Hans Stringuer
2026-11-13 12:18 ` [bitcoindev] " Hans Stringuer
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Hans Stringuer @ 2026-11-12 17:25 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* [bitcoindev] Re: BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65
2026-11-12 17:25 [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65 Hans Stringuer
@ 2026-11-13 12:18 ` Hans Stringuer
2026-11-13 15:49 ` [bitcoindev] " Zeeshan Ali Khan
2026-11-13 20:16 ` Murch
2 siblings, 0 replies; 6+ messages in thread
From: Hans Stringuer @ 2026-11-13 12:18 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 4402 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 5757 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65
2026-11-12 17:25 [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65 Hans Stringuer
2026-11-13 12:18 ` [bitcoindev] " Hans Stringuer
@ 2026-11-13 15:49 ` Zeeshan Ali Khan
2026-11-13 17:25 ` Hans Stringuer
2026-11-13 20:16 ` Murch
2 siblings, 1 reply; 6+ messages in thread
From: Zeeshan Ali Khan @ 2026-11-13 15:49 UTC (permalink / raw)
To: Hans Stringuer; +Cc: Bitcoin Development Mailing List
Hi Hans,
> 5. Whether the community sees value in pursuing this before a CRQC exists
I can't speak for others but I think this is definitely useful
**before** a CRQC exists. It'd be too late for the 6.9 million BTC you
mentioned when there is CRQC. :)
> revealing the full public key only at spend time in the witness — similar to how P2WPKH works today.
I think it'd be useful to highlight that unlike a P2WPKH address, the
address remains quantum-resistant even after its public key and
signatures are revealed.
--
Regards,
Zeeshan Ali Khan
--
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/CAAa3hFN%2Bz1KGRkU_8JLmQ_1cXMZEYHO-0370Q_REv_MB2ci9Og%40mail.gmail.com.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65
2026-11-13 15:49 ` [bitcoindev] " Zeeshan Ali Khan
@ 2026-11-13 17:25 ` Hans Stringuer
0 siblings, 0 replies; 6+ messages in thread
From: Hans Stringuer @ 2026-11-13 17:25 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6326 bytes --]
Hi Zeeshan, all,
Thank you, both points are right, and they are now part of a substantially
revised draft (v0.2):
https://github.com/Zaenus/btc-safe/blob/main/docs/bip/0001-pq-address-format.md
> I think this is definitely useful **before** a CRQC exists.
Agreed. The Motivation section now spells out why waiting fails. Soft
forks take years from proposal to activation, and migration is limited
by block space: a 1-in/1-out move from P2WPKH to the new output type is
486 WU, so every 10 million UTXOs needs roughly 1,200 completely full
blocks. A safe destination has to exist well before the threat does.
> I think it'd be useful to highlight that unlike a P2WPKH address, the
> address remains quantum-resistant even after its public key and
> signatures are revealed.
Yes. My comparison with P2WPKH undersold the design. The hash commitment
only keeps outputs small (34 bytes instead of ~1,955); it is not what
provides security. Unlike P2WPKH, the output stays safe while a spend
waits in the mempool, after it has been spent, and under address reuse
(still bad for privacy, of course). The draft now says this explicitly.
Corrections to my original post
-------------------------------
Several things in my first message were wrong, and I want to correct them
on the list:
1. Witness version 2 / bc1z: version 2 is used by BIP-360 (P2MR). The
proposal now uses witness version 3, so addresses start with bc1r
(tb1r on testnet).
2. "Similar to how P2WPKH works": misleading, see above.
3. "~6.9 million BTC (~$586B)": I replaced this with the figure cited in
BIP-361 (more than 34% of all bitcoin had an exposed public key as of
March 2026) and dropped the dollar value.
4. The signature aggregation claim ("~33KB to ~2KB for 10 signatures")
is withdrawn. The prototype was a mock that could be forged, and the
approach was unsound anyway: pairing-based SNARKs such as Groth16 are
themselves broken by a CRQC, and consensus cannot depend on a trusted
setup. Aggregation is now out of scope; a short research note
explains what a sound approach would need.
5. The reference implementation produced bech32 rather than bech32m
checksums for the new witness version, so BIP-350 wallets would have
rejected its addresses. That is fixed and tested against the BIP-350
vectors. It also generated mainnet addresses by default; it now
defaults to testnet, since these outputs are anyone-can-spend until a
soft fork activates.
What changed in the design
--------------------------
key_blob = key_type || pubkey (0x01 = ML-DSA-65)
commitment = TaggedHash("PQKeyCommit", key_blob)
scriptPubKey = OP_3 <32-byte commitment>
witness = <signature[||hash_type]> <key_blob> [annex]
sighash = TaggedHash("PQSighash", 0x00 || SigMsg(hash_type, 0))
verify = ML-DSA.Verify(pk, sighash, sig, ctx="bitcoin:pq:tx")
- Key type byte: the key blob is always the last witness element, and
undefined key types succeed (like OP_SUCCESS). ML-DSA-44, SLH-DSA,
FN-DSA or a hybrid type can then be added by later soft forks without
spending another witness version.
- The signature message is BIP-341's SigMsg, unchanged, under a new tag.
It commits to all input amounts and scriptPubKeys, which BIP-143 does
not.
- FIPS 204 context strings separate transaction signatures from
off-chain message signatures.
- The draft now has full spending rules, relay policy, size figures, and
a rationale section comparing this with P2MR (BIP-360), hybrid keys,
ML-DSA-44, SLH-DSA and FN-DSA.
- Test vectors (docs/bip/0001-test-vectors.json) cover keys and
derivation, all seven hash types, and 32 valid and invalid spends. The
signatures come from an independent ML-DSA implementation, and the
sighash code also passes the official BIP-341 vectors.
Size: an ML-DSA-65 input is 5,433 WU (~1,358 vB), about 736 per block. A
1-in/2-out transaction is about 1,455 vB.
Status of my original questions
-------------------------------
1. Address format: revised as above (witness v3, bech32m, tagged-hash
commitment with a key type byte).
2. ML-DSA-65 vs. smaller parameters: still open, and I would value
opinions. ML-DSA-44 inputs are 28% smaller (3,904 WU); ML-DSA-65
gives more margin against future lattice cryptanalysis. Should a
hybrid secp256k1 + ML-DSA key type also exist from day one?
3. Deployment: no activation mechanism proposed yet. Bitcoin Core
benchmarks of ML-DSA-65 verification come first.
4. Migration: the reference tools classify addresses by exposure
(Taproot and spent-from addresses count as exposed) and derive
recoverable destinations from a BIP-39 seed. BIP-361 covers the
policy side.
5. Before a CRQC: yes, per Zeeshan's reply and the reasoning above.
Detailed technical discussion is also happening on Delving Bitcoin:
https://delvingbitcoin.org/t/bip-draft-witness-version-3-ml-dsa-65-post-quantum-key-path-spending/
Full list of changes:
https://github.com/Zaenus/btc-safe/blob/main/CHANGELOG.md
Thanks again for the review.
Best regards,
Hans
https://github.com/Zaenus
Em sexta-feira, 13 de novembro de 2026 às 13:28:40 UTC-3, Zeeshan Ali Khan
escreveu:
> Hi Hans,
>
> > 5. Whether the community sees value in pursuing this before a CRQC exists
>
> I can't speak for others but I think this is definitely useful
> **before** a CRQC exists. It'd be too late for the 6.9 million BTC you
> mentioned when there is CRQC. :)
>
> > revealing the full public key only at spend time in the witness —
> similar to how P2WPKH works today.
>
> I think it'd be useful to highlight that unlike a P2WPKH address, the
> address remains quantum-resistant even after its public key and
> signatures are revealed.
>
> --
> Regards,
>
> Zeeshan Ali Khan
>
--
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/23d3f227-fb57-4ad3-8dab-438d2bd6e651n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7442 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65
2026-11-12 17:25 [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65 Hans Stringuer
2026-11-13 12:18 ` [bitcoindev] " Hans Stringuer
2026-11-13 15:49 ` [bitcoindev] " Zeeshan Ali Khan
@ 2026-11-13 20:16 ` Murch
2026-11-13 20:29 ` Hans Stringuer
2 siblings, 1 reply; 6+ messages in thread
From: Murch @ 2026-11-13 20:16 UTC (permalink / raw)
To: bitcoindev
Hello Hans,
thank you for chiming in. Please note that discussion, research, and
development of PQC solutions for Bitcoin has been on-going for several
years. Please kindly catch yourself up on the status quo per the last
couple years of mailing list, Delving Bitcoin, in-person events, BIP
discussions, etc.
On 2026-11-12 09:25, Hans Stringuer wrote:
> 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).
I’m afraid that yet another LLM-generated PQ proposal that you started
less than 48h ago is unlikely to be the breakthrough we have been
waiting for.
Please thank Claude for its hard work.
Cheers,
Murch
--
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/370af76f-6bcf-435d-bf88-fd4170d18537%40murch.one.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65
2026-11-13 20:16 ` Murch
@ 2026-11-13 20:29 ` Hans Stringuer
0 siblings, 0 replies; 6+ messages in thread
From: Hans Stringuer @ 2026-11-13 20:29 UTC (permalink / raw)
To: Murch; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]
Hey Much,
Thanks for the feedback. I see now that I need to do more research,
especially on the ongoing discussions. There are too many points I should
understand better and thanks for pointing them out, I will put more work
there before releasing anything.
I already thanked Claude, he helped me a lot. Just for the record I do
not believe that I will contribute with any breakthrough.
Cheers,
Hans
Em sex., 13 de nov. de 2026 às 17:19, Murch <murch@murch.one> escreveu:
> Hello Hans,
>
> thank you for chiming in. Please note that discussion, research, and
> development of PQC solutions for Bitcoin has been on-going for several
> years. Please kindly catch yourself up on the status quo per the last
> couple years of mailing list, Delving Bitcoin, in-person events, BIP
> discussions, etc.
>
> On 2026-11-12 09:25, Hans Stringuer wrote:
> > 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).
>
> I’m afraid that yet another LLM-generated PQ proposal that you started
> less than 48h ago is unlikely to be the breakthrough we have been
> waiting for.
>
> Please thank Claude for its hard work.
>
> Cheers,
> Murch
>
> --
> 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/370af76f-6bcf-435d-bf88-fd4170d18537%40murch.one
> .
>
--
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/CADrHc-2AuauYHrrgS6aXmcmJWPcE1pegDHV9HdOoQac9%2BGCn%2Bw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3059 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-11-13 20:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-12 17:25 [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65 Hans Stringuer
2026-11-13 12:18 ` [bitcoindev] " Hans Stringuer
2026-11-13 15:49 ` [bitcoindev] " Zeeshan Ali Khan
2026-11-13 17:25 ` Hans Stringuer
2026-11-13 20:16 ` Murch
2026-11-13 20:29 ` Hans Stringuer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox