Brainstorming Fixing Time (node clocks, monotonic timestamps, future time limit)

#1

In his “Best Difficulty Algorithm, Timestamp Rules, Selfish Mining, Selecting N” post, independent DAA researcher zawy is suggesting following changes:

To summarize this section, to prevent all the attacks related to difficulty algorithms, time, and timestamps, Lamport’s ancient distributed consensus requirements on time and timestamps should be applied to Nakamoto consensus. Nakamoto consensus is a distributed consensus mechanism and Lamport’s derivations were independent of the algorithm. See “Timestamp Attacks” for a history of all the difficulty algorithm, time, and timestamp attacks on Nakamoto consensus due to Satoshi et al not following Lamport’s requirements. These requirements are:

  1. Peer time should not be used, only independent local time.
  2. Monotonic timestamps should always be used, not the median of the past 11 timestamps (MTP).
  3. Future Time Limit (FTL) should be reduced to a fraction of block time
  4. Timespan limits and other methods of changing what a correct difficulty algorithm calculates should not be used.

So far, with ASERT, we have implemented only 4.

Did we consider implementing 1.-3. before?

2 Likes
#2

Somewhat tangential to this is the discussion of adjusting to custom blocktime (perhaps initially set to 1 min) but without relatively adjusting ABLA, DAA, script time locks and emission schedule.

Perhaps this issue of a “time upgrade” can all be wrapped up together into a CHIP - proposed as a companion to the 1 minute blocks?

#3

Concept for “Tanya” time upgrade, might add some inspiration.

image
image1024×1024 90.6 KB

#4

??? we MUST adjust those

These time-related issues have nothing to do with a particular block time target, they’re about which time does the network use as reference time, are timestamps recorded in blocks enforced to be fully or loosely monotonic, how big a difference between recorded and real time will nodes accept?

2 Likes
#5

ABLA is adjusted so that it doesn’t relatively adjust. If you follow me. Yes I understand that the other changes are required, and these are more optional and not related to 1 min blocks.

I’m just saying “Time” is a cool theme, so perhaps all of the related changes could be packaged together (would make for strong community interest in discussing it).

And technically the change to “making blocktime adjustable” is easily sliced off from the actual change of “and make it 1 minute”.

Just thinking out loud.

2 Likes
#6

well, it only really works as consensus change if we actually make a change, it’s really all about refactoring consensus rules, if you just did the refactoring while keeping the same time then it would be all the same consensus rules and really just an under-the-hood change to how node works out consensus rules

the 2nd thing is node RPC, here it could prepare clients for future change by adding the block tick to the output so clients interested in blockchain progression could switch to it ahead of time, and be agnostic to some future change in target time

then, there’s SPV header commitments which could remove dependency on whole headers from SPV clients, and dependency could be removed even now because Fulcrum already serves this stuff - but then you have the element of trust (which can be distributed across multiple servers)

1 Like