RFC for timestamping in SAFE

You have not lived in the middle East much I think :slight_smile: Same can be said of slavery, world wars, genocide, populations controls etc. I do’t see that as an argument.

I am not and have not said time is not important for humans, it’s a different aspect.

It may be very secure or it may not. In terms of the thought behind it I think @tfa is onto something pretty big here and it may prove to be dramatically good. It’s a huge subject though and I am trying to show that. It’s not a refusal, but a request to appreciate how much of a huge area this is. This RFC with some further debate may provide something amazing. At the moment the dev team are pushing fast and I feel this needs a few weeks of solid debate and discussion with many people who have been involved in this thinking.

It’s been a long term discussion in maidsafe to look at a globally agreed tick of some form and this may be pivotal thinking to get us there. So thanks to @tfa so far, no refusal, rejection or negative view. We just need to really dive in and it’s a bigger issue than many may realise. That’s all.

7 Likes

That would be centralized solutions. Or some complicated decentralized app. To be able to use the already existing distributed security in the SAFE network to generate secure timestamps is extremely powerful. And very easy to implement and essentially zero performance change in terms of computation.

Lol did you not hear a thing Mr Irvine just said

I’m puzzled about the hesitation to implement the timestamp. Looks like a good solution to me, and it’s hardly possible to come up with something simpler or more efficient performance-wise.

The just if it that I got was that it’s too much details to shove down into the networking layer.

If you put things in there without thinking deeply, you can screw up the whole foundations of the SAFE Network, even if you have good intentions.

The network layer has to be as simple and totally precise as possible

But by all means, feel free to build anything (an app that pays people SafeCoin for correctly stamping people’s data with the correct time maybe?) in the APPLICATION layer, because changes there won’t endanger the whole network

tl;dr don’t purpose changes in the SAFE core networking layer unless you totally have a deep understanding of how it works

That I totally agree with. Optimally it should be a version 1.0 that remains unchanged, kind of like IPv4. And then more functionality is added in the application layer.

1 Like

Exactly :slight_smile:

It would be a great idea for a SAFE App tho!

SAFEtimestamp lol

People submit their data to it and it uses decentralized consensus of many groups of nodes to properly timestamp people’s data for a small SafeCoin fee

Would be an easy app to make!

But let’s leave the core networking to the experts

1 Like

Of course, an application can manage dates and there will be plenty of them that will be doing this. The problem is that these dates cannot be proved. Generally this is not a problem because the consequences of a forged date are benign (for example the date of a post in a forum application).

But the RFC is about a date that cannot be faked at all (for example to prove the anteriority of a sketch that someone has designed). In order to do this, the date must be validated by the consensus of the safe network, namely by at least 28 nodes of a group of 32 chosen randomly in the whole network.

Trying to do this at the application level is not enough:

  • At worst, the date is generated by one instance of the application running on the client, and it would be easy to backdate a document.
  • At best, there is set of instances running permanently that controls each other. The problem is that there will be a lot less nodes in this sub-network than the whole network and I doubt people will be confident in the “proofs” generated by this sub-network because an attack would be easier on it.

Without the RFC or something equivalent implemented in the core network, the safest option for a decentralized proof of date would be to store a hash of the document in the bitcoin blockchain. And yes, an application could do that, but that doesn’t satisfy me.

For that I’m OK with… It’s just, it is going to be possible? I mean I don’t know how the app level will work. It is going to have access to a libraries with such functions that ask something with consensus? Later we will be able to access CPU at a cost from other nodes. For that it need a secure library and private secure script to do so. If we can’t access at least the node time within a random range and do a custom consensus script it’s not going to be feasible. But that possibility can be added any time later.

No dude, just get your app to get consensus from like a minimum of 10 groups of nodes or something.

Or charge more SafeCoin to verify with 100 groups, etc.

No reason it can’t be very easy like that

??

You would have to first identify where the nodes are in XOR space (impossible), then in geographical space (impossible), then steal / compromise all of them (extremely difficult).

I think this has about 0% chance of actually being a problem IMHO so no worries there

Just a couple of thoughts on that

Didn’t the blockchain technology solve this?

Safe allows versioned SD types. You can also make a simple chain with these. Maybe something there.

ntc servers work above the networking protocol layers and the world trusts them now.

protocol layer is hindered by times, best if time is not introduced at the low levels protocol layers.

So how can the provability be solved while not requiring (really a huge) change to the protocol layers.

Could the network introduce a layer above the protocol layers (yea I know it becomes a new protocol :slight_smile: ) that allows for “supervisory” querying of the group which can create a SD for you. For a start the first function is a “timestamp” query that includes the parameters you suggested and returns the address of the SD created for you.

Of course this “supervisory” layer would only allow access to information that does not compromise security.

So this way time is not in the protocol (even this new high level layer) layers but is a new aspect of the s/w for nodes that make up groups., Technically its not part of any protocol and the new (side) layer is simply a way to request information from the group to be stored in an SD (with parameters sent to it)

Of course I can see ways to fool the system so that I can claim a contract existed on such n such a date and show the timestamped hashes to prove it, but the contract legally did not exist till a later date. So even though electronically the time stamp proves one thing, I cannot used it to prove legally another. Thus is it such a problem to use an APP that can gain reputation as reliable which also can provide much more functionally to the time stamp than could ever be in a protocol layer function. The APP could then also provide the legal guarantee by for instance prove both parties were present and witnessed by 2 third parties as is required by many legally binding contracts.

1 Like

Yes, then it makes sense to not include the timestamp in the SAFE network. It’s better to implement the timestamp on top of the “file system” core. A secure timestamp belongs on the level of computation, not in the file system itself. Heck, Maidsafe should even develop a SAFE OS on top of the SAFE network and that has probably already been discussed in other threads. But I don’t mean a local OS. Instead it should be a distributed OS, where the ability to buy CPU power is included.

Hmm… Actually, neither does safecoin belong to the file system level. A bit off topic: is safecoin included in the core instead of added on top because it’s so integrated with the file functionality? Or, more on topic: Why is the timestamp removed from the core while safecoin is in the core? That’s still puzzling to me.

The solution is store the hash of data and date at same time sending this information to the “supervisory”, encrypted if necessary. The content of the SD data can be the hash of data or hash of immutable data (chunks) as factom style.

But an App using chained hash and public data can do the same and offer legal guarantee. Can be a successful App.

2 Likes