Timestamps specification proposal #742
Conversation
docs/timestamps.md
Outdated
| # Timestamps | ||
|
|
||
| ## Motivation | ||
| In order to enable snapshotting based on time constraints rather than special messages in the Tangle (e.g., milestones), nodes need to share the same perception of time. Specifically, they need to have consensus on the *age of messages*. Therefore, messages contain a field `timestamp` which represents the creation time of the message and is signed by the issuing node. |
There was a problem hiding this comment.
Probably better not to mention milestones (say checkpoints?)
Another application for timestamps is for Adaptive PoW
There was a problem hiding this comment.
Luigi, I have added a comment on aPoW in the next sentence. Does it make sense?
| + FPC: it's used to perform voting on timestamps. | ||
|
|
||
| ## Parameters | ||
| - `D` gratuitous network delay ~5 minutes. We assume all messages are delivered within this time. |
There was a problem hiding this comment.
Are these timings (D, w) updated? I recall we shortened them..
docs/timestamps.md
Outdated
| - `D` gratuitous network delay ~5 minutes. We assume all messages are delivered within this time. | ||
| - `w` window ~30 minutes. Require w>2D | ||
| - `Delta` max difference in consecutive timestamps. Require Delta>w+D | ||
| - `tw` transaction timestamp window. Max difference between message and transaction timestamp. |
There was a problem hiding this comment.
Are definition of message and transaction timestamps explained elsewhere?
|
|
||
|
|
||
| ## Clock synchronization | ||
| Nodes need to share the same perception of time to fulfill `Req_1`. Therefore, we propose that nodes synchronize their clock on startup and resynchronize periodically every `60min` to counter [drift](https://en.wikipedia.org/wiki/Clock_drift) of local clocks. Instead of changing a nodes' system clock we introduce an `offset` parameter to adjust for differences between *network time* and local time of a node. Initially, the [Network Time Protocol (NTP)](https://en.wikipedia.org/wiki/Network_Time_Protocol) ([Go implementation](https://github.com/beevik/ntp)) can be used to achieve this task. |
There was a problem hiding this comment.
Instead of changing a nodes' system clock we introduce an
offsetparameter to adjust for differences between network time and local time of a node.
Why do we do this? Is that easier from an implementation point of view?
There was a problem hiding this comment.
Initially, the Network Time Protocol (NTP) (Go implementation)
Should we have a second backup service to get network time in case NTP is down?
| ### Failure to (re)sync clock | ||
| We gracefully shut down the node if: | ||
| - initial synchronization of time fails | ||
| - resynchronization fails for more than `3` times |
There was a problem hiding this comment.
Link to resynchronization specs here?
| ``` | ||
|
|
||
| ### Message timestamp vs transaction timestamp | ||
| Transactions contain a timestamp that is signed by the user when creating the transaction. It is thus different from the timestamp in the message which is created and signed by the node. We require |
There was a problem hiding this comment.
Does this imply that PoW computation should be smaller than tw?
There was a problem hiding this comment.
What's the order of magnitude of tw?
| Clearly, in order to have a correct perception of the timestamp quality, **we assume the node is in sync** (see section [Not in Sync](#Not_in_Sync) otherwise). | ||
| Voting on timestamps should not occur for every messsage. Specifically, only for those that arrive around the border of the threshold +-`w`. | ||
|
|
||
| The initial opinion and level of knowledge are set according to the following rule: |
There was a problem hiding this comment.
Are we sure this window should be symmetric around current time? Messages with future timestamps could probably only be received in case of malicious behavior and unsynced clocks. We maybe want to have more thinking around that
| ## Consensus | ||
| The timestamp should define the time when the message was created and issued to the Tangle, and this must be enforced to some degree through voting. Specifically, nodes will vote on whether the timestamp was issued within `w` of current local time. This time window is large to account for the network delay. | ||
| Clearly, in order to have a correct perception of the timestamp quality, **we assume the node is in sync** (see section [Not in Sync](#Not_in_Sync) otherwise). | ||
| Voting on timestamps should not occur for every messsage. Specifically, only for those that arrive around the border of the threshold +-`w`. |
There was a problem hiding this comment.
What protects against an attacker sending many messages that will arrive in the time around the threshold +-w? Couldn't that lead to a problem, because then quite a lot of voting is needed?
There was a problem hiding this comment.
That is correct. However, an attacker could also force a lot of voting by spamming double spends. So this does not really open a new attack vector.
We're currently restructuring a lot and need to update all the specs with the new details. In #880 you can see a new data flow (still subject to changes at the moment). Generally, everything that happens after the scheduler is governed by the congestion control algorithm. As such, an attacker can not force unlimited voting (be it through conflicts or timestamps) but is limited by its fair share
| ## Motivation | ||
| In order to enable snapshotting based on time constraints rather than special messages in the Tangle (e.g., milestones), nodes need to share the same perception of time. Specifically, they need to have consensus on the *age of messages*. Therefore, messages contain a field `timestamp` which represents the creation time of the message and is signed by the issuing node. | ||
|
|
||
| Having consensus on the creation time of messages enables not only partial ordering but also new applications that require certain guarantees regarding time. |
There was a problem hiding this comment.
| Having consensus on the creation time of messages enables not only partial ordering but also new applications that require certain guarantees regarding time. | |
| Having consensus on the creation time of messages enables not only partial ordering but also new applications that require certain guarantees regarding time such as adaptive PoW. |
docs/timestamps.md
Outdated
| # Timestamps | ||
|
|
||
| ## Motivation | ||
| In order to enable snapshotting based on time constraints rather than special messages in the Tangle (e.g., milestones), nodes need to share the same perception of time. Specifically, they need to have consensus on the *age of messages*. Therefore, messages contain a field `timestamp` which represents the creation time of the message and is signed by the issuing node. |
There was a problem hiding this comment.
Luigi, I have added a comment on aPoW in the next sentence. Does it make sense?
| Having consensus on the creation time of messages enables not only partial ordering but also new applications that require certain guarantees regarding time. | ||
|
|
||
| In this document we propose a mechanism achieving consensus on message timestamps by combining a synchronous and an asynchronous approach. While online nodes can leverage FPC to vote on timestamps, nodes that join the network at a later time use an approach similar to On Tangle Voting to determine valid timestamps. | ||
|
|
There was a problem hiding this comment.
Rather than saying similar to onTangle voting we should say what the specific approach is. (approval weight? reorg?)
|
|
||
| ## Parameters | ||
| - `D` gratuitous network delay ~5 minutes. We assume all messages are delivered within this time. | ||
| - `w` window ~30 minutes. Require w>2D |
|
This will be included in #825. |
Rendered