There’s a big difference between adding some bugfixes or nifty userland features to what is now merely one client among many—and making a fundamental backwards incompatible upgrade to the entire protocol which would affect every client, miner, and interfacing software with major security ramifications. Interoperability is fragile (witness the recent blockchain fork which led to lead dev Gavin paying out >$70k in bitcoins to miners on the wrong side of the fork), and changing hash functions will break it.
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.
I don’t think the delineation between old and new will be quite so clear. Consider a new client that all the miners switch to, importing your wallet to this client causes a transaction to appear on the network transferring all your old coins to a new client, when confirmed all your old coins are now bitcoin2, which can’t be sent to bitcoin1 wallets. ANy attempt to use your old bitcoin1 coins will show up as invalid.
But the devs released updated clients all the time.
There’s a big difference between adding some bugfixes or nifty userland features to what is now merely one client among many—and making a fundamental backwards incompatible upgrade to the entire protocol which would affect every client, miner, and interfacing software with major security ramifications. Interoperability is fragile (witness the recent blockchain fork which led to lead dev Gavin paying out >$70k in bitcoins to miners on the wrong side of the fork), and changing hash functions will break it.
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.
I don’t think the delineation between old and new will be quite so clear. Consider a new client that all the miners switch to, importing your wallet to this client causes a transaction to appear on the network transferring all your old coins to a new client, when confirmed all your old coins are now bitcoin2, which can’t be sent to bitcoin1 wallets. ANy attempt to use your old bitcoin1 coins will show up as invalid.