pull down to refresh
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
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 A, 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 S, which proves that you own A.
How it works
Reason for the timestamp and the delay
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.