pull down to refresh

Hmm. This is cool.... let me check if I understand it correctly. Also, this might help others understand in more laymens terms (if I got it right)

The Problem

You have coins sitting in a quantum-vulnerable address , and you failed to move into a quantum-secure address before Q-day

The Solution

A soft fork that still allows people to spend from quantum-vulnerable addresses, but only with additional proof of ownership. The protocol relies on the existence of "knowledge asymmetries"... information that is hard for a quantum attacker to crack, but the true owner of the coins would have. We'll assume that such a knowledge asymmetry exists, and we'll call that secret , which proves that you own .

How it works

  1. First, you create a new post-quantum keypair, . ( is the public key, is the private key).
  2. You use and to broadcast a "timestamp" transaction on block . The purpose of this transaction is to prove that you knew at time . and can't be reversed from the transaction data.
  3. After a delay of blocks, you publish a "rescue" transaction to move the funds from vulnerable address to post-quantum address . The "rescue transaction" reveals , thus proving that you control , and it also contains proof that you published the previous timestamp transaction.

Reason for the timestamp and the delay

  1. Once you send your rescue transaction to the mempool, is revealed. Without the timestamp/delay scheme, anyone can take that information and race you to moving the funds from . However, because the protocol requires the proof of timestamp, the attacker would first have to create their own timestamp. But since you didn't reveal it until time , they'd have to wait until at least to steal your funds, because they'd first have to create a timestamp at time (when they see ), then wait another blocks.

Advantages of the approach

Allows people who failed to migrate to post-quantum addresses a chance to recover their funds, while at the same time not letting vulnerable coins become exposed to a quantum free-for-all.


Does that about catch it?

I think your article has a lot more details about miner incentives and other implementation details, but I just tried to capture the high level gist of the idea.

Thanks. Yes, that's mostly correct. A few minor notes:

  • You don't necessarily need to use the same PQ key $Q$ for publishing the "timestamp" (commitment) transaction.
  • You (the wallet user) don't need to publish the commitment transaction - you can delegate that to an untrusted 3rd party: an "aggregator", who publishes a merkle tree that merges many users' commitments together, a la opentimestamps.

hehe sorry, the miner incentives game-theory appendix at the end was rather long-winded, but necessary if i wanted to argue security. Otherwise one could claim the scheme is broken by just saying "Miners will collude"

reply