Quote from: TierNolan on November 01, 2014, 10:22:40 PM

special about 60 days of work?

It's an arbitrary big number which is hopefully macroscopic relative to whatever external process you'd hope to rescue the system if it failed, but hopefully still small enough to give a good speedup on the checking.

I only used a specific number because thats an example of the kind of numbers that were banded about before... even given pretty healthy hashrate growth far in excess of computer industry historic trends numbers in that space should still be adequate to keep downloads bandwidth bounded instead of cpu bounded. (Also keep in mind that libsecp256k1 is >6x faster than openssl).

Quote

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

Yes, for many months: http://bitcoin.sipa.be/growth.png

Quote

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

Yep.

Quote

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

Complexity by itself isn't really the engineering constraint (passing a message is no big deal, in any case) the concern would be complexity coupled with risk. If there is something complex but its strongly isolated you can reason about what kind of things can happen if it goes wrong. E.g. fraud proofs can initially run over a separate protocol, communicate to an isolated sandboxed process, and even if they've massively gone wrong the threat is likely limited to a nuisance of making all your transactions show as unconfirmed, rather than splitting the consensus or stealing keys or what have you. See Matt's relaynode network client (https://github.com/TheBlueMatt/RelayNode) for an example of how to develop and try out protocol features (in that case, relaying blocks more efficiently by taking advantage of transaction pre-forwarding) with reduced risk to the production Bitcoin system.