Min date set to 0 halves the probability that a managing node is outside the specified range (because only one limit can fail instead of 2).
I was referring to a very hypothetical case of someone trying to timestamp a document with a very narrow range. A 10 mn range is sufficient for most people and in this case a 1 or 2 seconds offset will not really make a difference. Besides we don’t really know the travel time.
Well…Time and Irvine are not very good friends…
The truth, I don’t think your path proposal, defining a new global SD, is the good answer.
To my mind, create a specific data type with certain characteristics, similar to the DNS type or Safecoin type could be better.
Might work as follows:
We define a new type of structured data (TimeStamp). Among its features we defined that can’t be erased and must contain:
.-Data owner (not always required)
.-Time
.-Interval
To add a new record of TimeStamp type, a node sends a message to their managers with a time and interval. Managers send that data to all nodes in a group. Those who agree, answer affirmative.
When there are sufficient affirmative answers, we can use a accumulator, the new record, signed by the managers, is created. To be sure, we can demand that the new record is signed by two, three or even four managers.
If there are not enough affirmative answers, the request is considered erroneous and informs the node.
The node will use the Hash of this new record as TimeStamp. We can create a variable:
TimeStamp : i64
This data could be stored as evidence in any other data: other SD, in chunks of data, safecoin transfers, etc, etc,…
What happens if your timestamp order set to 60 seconds fails?
What happens when someone issues millions of such orders?
Than it fails, just like a PUT could fail when there’s an error in the connection between the 32 nodes. You’ll just try again with a different timestamp.
Misbehavior is not allowed in a close group. If you spam the other 31 nodes with thousands of Safecoin transactions a second they’ll kick you out as well.
In this solution nothing prevents someone to create a set of such records in advance and use them later to backdate some documents. The data and its date must be validated together, by the same group, managing the same request.
If there’s a possibility of this happening, then the next question is how significant that possibility is and the worst case scenario (say, having 2 messages fail means 179 seconds becomes the maximum precision one can rely on).
If your app has to timestamp something, it’s important that it can give it the correct stamp, not that it ultimately can obtain one.
We have had times drift a minute or so when there have been unusual connectivity issues with NTP servers. However, even then it was nowhere near 10 minutes out.
Modern computers are surprisingly poor at keeping time compared to, say, a quartz watch, mind. However, connectivity with the internet has largely nullified any issues in this regard.
I think this will be a fine solution for the sort of time resolution needed. Nice!
You’re looking at a worst case scenario. Look at Bitcoin. If your node sent out a transaction it will be at over 80% of the nodes under 3 seconds. And that’s sharing with the full P2P-network. In SAFE you’ll just share with some groups, for Safecoin it is like 3 groups. So 130 nodes at max. It’s could look something like this in a simplified way:
Not very different from a normal PUT, only a timestamp added. Now you give an App access to your little cat video. The App would just list the video in a youtube-like way, and there’s a timestamp included which is signed by 32 nodes, so reliable. And for a little fragment of data under 100KB this process could go quite fast, so if you post to a forum, the maximum range could be under 5 sec. I think. Some glitch in your App, your reply didn’t came through? Just try again. but I don’t think that this process will fail that much.
I don’t disagree with the use case, just feel the proposed “spread” sets reasonable expectations.
Even on Bitcoin with speedy transaction broadcasts your system clock can be several minutes fast or late, which goes to show they prefer reliability vs. speed and I think that’s a good idea.
I like the idea but I would remove your min_date and max_date in the SD and use only one timestamp saving 64 bit (Depending of the context). That timestamp alone is generated be the consensus as an average when you ask them to validate a timestamp. You ask them with the acceptable range you want and the group reject the out of range to calculate the average. The average end up to be the same for each node in the group and it is validated again each other. Now you always have almost a precise timestamp.
It’s a little more work than you propose I guess and maybe a little more overhead too. Maybe it should have a little extra cost for this.
The nodes in the group would have to send each other their own system dates to compute the average and this has to be done each time the group receives a request with a timestamp (because groups permanently change following incessant churn events). This will add a delay that will create a less precise timestamp. And above all, I don’t think David will like this complexity.
My proposal doesn’t add new communications between the nodes and may have the result you wish: If people progressively, years after years, ask for narrower and narrower ranges the network will naturally converge with a uniform UTC time.
Attaching a timestamp after the SD is signed breaks down part of the power of this proposal.
I was kinda’ thinking along these lines myself, but realized that getting a timestamp is not really the purpose here. What you’re really doing is asserting and signing a claim that your PUT is happening within a specific time/date range. If the network agrees with your claim, your SD gets stored.
By rejecting invalid claims, the network legitimizes those that it keeps, but the signature is important to later prove that the original claim wasn’t tampered with.
I’m not sure I follow you. But I propose something without thinking about the overhead even if it’s important. I don’t really like the min max range in a SD. I would just like a timestamp. That’s all.
“Attaching a timestamp after the SD is signed bla bla bla …”. Seriously who are you to determine the order it should be done?
I think it’s possible to only keep the max_date field in my proposal, because what we really need is only a proof that a document has been stored before a certain date.
That way there would be only one date remaining in SD and it could be called a timestamp. The change is minimal and is a simplification of my proposal:
But will that timestamp have a guaranteed accuracy in both directions? It’s important to be able to prove that the data was stored at a certain point in time. For example a question: “Was this file stored on the date 2015-10-19?” Then it would be insufficient to answer: “I don’t know, but it was stored before that date.”
Yes, you right. But in most cases the possibility of backdate does not matter because the timestamp function is to discover possible future changes. In fact, in many cases, it is good to reuse the same timestaping to save the payment of a new one. It is similar to using an old, but valid, certificate to sign.
To improve the design, we create the option of adding the hash of an undetermined number of data, both SD and chunks of data. To this we add the option DataHash as Vec (u8). Hence we would have:
.-Data owner (not always required)
.-Time
.-Interval
.-DataHash (optional)
In this way we can unite, if we want, data and date.
The system is flexible enough for timestamp a particular data or use it for a lot of data at once. (up to the limit of 100KB). For example could be used to timestamp the contracts signed today, data stored in a period or almost anything stored in the SAFE network. We may also timestamp, similar to Factom, chunks hash which contain other chunks hash.
For security reason I read before, if it’s going to happen, every node that will generate a time stamp should do it be randomizing within at least one minute range to prevent traceability.
Your structure is a subset of the new SD I propose (I consider that your timestamp + interval fields is the same as my min_date + max_date fields, they are only expressed differently).
This means that my proposal can do exactly what you are describing: timestamping a set of documents at once. This is done by storing the hashes of these documents in the data part of the SD.
But your proposal is more complex to implement because a new kind of object has to be developed and this object has less functionality than the new SD I propose, it is missing mainly:
a type_tag which can discriminate what is timestamped (a set of outer document hashes or an internal document with a specific structure).
a name which allows retrieving the object by an application key
I don’t see the use case for a proof that a document has been stored after a certain date.
I do see the use case for other kinds of dates (for example a creation date in a document management system or more generally a trigger date in any event system) but theses dates can be stored in the data part of the SD and is handled by apps managing a specific SD type_tag.
But I am not sure of this, and anyway the MaidSafe team may find a use case and will ultimately decide to keep min_date field or not.
@Ghaunt: If a unique timestamp is needed then the max_date field plays this role, even in the presence of min_date.
Yes, can be considered a subset because my idea, undoubtedly perfectible, is make it simpler.
Why previous_owner_keys? Why version? Is not better use one public function and not two?
Is nor better made the Timestamp SD simple and not deletable?
Simple KISS principle.