Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2011-09-14 🗒️ Summary of this message: Changing the ...
📅 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
🗒️ 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