If they need to change to a new hash function, there’ll probably be plenty of warning, so a sensible rollout can be planned. If you need a new hash function, everyone’s going to have to update anyway, and I think most people involved in bitcoin would prefer to keep the existing blockchain rather than start again from scratch.
The recent fork was different, in that the problem wasn’t detected until it happened (and the people running old versions are going to have to upgrade in any case).
If you need a new hash function, everyone’s going to have to update anyway, and I think most people involved in bitcoin would prefer to keep the existing blockchain rather than start again from scratch.
But is this even possible? If the hashes are broken, depending on the attack any transaction on the ‘old’ blockchain may be a double-spend or theft, and so backwards compatibility just imports the new security problems. (Imagine there’s a new attack which can double bitcoins at an old-chain address, but the new-chain with a hash forbidding it is backwards-compatible and accepts all old-address transmissions to new-addresses; then as soon as the attacks finally become practical, anyone can flood the new-chain with counterfeit coins.)
Easiest to just make a clean break with an entirely new blockchain. People can sell out their old coins and buy in, or they can use a different scheme. (For example, Bitcoins can be verifiably destroyed, so the new blockchain’s protocol might use that as a way to launder 1.0 into 2.0; at least as long as there is no largescale counterfeiting happening.)
I think it could be done, assuming there’s enough time between the old hash looking vulnerable and it actually being broken:
Release a new client version X which uses the new hash after some future block N. Once block N+1000 has been found , hash every block up to N using the new hash and bake a final result of that into client version X+1, such that it rejects all old-hash blocks that haven’t been blessed by the new hash.
Still, that is rather involved, and your destroy-to-convert scheme (which could be disabled once the old hash is looking too shaky) looks like it would work pretty well.
I’m not sure how well selling old coins and buying in would work, though—someone’s going to be left holding a large bag of worthless bitcoins at the end of that.
If they need to change to a new hash function, there’ll probably be plenty of warning, so a sensible rollout can be planned. If you need a new hash function, everyone’s going to have to update anyway, and I think most people involved in bitcoin would prefer to keep the existing blockchain rather than start again from scratch.
The recent fork was different, in that the problem wasn’t detected until it happened (and the people running old versions are going to have to upgrade in any case).
But is this even possible? If the hashes are broken, depending on the attack any transaction on the ‘old’ blockchain may be a double-spend or theft, and so backwards compatibility just imports the new security problems. (Imagine there’s a new attack which can double bitcoins at an old-chain address, but the new-chain with a hash forbidding it is backwards-compatible and accepts all old-address transmissions to new-addresses; then as soon as the attacks finally become practical, anyone can flood the new-chain with counterfeit coins.)
Easiest to just make a clean break with an entirely new blockchain. People can sell out their old coins and buy in, or they can use a different scheme. (For example, Bitcoins can be verifiably destroyed, so the new blockchain’s protocol might use that as a way to launder 1.0 into 2.0; at least as long as there is no largescale counterfeiting happening.)
I think it could be done, assuming there’s enough time between the old hash looking vulnerable and it actually being broken:
Release a new client version X which uses the new hash after some future block N. Once block N+1000 has been found , hash every block up to N using the new hash and bake a final result of that into client version X+1, such that it rejects all old-hash blocks that haven’t been blessed by the new hash.
Still, that is rather involved, and your destroy-to-convert scheme (which could be disabled once the old hash is looking too shaky) looks like it would work pretty well.
I’m not sure how well selling old coins and buying in would work, though—someone’s going to be left holding a large bag of worthless bitcoins at the end of that.