Bitcoin Development Mailinglist
 help / color / mirror / Atom feed
* [bitcoindev] A slight change proposed on Committing to quantum resistance: a slow defence for Bitcoin against a fast quantum computing attack
@ 2026-04-06 20:30 PYM
  2026-04-11 17:09 ` [bitcoindev] " Daniel Buchner
  0 siblings, 1 reply; 2+ messages in thread
From: PYM @ 2026-04-06 20:30 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2011 bytes --]

Hello, here's a small idea to combine merkel tree with timestamped message 
signature to bind p2pkh adress to quantum resistant scheme so user do not 
need to rush to move bitcoin before qday, in a space efficient form.

- *Universal P2PKH freeze* — At a defined block height, all P2PKH outputs 
become unspendable via classical ECDSA. 
- *Pre-freeze claim* — Before the freeze, owners sign a claim containing 
their Bitcoin address and a new post-quantum public key of their choice. 
The claim is ECDSA-signed, proving classical ownership while quantum 
computers don't yet exist. 
- *Merkle-batched publication* — Claims are batched into Merkle trees. Only 
the 32-byte root goes on-chain via OP_RETURN. One transaction covers large 
amount of claims. 
- *Post-freeze spending* — To spend a frozen output, provide: the original 
claim, a Merkle inclusion proof linking it to a pre-freeze root, and a 
signature from the post-quantum key committed in the claim.  
- *No claim, no spend* — Any P2PKH output with no registered claim before 
the freeze height is permanently frozen until a future recovery mechanism 
is defined by the community.
I do not have enough knowledge to find the ideal scheme or implementation 
that fulfill those requirements sadly. 

1 - Stewart I, Ilie D, Zamyatin A, Werner S, Torshizi MF, Knottenbelt WJ. 
Committing to quantum resistance: a slow defence for Bitcoin against a fast 
quantum computing attack. R Soc Open Sci. 2018 Jun 20;5(6):180410. doi: 
10.1098/rsos.180410. PMID: 30110420; PMCID: PMC6030263.
https://pmc.ncbi.nlm.nih.gov/articles/PMC6030263/

-- 
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/4303fca1-81a8-4655-ac53-33f566daebc2n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2762 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [bitcoindev] Re: A slight change proposed on Committing to quantum resistance: a slow defence for Bitcoin against a fast quantum computing attack
  2026-04-06 20:30 [bitcoindev] A slight change proposed on Committing to quantum resistance: a slow defence for Bitcoin against a fast quantum computing attack PYM
@ 2026-04-11 17:09 ` Daniel Buchner
  0 siblings, 0 replies; 2+ messages in thread
From: Daniel Buchner @ 2026-04-11 17:09 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2552 bytes --]

This is basically the same concept as this proposal that describes a 
mechanism to do so (which I started a thread about 
yesterday): https://github.com/csuwildcat/pqc-precommitment-migration. Only 
difference is that you'd just activate the precommitted PQC key/validation 
pathways instead of having to explicitly freeze ECC (though I suppose you 
could do both).

On Monday, April 6, 2026 at 3:32:30 PM UTC-5 PYM wrote:

> Hello, here's a small idea to combine merkel tree with timestamped message 
> signature to bind p2pkh adress to quantum resistant scheme so user do not 
> need to rush to move bitcoin before qday, in a space efficient form.
>
>
>    - *Universal P2PKH freeze* — At a defined block height, all P2PKH 
>    outputs become unspendable via classical ECDSA. 
>    - *Pre-freeze claim* — Before the freeze, owners sign a claim 
>    containing their Bitcoin address and a new post-quantum public key of their 
>    choice. The claim is ECDSA-signed, proving classical ownership while 
>    quantum computers don't yet exist. 
>    - *Merkle-batched publication* — Claims are batched into Merkle trees. 
>    Only the 32-byte root goes on-chain via OP_RETURN. One transaction covers 
>    large amount of claims. 
>    - *Post-freeze spending* — To spend a frozen output, provide: the 
>    original claim, a Merkle inclusion proof linking it to a pre-freeze root, 
>    and a signature from the post-quantum key committed in the claim.  
>    - *No claim, no spend* — Any P2PKH output with no registered claim 
>    before the freeze height is permanently frozen until a future recovery 
>    mechanism is defined by the community.
>
>
> I do not have enough knowledge to find the ideal scheme or implementation 
> that fulfill those requirements sadly. 
>
> 1 - Stewart I, Ilie D, Zamyatin A, Werner S, Torshizi MF, Knottenbelt WJ. 
> Committing to quantum resistance: a slow defence for Bitcoin against a fast 
> quantum computing attack. R Soc Open Sci. 2018 Jun 20;5(6):180410. doi: 
> 10.1098/rsos.180410. PMID: 30110420; PMCID: PMC6030263.
> https://pmc.ncbi.nlm.nih.gov/articles/PMC6030263/

-- 
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/adeaa540-eaf0-4a1c-ad67-57ae50a58671n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3678 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-04-11 17:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-04-06 20:30 [bitcoindev] A slight change proposed on Committing to quantum resistance: a slow defence for Bitcoin against a fast quantum computing attack PYM
2026-04-11 17:09 ` [bitcoindev] " Daniel Buchner

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