I just finished watching the video on coordicide and specifically the part about timestamping. As some might know I have been onto getting timestamping in the tangle for a while now and I would really like to see a definitive answer on why the following is not preferred over voting on time.
For simplicity, I use a message (/transaction) M with trunk T and branch B that could be either a bundle or variable-sized. The message has a timestamp (ts) that is independent of the payload. Just like trunk and branch, it is an integral part of the tangle structure.
A timestamp is in milliseconds and represents wall-time. An imperfect representation of global ordering. Something, considering we use the tangle, we all agree on simply doesn’t exist. None-the-less still a very useful measure for all sorts of mechanisms.
Add to the tangle as a rule (Make it a vector/logical/Lamport clock):
M.ts >= T.ts && M.ts >= B.ts
This simple rule always needs to be valid, just like your trunk and branch needs to be existing. No upper or lower bound on this validation rule.
Creating a transaction:
We have two main actors: The Node & The Client, they each have their own clock.
The client calls the node for tip selection. Tip selection is the standard URTS with an upper bound of the node’s clock. Meaning no transactions with a timestamp higher then the node’s clock will be selected by this particular node. The node returns a trunk and branch and it’s own current timestamp.
The client checks if the timestamp is within ± 30(N) seconds. If not the client libs will throw an error. The local modifier is on the client.
The message that the client creates contains the timestamp obtained together with tip selection. While doing proof of work this timestamp is increased as time passes.
When the proof of work is finished, send the message to the node and in turn checks if the message timestamp is ± 30(N) seconds. It then stores and broadcasts it.
This very simple mechanism creates a vote per message on what each machine(be it client or node) on the planet thinks what the current time is. Relative to each trunk and branch we already know the ordering is correct and that the flow of time is in one direction. But now each message votes it’s perceived global order of events relative to the rest of the messages.
My main question is, what are the problems with this approach vs voting every 30 minutes?
It seems so simple and timestamps become much more accurate as TPS goes up.
I am aware of and it’s deterministic described method could be used for transactions to calculate it’s confidence.:
And just now it seems a similar idea was proposed: