📅 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
Gavin Andresen [ARCHIVE] /
npub1s4…d44kw
2023-06-07 02:25:27
in reply to nevent1q…trgx
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 02:25:27Event JSON
{
"id": "292eb67faac4ea683f0d490a03b919d0f4287c8c936a3960d16758d788d52d54",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686104727,
"kind": 1,
"tags": [
[
"e",
"c5d8eb0720120c08594c588b2c728c7a4f1ca34d1ae4dfac6ef6225ba2d5a835",
"",
"root"
],
[
"e",
"3e66faa4dab258fe324d348a0dce94e73ab0563728f36a48f339a1b9378f308d",
"",
"reply"
],
[
"p",
"59566453b962ef5a0785be04ff51728e2eaa248d99f113bb2e2bc129364c88c0"
]
],
"content": "📅 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",
"sig": "1d7f374689ce5bc2fae6a792080b9ecc649bbbf8c2ac615bce8aea26a8185ec2558c86532c7ded10462dd80a53912df1f6e34d9b63768e406f862a32298c0fd3"
}