Quote from: leopard2 on March 10, 2014, 08:19:37 PM

One question: how would you prevent 51% attacks during step 7? There will be a time span until most miners are mining this so that the network would be vulnerable, or not?

In the emergency scenario that I have in mind, the old network is already under attack and unusable.

For example, let's imagine a serious flaw in SHA-256 is discovered and it becomes possible to calculate the nonce for any block and any difficulty in essentially no time.
Then it wouldn't take an hour until miners start abusing this flaw and we'd have virtually infinite hashing power which keeps flooding us with new blocks.
The difficulty could never adjust to this because the only thing that limits blocks from being created is the network latency.

Applying the above procedure to this scenario, step 1 would consist of replacing the defunct SHA-256 function with something else, for example Keccak.
Step 2 would be to agree on the last block that was mined before the SHA-256 flaw was first used.

When distributing the new software in step 7, the old network would still be online and running, but it is unusable, because it keeps being flooded with new blocks.
The new network would be established just like any other Keccak-based altcoin, with the exception that everyone's wallet balance is preserved.

About the >50% attack: It's like with every other altcoin. An attack becomes increasingly difficult as the network keeps growing. But yes, conversely, this means that the new network is most vulnerable at the beginning.

Quote from: Ichthyo on March 11, 2014, 02:08:35 AM

Basically we had this very situation last year.
A critical flaw in a just released new version of the standard client was discovered, which would have led to transactions being judged differently by miners, and thus to a split of the chain. It took the core devs just some hours to negotiate with some large miner pools to revert back. Before 12:00 PM UTC next day, most of the bitcoin network had followed this move, and the few problematic blocks where obsoleted this way.

Initially this created quite some turmoil and a lot of bad press, but in the end consensus was that this incident showed the Bitcoin Community's ability to deal with critical situations professionally.

Exactly. The events of March 2013 strengthened my confidence in Bitcoin's stability.
I'm convinced that in case of emergency, most if not all of the Bitcoin developers, miners, and full node operators will act together in Bitcoin's best interest.
I would argue that this was one of the things that drove up the currency's value in the following months.

While we can't foresee what the exact cause of emergency will be, it can't hurt to make plans as much as possible.

Quote from: leopard2 on March 10, 2014, 08:19:37 PM

Should that not be the Bitcoin foundation's job to ensure such a procedure exists?

There is no such thing like the Bitcoin foundation. There are multiple organisations supporting the Bitcoin project, one of them is called "Bitcoin Foundation", but that doesn't make them officially responsible for Bitcoin.

Quote from: leopard2 on March 10, 2014, 08:19:37 PM

It would be immensely confidence building to have such a safety net.

Definitely! Let's just do it. Wink