Any time consensus within SAFEnet?

No blockchain, that’s great. Safecoin transactions within a second, just like digital cash with a crypto sign from the last owner. But what about time in the network? Let’s say someone creates some sort of youtube on the network. Everybody can upload movies to this “SAFEtube” but how do we know which movie was uploaded at what time? I think it would be great to know that! And what about a search-engine in the network? It would be great to search all the SAFEsites which where online in 2015 when you live in 2016. But how on earth does the network know which time it is? I have a little idea, don’t know if it will work.

let’s use the time from the Bitcoin blockchain. No, I not propose to build a blockchain into the SAFEcode, but what about nodes running the blockchain and BTC-software on their SAFEdrive? Instead of storing the BTC blockchain somewhere in a map called “Appdata/roaming” a number of users will just run the client inside their SAFEdrive and even if 1000 people do this, the blockchain only needs to be stored “live” like 4 to 8 times, just like all the other chunks. It wouldn’t surprise me if the Ethereum folks would one day create a little bridge between Ethereum and Maidsafe so people can use the same log on, PIN etc. for both systems. Ethereum will have so many contract etc. running on their blockchain, it’s gonna be very big in a couple of years. Maybe external blockchains are a good idea for SAFE, or maybe not! But there’s no way to prevent other systems using SAFEnet to do this.

Here are some problems with that idea:

  1. A 100 GB blockchain in SAFEnet stored by 10.000 users should be no problem for the network due to de-duplication. For users on the other hand, their software needs to “scan” the blocks to use them. And files are only downloaded to your computer in SAFE the moment you try to open them. So this means a lot of GET-requests.
  2. If not enough people are running the Bitcoin client within SAFEnet a spinnoff from the real blockchain could occur, creating a split in the external and internal Bitcoin blochchain.

But of course there are some pro’s as well:

  1. In a Maidsafe version 2 some new managers could be added. The only thing they do is create time-consensus. They use the internal Bitcoin or Ethereum Blockchain and they look at the latest valid blocks and set networktime every 10 minutes or, with Ethereum every 12 seconds! Websites in SAFEnet just like youtube could add new videos with a time-stamp derived from these managers.
  2. It would fix problems for systems like Bitcoin and all the other Blockchain based crypto’s. No longer the need for 8000 nodes to store GB’s worth of data. SAFEnet would even become more used by the crypto community this way. It would be a great combination of 2 technologies without the need to build a blockchain in SAFEnet at all.

Let me know what you think about this idea.

3 Likes

Would it impact privacy or help enable DRM type schemes? DRM and privacy seem completely incompatible to me, and systems of progressive waiver anathema. Really hoping SAFE enables end user to pay if they like, and only what they want, with absolutely no pressure not even a convention or culture of suggested prices.

On the plus side would it help stuff like real time gaming or MMO?

No not really. I think @polpolrene just wants a timestamps to indicate when files first appeared on the network.

2 Likes

That’s right, and for things like a forum inside SAFEnet. Take a forum like this one, imagine how it would work without the time aspect? Topic number 112, and subreply number 0000002? When was the topic created? Today? A week ago? 2 years ago??

This is from the patent, but doesn’t mention any Master Clock source:

According to a related aspect of this invention, a system of perpetual data, self encrypting files and data mapping will allow a global anonymous backup and restore system for data to exist. This system can be constructed from the previous discussions where data may be made perpetual on a network and anonymously shared to prevent duplication. This together with the ability to check, manipulate and maintain revision control over files adds the capability of a ‘time machine’ type environment where data may be time stamped on backup.

This allows a system to rebuild a user’s data set as it was at any time in history since using maidsafe.net or similar technologies. This may form a defence at times where in cases like prior art enquiries, insider dealing etc. is being considered, as the system is secure and validated by many other nodes etc. It can therefore be shown what knowledge (at least from the point of view of owning the data pertaining to a subject,) anyone had of certain circumstances.

1 Like

@dirvine mentioned that the Maidsafe preference is for things to be event driven.

But if the network preserves the relationships between events, so long as some of those events have hard times associated with them, such as a blockchain, it should be relatively easy to calculate the actual time of each event.

Of course, what we are really talking about is PRIORITY. If the relationships between events are preserved, then what do we care about the specific time of things. All that we care about is being able to prove that “File A was posted prior to File B.”

2 Likes

Yes that’s the comment I remembered…nice catch.

What about legal systems, Land Titles etc…I would think there would be a bunch of stuff that requires a fix to GMT.

I’m not sure what you mean by “legal systems” but at least in Land Titles, again all that matters is priority, that is the relationship between different events, not a timestamp as such.

Now to the extent that you needed to show priority between events which took place within the system and events which are outside the system (such as proving a legal title in court) a timestamp may be needed. But at that point you are interacting with an external and unsecure system.

I think for things like that then it’s handled at the human end of the network. So you sell me a house and we sign and store the deed, but the deed has a time we agree this happened at and that is what is signed. So there is a time element there.

