{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-09-14\n🗒️ 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.\n📝 Original message:\u003e But that doesn't solve the whole problem, because the block timestamp\n\u003e checking is based on the assumption that the node is looking at the bitcoin\n\u003e clock rather than the, ahem, real clock.  If we change the idea of network\n\u003e time to NTP, we will then need to write (and test!) new block timestamp\n\u003e rules to account for the new assumptions.\n\nWhy?\n\nThe block timestamp rules currently give HOURS of wiggle-room for\ntimestamps. We can't change those rules without risking a chain split.\n\nHere's a thumbnail sketch of what I'm thinking:\n\nWhen new tip-of-chain blocks are received, IF their timestamp is\nunreasonable with respect to system time and the previous block's\ntimestamp, then add them to a 'discouraged' list.  (but follow the\ncurrent rules for outright rejecting blocks based on timestamps too\nfar in the future or past)\n\nModify the getwork code to build on the second-from-tip block if the\nfirst-on-tip block is on the discouraged list.\n\nAssuming a majority of pools/miners adopt the \"discourage blocks with\nstale timestamps\" rule, that should squash any incentive for cartels\nto try to start playing with difficulty-- you would have to have 50+%\npower to start, or you risk producing mostly orphan blocks.\n\n\u003e Also, this is going to cause problems for at least one pool operator.\n\nI'll trade more security for \"make at least one pool operator have to\ndo some work\" any day.\n\n-- \n--\nGavin Andresen"}