Quote from: gmaxwell on November 01, 2014, 09:47:55 PM

Pieter and I-- at least-- have been talking about it for a while as part of the motivation for headers first, even prior to the fraud proofs: past some limit (E.g. max(60days work at the highest difficulty ever observed in the best chain, 2016 blocks) ) a huge reorganization at tip is a guaranteed system failure.

What is special about 60 days of work?

Quote

For a while this wasn't as interesting because the total time to replace the chain with the tips hashrate was very low, but it's finally expanding nicely: http://bitcoin.sipa.be/powdays-50k.png

Right, you can replace the entire blockchain with two doubling times worth of hashrate.

That number increasing means that the hash rate doubling time is increasing?

Quote

Another potential softer safety mechanism is simply holding the confirmation count in the RPC at zero when there has been a 'system failure grade' reorganization to allow time for a "higher process" to sort out the mess. This also needs a couple other pieces to be completely useful, like the ability to manually invalidate a block over the RPC.

This is a good idea anyway. A 60 block re-org would be indicate that something major has happened.

If headers were broadcast for invalid forks, then clients on both sides of the chain could detect the condition.

Quote

Obviously fraud proofs have been on my mind for a long time, but they have a lot of protocol surface area. The recent reorganizations of Bitcoin core (e.g. libscript work) will make it easier to work on them with confidence, e.g. be able to build an external process that receives and checks fraud proofs.

Fraud proofs would presumably be new messages, so they would be sent to an external process? Isn't that more complex?