Even better though if the deed is signed by the current owner then it can be treated like a safecoin, sort of, it can be held at a version manager (each hash is a version and the version managers keep these like mini blockchain devices) and then you have a history of the deed that is linear so A -> B -> C versions and each holds the date the change was made. So the network provides the order of the deeds and humans agree the time. If there is a weirdness then it can be spotted, but the weirdness will be humans putting the wrong time (which can happen I suppose)

From our perspective though we just give the version history of every file on the network (happens at the directory level), then it’s up to people to have them private or public. I think there will be many public shares where things like contracts and agreements can be kept and many people will copy these public shares. Regardless the data is there for ever so should prevent rewriting history.

4 Likes

It would be good to have a global clock on SAFEnet for calendar time. Let’s say that I want some data to be visible only for 24 hours. Having to rely on local computer clocks seems shaky and a potential risk for fraudulent time manipulations.

2 Likes

The GPS system may be something that can be utilised for global time.

1 Like

If I were to make SAFEforum, I would probably be storing the forum data in publicly shared storage.

Since I’m the one doing all the storing, I get to append any data I want to the record. I’ll look up my local time, convert it to GMT, and timestamp every post with that time. I imagine most applications could similarly just have the application itself add the timestamp.

Would it be possible to generate a global calendar timestamp in the SAFE network by taking the median value from the system clocks of a large number of nodes?

The core functionality can produce timestamps say every 10 minutes. And have a calendar API with a method for getting the latest timestamp and another method that allows apps to tag files with the most recent timestamp.

This would I think (well, I haven’t thought this through yet) allow “blockchain-like” entries on the SAFE network. Each timestamp can be used as a proof for when a file was stored.

And apps can use the calendar API to ensure that the local clock in the client is at least correct within a 10 minutes error margin (or whatever time interval is used for the timestamps).

And to prevent nodes from being hacked the calendar functionality can be distributed among several nodes. Maybe easier said than done, but it could be that the SAFE network already has similar security functionality that can be used. It should be impossible to hack a single node to produce fake timestamps.

3 Likes

The problem is that maintaining a global time across the network adds another complex layer in the core.

A much simpler solution which would need a minimal modification of the core is to add the following fields in StructuredData:

  • min_date: i64 (default value 0)
  • max_date: i64 (default value std::i64::MAX)

The i64 type represents the sec part of a struct Timespec generated from an UTC time (a number of seconds since the beginning of the epoch). Each nodes in the data manager group handling a data put would check that its own current UTC time is > min_date and < max_date. This is a little modification in the validation procedure.

If someone wants a proof of an approximate date for storage of data, then these 2 fields must be filled with the current date minus a margin for the min_date and plus the same or another margin for the max_date. The margins are added to take into account the variability of the vault times.

In most cases user don’t want a precise dating, so a 10 mn or even a 1 hour margin is sufficient and so there is no need to synchronize the nodes. A put to succeed only needs 28/32 nodes having a time within the margins. If the put is unsuccessful, the user can try again with:

  • higher margins
  • another name so that another group will handle the request (with more precise nodes maybe)
  • min_date set to 0 because only a max_date is needed most of the times (to prove that we stored a file before a date).

Some more remarks:

  • The default values insure that the check on the date is always successful when user don’t want dating (which is the current situation).
  • To be sure that the dates are updated whenever the data is modified, the check has to be done every time that the SD is updated (put and post requests)
  • The simplicity of this solution lies in the absence of time synchronization implemented by the safe network
3 Likes

Late reply, but this thread was just brought into my attention.

How about forming chains of signatures?

If I want my data to have a timestamp, I just make a signature for it and I throw it in the pool.

The problem is, I could put any date on it. So, to prove that I’m really after a given point in time, I add a couple of existing signatures from earlier (but recent) points in time. By this, I’m also proving that those other signatures were before mine. And so it goes on, with signatures forming a complex directed graph, where the more you go back in time the more proof accumulates to confine a given signature within a given time period.

Well of course not all signers are born equal, which needs to be taken into account when computing the validity of a signature. But this system already deals with similar issues, so I guess it can’t be too hard to expose a value for that in the API.

I know, it looks all too similar to that damned b****ch**n with its unholy Merkle trees and all; forgive me for that.

1 Like

Time🐜If one would want to timestamp media uploads one could tag the completion against
a verifiable hash of one or more trusted timeservers . I imagine that would do the job well .
Please , correct me if I am wrong🐜

1 Like

Yea! One of the ideas of SAFE by the way is that trust is not something static; one can earn it and lose it. How much a timestamp is trusted could depend on how dependable the issuing server (e.g. a vault) is.

The complexity about it lies in proving your timestamp is from when it claims it is from (give me a file, I’ll give you a signature it’s from June 12, 4130, no sweat.) To counter that, we could “freeze” a given timestamp between other similar timestamps, using not only the trust behind its own signers, but also behind the signers of the connected timestamps. The signed timestamps form an acyclic directed graph; the denser it is, the harder it becomes to fake a timestamp.

3 Likes