I’m a big fan of both projects, but definitely more of a fan of Safenet, just due to the incredible potential it has.
I assume, maybe rightly or wrongly, that Safenet will be able to do what Factom does and pretty much all other projects in the crypto space. I am still yet to dig really deep into all the technicals of Safenet, but will try and find time to learn as much as I can over this year.
So just for an example: how would Safenet hash or store a simple document like a birth certificate that can be time stamped and not changed without leaving a trail of them changes. I understand the potential of Safenet to actually store these documents in a decentralised way which makes it hard for anyone to change without getting access to the keys / logins that created it, but will it also have some kind of blockchain system that will leave a history of unchangeable data? I read recently a DAG system will be used, so will this be how such a thing is possible or is it more involved in the datachains side, or maybe both?
Please excuse my ignorance on the subject, and if you have time please educate me.
“certificate” tempts authority?.. so, an authority could easily host a copy that they acknowledge it “genuine”.
I would expect some app will appear that helps with time stamping - but again you need a consensus about who is authority about what time it is. Some crypto signing of the time stamp then would be trivial and that document can be within SAFE.
I don’t know Factom but would encourage any links to other projects that can allow cross fertilization. Expecting a lot of that would be those other projects simply make use of SAFE’s solution for privacy and security.
Okay that’s the easy part I’d think - just transferring ownership away from you everybody would leave it unchangeable =O
Not possible to change without it being obvious would be manageable by storing it as immutable data - if someone would have changed it it would have a different address in the network.
Time stamping… Now that seems to be the tricky part to me… Since the network doesn’t know time… You’d need to include something that can’t be known earlier and won’t be provided later… Or so…
It seems factom is great for leaving an auditing trail and hashing a document so it can be proven in the future that the document is valid (like a birth certificate) and takes away the fallibility of manual human systems, or centralised computer systems that can be easily changed.
The part I struggle to understand with Factom is how that hashing a document can completely prove said document is the one that was created at a certain time without storing the whole document on the system. I suppose I need to get my head around hashing better and delve deeper into their system.
I would have thought Safenet would have some kind of internal clock? Even if it doesn’t have a blockchain that is always available to audit from the first block, surely there must be something that cycles at a set time and therefore calculable to when something was written to the system?
nope - afaik SAFE is purely event-driven - no concept of time does exist on the network
[for node aging number of relocations is counted … but for data i don’t think anything like this is in place]
Yes, the concept is that there aren’t any other documents that give that same hash. If there was another unique document that gave the same hash, that is called a collision, and that would be bad.
SAFE has an immutable data type that can be used to store a document. As others said, by storing something that could only be known at that time, you could basically timestamp the document. An easy example would be including the current Bitcoin block number and block hash along with the document (actually, probably a 6 confirmation old block).
It doesn’t have a concept of time (as in date and time) but it does understand sequences. This is by design, so as not to rely on time as far as I understand it. Much like TCP/IP, you don’t want to rely on constructs like time.
Of course, time could be represented at the application layer in some way, much like the NTP protocol/service does.
Ok, so that sounds like what Factom is kind of doing as they anchor into the bitcoin blockchain. I suppose something like Factom could be created on top of Safenet, with like you say anchoring other protocols like bitcoin to do somethings that are maybe not possible on Safenet.
So in other words Safenet itself can’t do what Factom does, but a system / application like Factom could be built on top of Safenet that is maybe equally as good or maybe better (speed and scalability in mind)?
hmhmmm with immutable data types the address on safe is the data hash and therefore except from the time part safe does pretty much exactly what factom does then by default - securing your data and making sure nobody can alter it
the time thing indeed would need to be built on top of safe … but
if you would use the chaining methodology seneca uses for his coin - inserting references to data and transfering ownership to that data to the network … e.g. you could make “one block per second/minute” … nobody could insert just references to immutable data without knowing the data itself (because the hasing is a one-way-street) and because you transfer ownership away from you nobody can change the data afterwards … so there you’d have kind of a time-lock …
of course people would only know that you really create those blocks at the times you said if they track you and once the blocks exist nobody would see when they first appeared and need to trust you to some degree …(but thats basically the same as with blockchains … you can’t be really sure the blocks that were there the moment you joined the bitcoin world were really created every 10 minutes … i wouldn’t see where this proof could come from)
The other solution is that SAFE can host a blockchain full of signatures; so, you would know ‘when’ relative to other signatures. Blockchains still are more about ownership and the sequence of change, than time but I expect it’ll become a simpler problem because of the need to link into the real world for ownership of objects and that a sum of many time services would provide reliable consensus. What’s needed that is more complex is for Government to prompt Law to understand and acknowledge these new technologies… then alsorts of real world contracts can move forward.
Those who maintain atomic clocks etc could write time stamps to the network, along with a unique hash. Others could use this to associate data with a date/time.
If the clock owners keep their salt private and/or rotating, future hashes could not be predicted. Hence, others could only declare something occurred in the present or past, but not the future.
This could be extended to use a decentralised consensus of time and it need not be perfect to begin with. Anyone could post time if people are happy to trust them.
Safenetwork can store a document but not time stamped it and Factom can do the contrary. So a solution is a dual one: Factom (to time stamp the document hash) + Safenetwork (to store the document).
All these cases can only prove that a document was issued after a certain date and generally we need a proof that it was issued before a certain date.
A time stamp is not something that is created independently and that can be reused at will for any documents. It must created with the document and both must be validated together by the network (an app is not enough).
Getting time has always been a consensus situation, ever since they decided to standardise time beyond using the sun as the source of time. And today they use a number of very accurate time pieces (in each location) to get a standard time for that location. Then they get consensus between locations. Now you can get time from GPS thanks to this consensus mechanism and be confident it is based on some standard time.
The internet has time servers which all “good” servers and PCs now use as their source of standard time and again these use consensus to validate their time and I suppose there is some mechanism that somebody checks each ntp server, even if as a hobby.
I’d suggest that we will see some form of “ntp” servers for the SAFE network since time is such an important metric that we humans need. Maybe as the network takes over the world the ntp servers will join the network and become SAFE time servers. Yes a very specific need for a server, the server has the rare source of very accurate time and provides the service.
Now then a way to time stamp is that you send the time server the hash of the document and the time server “signs” it with the current time and the “ntp” server’s ID. This then provides a “proof” that the document existed and was stamped at that time with an agreed time authority. If needed then this could be done with a number of “competing” time authorities.
Due to the cost and complexities of these time servers and their public usage then its possible to have agreement amongst the world that they are considered accurate. Non essential documents may have only one time stamp but anything that is to be legally relied on should have 3 stamps just to prove that no glitches in one server was not used to fake the time.
Of course we could use @tfa’s RFC. Hey @tfa did you consider where the node PCs get their time from? Usually from ntp servers, so in effect your RFC still links back to time servers. Even if the PC’ time is set by a human whose source is a time server via a path of secondary sources (eg radio, gps, etc)
True, you can’t really know the exact time a block was created down to the second, but you can surely nail it down to the day? Which in most cases for documents like birth certificates, house deeds, passports, etc is all you really need. It really is a very useful audit trail for a company than creates many important documents.
In my proposal there are not such dedicated time servers, at least not explicitly. I have observed that devices on internet have already an approximate correct date. This is certainly thanks to some ntp servers, but I consider them taken for granted, like IP routers and everything that make internet.
When a user wants to timestamp a document, what is proposed to a group consensus is simply a condition like: do you (= the vaults which are storing the document) agree that the current date is between T - 10mn and T + 10mn. If there isn’t a majority that agrees with this condition because some vaults in the group have a too big divergence with the correct date, then the document won’t be timestamped. If by extraordinary back luck this happens, the user has just to try with a larger interval and/or another ID (so that the document is stored in another group).
This is what I mean when I say the solution doesn’t need a complex time synchronization mechanism in the safe network.
My point though is that their (nodes) source of time can still be traced back to these ultra accurate time centres (sources).
Everyone sets their watches or clocks from say the radio who gets their time from another secondary source of accurate time and that secondary source could get its accuracy from another secondary source or even directly from one of these very accurate time centres/servers/
So my point was that even though your RFC is using the node’s internal clocks the time is still traceable back to one of these ultra accurate time centres/servers
And yes while your RFC proposed a non-complex sync mechanism, it still relies at its core on the complex ultra accurate systems, because the node’s PC time is obtained from a ntp server on the traditional web. And I suggest that as SAFE network grows the “ntp” servers (or new ones) will crop up that will sign people’s document hashes to give this time stamp even if your RFC is adopted. Simply because the legal status of these SAFE-nfs servers can be verified.
I think if we look closely, there will be more things on the nodes (or in the connection to them) than just time, that is relying on something more or less centralized.
The full power of the network will still rely on some of these things, as long as they have not been replaced with more decentralised versions.
Naturally we want to minimise the impurities, but it won’t be possible to start with a 100% pure system.
What we have problems with currently is accurate measurement, meaning that it is not trivial and thus not every node can be expected to have it, which leads to them needing to reach out to some specialised resource - the NTP servers.
But it is only right now that we have this problem. Time is something real (what is maybe not always so “real” is our measurement of it), and it is a fundamental part of our societies. To ignore it today simply because of this current lack of technology penetration seems short sighted.
tfa’s proposal is something I see great value in.
I think it is realistic to assume (especially if you believe in the network) that eventually the centralised nature of time measurement will transition to being decentralised.
Humans will need timestamping of data regardless of how perfect or imperfect it is with regards to decentralisation. I think the network should look to that, rather than limiting itself to the current lack in technology penetration.
Because the timestamping has to go along with the persisting of the data, and persisting is what the network does.
Definitely not. I was adding another dimension to issue.
The RFC is not without issues either unfortunately
providing time at the section level then enables sloppy core programming which is bad for protocols. People will call for time related events to be built in to the core. (more stateful information to keep)
Eventually (maybe as little as six months) we will see these accurate time servers for SAFE. Its just an program running on the machine to do the work. Or maybe even a more cleaver APP that accesses these servers (or ntp servers) to do the signing.
the only real use case has been time stamp of documents. Honestly how much is this going to be needed as the system is in its early stages. Your own computer’s time will suffice initially for 99.9% of the time while the network is in its 1st or 2nd year.
So to build in a feature that will have issues (on a conceptual level) which will be overtaken by more accurate/better simple systems is short sighted in itself.
The system can be implemented at the APP level and since we can deterministically prove that a particular APP does not change then once someone develops a time APP that can sign hashes then as long as it is trusted then it can be used to time sign documents etc.
All the needs humans have for time can be implemented with an trusted APP. The sections do not need it.
Now this does not mean I am totally against the idea in the RFC, just that it only solves a short term issue and creates its own problem when implemented in the core code.
- securing your data and making sure nobody can alter it