 Show Posts
|
|
Pages: « 1 [2]
|
|
One more thing - could potentially extension blocks be a solution for this?
I mean to start a "new parallel" SHA-3 chain like an extension block chain, with interoperability (people can move coins from "old" to "new" and vice versa) which can last even for decades.
If SHA-256 is then dangerously close to being broken, could the original chain be somehow eliminated/merged into the extension block chain without the coins not moved to "new" being lost?
|
|
|
|
|
Thanks again, garlonicon, for all your answers!
|
|
|
|
I am trying to read the github thread but it is probably beyond my capabilities. I thought that because of unsigned 32-bit integers used in Bitcoin the problem is "postponed" till 2106. In other words - is it easily repairable for the next versions? It is clean, but it is hard-fork. In general, hard forks can do everything and make it clean. But we cannot use hard forks for everything, because of backward compatibility, that's why BTC is going to do soft-fork or no-fork every time when possible. I absolutely agree with that. I was just curious how this exact hard fork would work. If we do the hard fork with hard-coded chain (state of the UTXO set at some block height?) then the new nodes would sync only from the new Genesis Block? They would not check the history prior to the hard fork? |
|
|
|
I don't know, because we don't have a clear proposal for 2038 year problem or 2106 year problem. For now, the latest Core version is crashing in 2038. The whole chain will stop in 2106. Can you please elaborate? I though the timestamp overflow bug will cause the chain to stop in 2106. Did the latest Core version bring a worse bug? You can also hard-code it into the new Genesis Block as a commitment, but I think we should not do that. What are the risks of that? It seems to be a clean solution at first sight. |
|
|
|
The whole world will need to change when SHA256 is broken. This encryption algo is being used almost everywhere. Mostly in banking. When SHA256 gets hacked, crypto will be the last thing you'll worry about. The civilization will collapse if we don't act in time. People will lose their assets, their bank accounts, their passwords and everything else. Crypto will be a drop in the bucket.
This is the answer I always get. I am sorry but that was not my question. |
|
|
|
|
So that is about soft-forking, am I right?
1) If we found a consensus to hard fork (because it would be maybe necessary), how would we proceed?
I guess we would not have to re-hash things but start with a new hash function from a certain block? Would the old SHA-256 chain/history be safe even without re-hashing if we do the hard fork?
2) Could all the existing UTXOs stay spendable (even if they could be stolen if not moved to a new safe address)?
Thank you
|
|
|
|
|
Thanks, garlonicon.
One more question regarding the solution you described earlier - would everything above (txids, merkle trees, signature hashes, etc.) need to be re-hashed back to the Genesis Block or the new client would rehash only the new "activity" - like from the UTXO set state at a certain point of time, from some UTXO commitment (I mean practically importing the UTXO set into the new system)? If it is back to Genesis Block and every client would need to do that, it would be computationally difficult I suppose.
|
|
|
|
My question was more about what would have to be changed if it occurs gradually, not overnight. 2) We have 10 years to migrate (we know the attacks will be possible but will come gradually, not overnight) |
|
|
|
How hard would be to migrate these parts of Bitcoin with a minimum damage? Porting txids: every txid should be re-hashed, just like in Segwit you have txid and hash, here you will have one more field for a new hash. Mining: you will have two difficulties, one to preserve the old, SHA-256 chain, and the new, to keep it unaltered. Merkle trees: each merkle tree should be re-hashed, it could be a commitment, like in Segwit, but could be also better compressed. Block headers: you will have 80-byte new header that would contain both old and new data, in a combined and compressed form. Signature hashes: you have to use new hashes, and re-hash old signatures, because it is the same (or even worse) case than txids. Bitcoin Message: the same solution as for signature hashes; also encourage upgrading to signet-way-of-signing-things. Hashed public keys: old coins should be moved to the new addresses; it could be spendable or not, whatever option will win. Hashed scripts: the same solution as for hashed public keys. Commitments: the new chain will be started with one, huge commitment, containing the whole old chain. Timestamps: they are invalid, new timestamps should be year-2038-resistant and year-2106-resistant, it could be modulo 2^32, but should be clearly defined, whatever it will be. One more question - would everything above (txids, merkle trees, signature hashes, etc.) need to be re-hashed back to the Genesis Block or the new client would rehash only the new "activity" - like from the UTXO set state at a certain point of time, from some UTXO commitment (I mean practically importing the UTXO set into the new system)? If it is back to Genesis Block and every client would need to do that, it would be computationally difficult I suppose. |
|
|
|
I know the form of past breaks do not imply how fast the future breaks will be. But if the past repeats the breaks will be rather gradual than 0-day so we have hopefully enough time to migrate. Your opinion/"hopes" on that?  |
|
|
|
1) I don't know. I don't think quantum computers will be a problem. I think there are more serious issues, like lattice attacks, that can be done on a non-quantum PC's.
Never heard of it but a little bit of googling and it looks quite scary. How serious do you think it could become? Can there be any countermeasures against these attacks? |
|
|
|
|
Thanks for this answer, garlonicon, once again.
This is all very helpful!
Two more questions if I may:
1) As I understand quantum computers will be (Bitcoin related and if they will ever exist with enough logical qubits) a threat only to public key cryptography.
Regarding SHA-256 and Grover's algorithm - this should not effect safety of this hashing function in Bitcoin that much, am I right?
2) This will be more about your personal opinion rather than a technical explanation.
What do you think would happen to all the not-moved UTXO's (lost/forgotten/etc. coins) - or what do you think the consesus would be?
I think there would never be a consensus to freeze these coins (and it should not be IMO).
I think these coins should serve more like a honeypot for all the "hash-breakers" or quantum computers (in case of ECDSA).
|
|
|
|
Hashed public keys: old coins should be moved to the new addresses; it could be spendable or not, whatever option will win.
Hashed scripts: the same solution as for hashed public keys.
Thanks a lot for your excellent answer! What do you think would happen to L2 layers, especially LN? Would all the channels needed to be closed and re-opened again or could there be any better migration path? |
|
|
|
|
I have found a lot of threads about PoW but not much about other aspects of SHA-256 dependence so I hope this won't be a duplicate.
Assumptions:
1) Let's say we know that SHA-256 is weakened in every possible way (collisions/preimage attacks/second preimage attacks) and will become risky to use within 10 years.
2) We have 10 years to migrate (we know the attacks will be possible but will come gradually, not overnight)
3) Let's say we have a safe replacement in the form of, for example, SHA-3 (just theoretically, it can be any hash function of the future, it is not important for the following questions)
How critical do you think the situation would be for Bitcoin? Not particularly concerned about PoW at the moment.
Questions:
1) What would have to be upgraded in Bitcoin besides mining - txids, merkle trees, block headers, signature hashes?
2) How hard would be to migrate these parts of Bitcoin with a minimum damage?
3) What would happen to all the UTXOs in e.g. P2SH, P2WPKH, etc. - could they still be moved after the hash function change (which would be a hardfork probably)?
I know we probably won't have to deal with this in our lifetime, but again, in theory, I would like to know how you think about a similar emergency scenario.
Thanks a lot!
|
|
|
|
|
