So, if BIP360 gets the green light, can folks without seed phrase wallets still get their assets back after the cutoff?
I was checking out BIP360 and got a bit confused. There are these three key points:
In Phase C, it mentions recovering coins that weren't sent to quantum-resistant addresses by the deadline, which could take around 5 years. But it seems like only those with seed phrases can recover their funds after that deadline. What about those who only have a private key?
Only if it will be possible to include a general proof for any public key, not restricted to any particular seed. For example: if it would be possible to prove ownership of private key, equal to one, as an example, then it should work for all other keys. Because having SHA-256 output of just "0000000000000000000000000000000000000000000000000000000000000001" is very unlikely, and if only seeds will be allowed, then all non-seeded keys will be trapped (it will be still possible to move them in theory, but in practice, it may require breaking for example SHA-256, or whatever is used for seeding).
Also, I wonder, what will be the space of allowed seeds. Because we have around 2^256 possible private and public keys, but many seeds are based on 12 words, which then have only 128-bit entropy. And if seed length would have no upper limit, then someone may try to upload a JPEG by trying to recover a seed with 3k words. To avoid all of that, things should be based just on raw private keys, and proofs should work regardless of the seeds.
One example of a proof, which could work for every private key, is DLEQ proof: you have the same private key in a strong curve, like secp256k1, and in some weaker curve, like secp160k1. And then, you sign a message in a way, where you prove, that you have the private key, without revealing it. But of course, if ECDSA will be fully broken, then going from 256-bit curve to, for example, 512-bit curve, may not be sufficient.
The current state of Phase C proposes a recovery method primarily for BIP39 seed holders. However, not all UTXOs on the chain are derived from a single seed. There are thousands of users who directly possess the private key. If recovery is based solely on the seed, millions of UTXOs outside the seed could remain locked. This presents a significant problem.
Perhaps a solution can be found. A system should be designed that allows recovery of both the seed and RAW PV Keys. Perhaps a system could be designed where users can provide proof of ZK. Is this not possible?
I do not like this at all.
This basically makes us Tether, except we are also indiscriminately hamstringing receives, which is going to take down *a lot* of Bitcoin businesses - Not only those still using legacy addresses for some reason, but also everyone else on Segwit.
This will also cause a transaction rush, shooting up mempool fees and possibly causing a collapse in the price from any resulting sell-off.
Not entirely as, this thread concerns itself with an aspect to the BIP proposal with focus on possible recoverability of assets or coins that wasnt sent to a quantum resistant address within a defined period of 5years.
Found this on the draft to use a 3years time frame instead of 5years and its in phase 4.
I want to point again to Tadge Dryja's scheme which could be used alternatively to complicated proofs involving BIP39 seeds. It is simple but genius if I'm not missing something
It could secure coins on addresses where the public key was never exposed, i.e. the address was not re-used. It would not need any preventive migration of coins to quantum-secure addresses, and instead could be applied once the quantum threat becomes real.
The simplest variant is so simple that many would have thought perhaps "why has this never ocurred to me"
Spends from ECDSA keys from a certain block on are only allowed if the transaction ID was computed and included before in a transaction with an OP_RETURN output, with a certain delay before the "real" transaction.
I.e. each transaction has two parts: 1) the OP_RETURN tx with the TXID of the "real" transaction, and 2) after e.g. 50 blocks, the "real" transaction (which reveals the public key)
The owner of the ECDSA key can always compute the TXID of a new transaction. A valid TXID followed by a real transaction which matches that TXID, is thus a proof that a person knows the private key. But the TXID itself doesn't reveal the signature and also doesn't make the computing of the signature easier.
The delay (e.g. 50 blocks) has to be added to prevent the quantum attacker to steal the signature from the public key when the transaction is in the mempool. He could create a transaction to his own address, add its TXID in an OP_RETURN output and then broadcast the transaction, if he's lucky he could in theory get the coins (although his success isn't guaranteed).
The scheme would need a working post-quantum transaction model (FALCON, SPHINCS+ etc.) to be implemented before it could be used to move existing coins. You would thus need to post the OP_RETURN output in a "post-quantum" transaction, and then move the "real" coins using an ECDSA signature.
Dryja has presented more advanced variants of this concept which don't need a delay, and it is also based on earlier work from 2018. But I think this is probably one of the most interesting ways to move forward: prepare a post-quantum scheme and the code for this "commit-reveal" scheme, but don't invalidate ECDSA spendings until the quantum threat is really around the corner.
Someone correct me if I am mistaken, but this is not BIP360. I stumbled upon BIP360 from the Bitcoin Core repository and then noticed that these phases are missing and remembered this thread. The proposal with phases does not have a BIP number, it is not BIP360 but it requires BIP360.
Unassigned BIP with phases as mentioned in the first post: https://github.com/bitcoin/bips/blob/c64b817f945d9e84581d01478a7ba216c6a7920c/bip-post-quantum-migration.mediawiki.
Here is the pull request of this proposal: https://github.com/bitcoin/bips/pull/1895
The proposal with the number BIP360 is a bit older: https://github.com/bitcoin/bips/blob/4095d33d0d781916df7fc2aec0764d55b30e64d9/bip-0360.mediawiki
Here is the pull request for this proposal: https://github.com/bitcoin/bips/pull/1670
I ask OP to correct the title if I am correct. We can include BIP360 in the discussion here though as it is a requirement for this proposal. Neither have been accepted yet into the BIP repository, an earlier version of my post mistakenly indicated that BIP360 has been accepted which is not true.
The main points of this proposal have only been introduced very recently.
I don't see anything really wrong with this as a starting point, putting aside details relating to the implementation and the horrible pull request submitted to Bitcoin Core. Thoughts anyone? d5000? stwenhao?