rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2011-09-14 🗒️ Summary of this message: Changing the network time to NTP would require new block timestamp rules, risking a chain split. Discouraging blocks with unreasonable timestamps could increase security. 📝 Original message:> 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