Maybe if the app could receive timestamps from several users somehow.
1 Like
It would use the clock on the machine the owner/admin is using.
Ah! Thatās pretty clever. It will be good enough for basic dates like on forum apps and SAFEpress. But will the admin app be able to replace the server functionality? Or does the admin have to manually check the timestamps?
Either is possible.
Blah
My proposal doesnāt need ntp servers because we donāt need a sub-second accuracy. To compete with the bitcoin blockchain we only need a ten minute accuracy and a large enough majority of devices currently connected to internet have already a much better accuracy than that, and this is true for all ranges of devices, from the biggest servers to the smallest smartphones.
Also I didnāt add time crate. It is already heavily used in routing. And my usage is much more inoffensive and is not part of the management algorithm: itās only an optional data that is valid or not, exactly like the previous owner signatures.
So I am very disappointed. This is a missed opportunity to add this great functionality at network launch because the effort is minimal.
Sure, this can be added later but it will have to be implemented as a new kind of object because the old standard SD will still have to be managed. And this will go against the effort you have made to unify the data structures on the network.
1 Like
Iām agreeing with @Anders and @tfa here. This is an optional timestamp and it should not be considered has a secure thing but it must be available. MaidSafe should warn that they donāt support it but it still available because it is needed. āUse it at your own riskā. SAFE Network time is more secure than local time.
@dirvine I know you donāt like it, it will not break your current design. But what you prefer? We use local time or the SAFE Network time?
I think Mr Irvine is saying that we can only have 100% secure access under certain conditions, when all the code works together perfectly in harmony with all the other parts,
And this throws things off internally and compromises security and anonymity in certain ways
Actually why could not the stamping be logged in an available data base. Thus the āproofā of its timestamp is available to whomever the datamap is available to (public/private if you wish). The entries are keyed with a hash so the tracing of particular documents through their steps of stamping cannot be tracked. Users pay the APP to do the stamping.
This way it does not have to be part of the core, but above in an APP. The only issue then is for the APP to obtain a reasonable value for the time.
This was my thought too. The proposal seems very easy to implement. But there is a security risk. I was thinking that the timestamp would be secure. But if many people running nodes start to mess with their local clocks, they can launch a kind of āglobal clock changeā attack. Maybe the risk in practice is very small, but if it happens it could have devastating consequences for financial and medical services etc who rely on 100% reliable timestamps.
EDIT: On a third thought, a global attack would fail, because the client sets the original date. From the RFC:
"To maximize the chances that its request is valid the client can give a very large range
like current date Ā± one hour. This is not a problem because most of the times
people donāt need a precise dating.
If it really needs a precise dating, the client can also try different names for the SD
until it is handled by a group with a majority of more precise nodes (28/32 consensus majority)."
Then what about other risks? What if governments start to mess with time servers? And thereby making the client clocks in an entire country go wrong. Thatās an insignificant risk, because the whole society is dependent on such time servers.
So my recommendation now is: Implement the secure timestamp already in the first version of the SAFE network.
You guys need to keep in mind that they are still only working towards a first implementation of the network. This first implementation will be far from finished, so not including this timestamp in first version does not mean it would have to be delayed beyond launch.
You see, the launch is still far away, probably in 2016. Once the current sprint finishes testnet1 starts if all goes wellā¦
The release version 1.0 should include a secure timestamp I think. Because I believe it will be difficult to upgrade the network after release. Kind of like TCP/IP but on a higher level. Itās tricky to update the TCP/IP protocol today.
How far from finished will the first implementation be? I think only the dev team knows how much more they need to do right now. And they got rid of the so called testnets.
The version number in each SD (Structured Data) element does just that AFAIK. So incrementing versions are equivalent to time if used as a sequence measure. Part of an SD update is to confirm sequence numbers are sequential, well that was the design decision to include a version number anyway to provide sequence checks. If the SD data included a signed date then we donāt mind if an app used that as another sequence or time measure.
3 Likes
Protocols generally are not recognised by timestamps. there is no IP version 1964 for instance, it is IP V4 and upgrade to IP V6. Wire protocols generally use a single byte or even nibble to identify versions, as do some crypto algorithms. A date is a big chunk of info in comparison and we donāt have a recognised time zone/format for such numbers without additional identifiers such as time zone info and all the other locale information. A sequential number is pretty much recognised and agreed to follow a sequence we know (current == last + 1 and next == current + 1). Hope that helps
2 Likes
I would hope we can come up with a recognised measure of entropy that can recognise a sequence of events. I often think of it, but keep putting it off, time is OK but do we need a click every second or is there a better way? Outside of the current scope of this RFC, but I do think there may be a measure that can be globally agreed and able to identify events accurately. Itās a really interesting area but it will need to be agreed without propagation of all nodes. At the moment nodes only ever share bits of info, they do not share any complete state and the answer is in there somewhere.
So short answer I would prefer SAFE time but not necessarily time ā¦ but ā¦ yip itās an are of interest with no clear answer and I believe no simple answer. Sorry for not being clearer here, but when I fully understand it then I will be able to explain myself better. Launch take these pleasures away for the time being 
4 Likes
Yes, but look at how difficult the IP-version transition is. Version 1.0 of the SAFE network will as an analogy be āIPv4ā and version 1.1 will be like upgrading to āIPv6ā. Very difficult when there are thousands of farmers who all need to upgrade their software.
And the secure timestamp is an excellent and easy-to-implement feature. What information system today does not use timestamps? Calendar time dictates much in society today.
I donāt see how that is easier if it were ip1964 or ipv4, the version identifier has not been the problem. The issue with IPV4 upgrade is very much economics/profit and basically a tough issue. There was not really a financial incentive to upgrade and companies etc. did not have a push to do it. Like Global Warming (ignoring the debate) then it seems hard to get stuff done when profits are not obvious. Danger is not as good a driving force than profit is, unfortunately.
SAFE Many really, IP for instance does not, there are huge numbers of systems that do not use time(stamps). In the natural world for instance only humans do AFAIK.
Maybe a way to answer this is to ask if there is a total system (complete) that cannot work without a timestamp? In answering keep in mind, is it possible to have a network with no servers? or was it? or did we just not look hard enough?
Then ask what time really is? Why do we rely on a tick and number of ticks to identify stuff.
Then look at maths and figure out where timestamps fit into stuff, say bitcoin, the ācurrency managed by mathsā, how many mathematical constructs and first principles include a timestamp in their algorithm/function?
I think this is a very deep subject and requires thinking as deep as a serverless network. Initially when I proposed and presented such a thing everyone told me, every information system needs a server [sound familiar - cheeky I know, but ā¦ hope you get the point].
3 Likes
Heej, I really like your idea, and I know a lot of others do as well. It will probably be used/implemented after launch. So itās no waste of time or anything. Keep up the good work, you really provided something good here.
2 Likes
Without the Gregorian calendar we would still be in the Dark Ages. Sure, during the dawn of our civilization people could use the sun and the seasons to plan and coordinate activities, but thatās a crude form of organizing society.
And the RFC proposes a really secure timestamp. I became worried that people could launch a āglobal clock changeā attack, but as the RFC says, the client must set the desired timestamp. So the timestamp is guaranteed by 28 out of 32 nodes and by the client. The risk of being hit by an asteroid is higher than getting a wrong timestamp. Well, at least itās a very secure timestamp. Not even governments or large corporations can attack enough local node clocks.
To paraphrase David for something that it seems you missed.
A clock is not needed for protocol use. SAFE core network is a set of protocols. Time is a negative influence for protocol use, its unneeded, only adds complexity that has no need to fill for the network.
Now I can see the need for timestamping documents for human use. And from all David has said it seems he would suggest that it lives in a layer above the network protocols. More like an Application that can do the secure stamping or some layer that is introduced above the network protocols.
Hope this helps you understand where David is coming from.
2 Likes