Quote from: casascius on March 18, 2012, 06:39:21 PM

Quote from: Gavin Andresen on March 18, 2012, 04:12:07 PM

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint ' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify. etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

If you did something like this, my pet preferred default setting for the majority would be to just auto-checkpoint anything 6 blocks deep as long as the client believes it has had a good streak of good connectivity (e.g. it has been online for at least 24 hours and has received blocks at a rate consistent with their expected creation rate). And for the client to simply shut down if it receives an attempt to rewrite more than 6 blocks - that is, a shutdown until it is issued an explicit checkpoint command to lock in what the user believes is the correct block chain.

A GUI interface to respond to the shutdown could offer the user two options: 1) a "phone home" option that allows the user to explicitly trust the dev team on a one-time basis to resolve the conflict (it would hit a predetermined URL and look for a signed message), or 2) a textbox in which the user can paste the RPC command supporting the view of his choice (which presumably would be clipped from a forum or whatever news source the user trusts) or a URL leading to a message containing the same.

+1

I suggested the same a while backbasically, stated another way, you don't allow reorgs deeper than 6 blocks. I think plenty of testing would be in order before making such a change, but it seems like a good solution on the surface. Such a change would force any would-be attackers out into the open with their hashing power. And 6 seems like plenty of time to allow miners to get their blocks distributed. Any subnets cutoff from the main network would have to operate under an assumption that a) their blocks may be invalidated and b) they may have to take manual action to rejoin the main network. The subnet could continue to mine to ensure the integrity of their own transactions while separated from the main net, but they would have to expect that their block rewards may eventually be rendered invalid.