Bitcoin Development Mailinglist
 help / color / mirror / Atom feed

* [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