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
  0 siblings, 0 replies; only message 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] only message in thread

only message in thread, other threads:[~2026-11-12 17:27 UTC | newest]

Thread overview: (only message) (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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox