> But that doesn't solve the whole problem, because the block timestamp > checking is based on the assumption that the node is looking at the bitcoin > clock rather than the, ahem, real clock. If we change the idea of network > time to NTP, we will then need to write (and test!) new block timestamp > rules to account for the new assumptions.
Why? The block timestamp rules currently give HOURS of wiggle-room for timestamps. We can't change those rules without risking a chain split. Here's a thumbnail sketch of what I'm thinking: When new tip-of-chain blocks are received, IF their timestamp is unreasonable with respect to system time and the previous block's timestamp, then add them to a 'discouraged' list. (but follow the current rules for outright rejecting blocks based on timestamps too far in the future or past) Modify the getwork code to build on the second-from-tip block if the first-on-tip block is on the discouraged list. Assuming a majority of pools/miners adopt the "discourage blocks with stale timestamps" rule, that should squash any incentive for cartels to try to start playing with difficulty-- you would have to have 50+% power to start, or you risk producing mostly orphan blocks. > Also, this is going to cause problems for at least one pool operator. I'll trade more security for "make at least one pool operator have to do some work" any day. -- -- Gavin Andresen ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
