You seem to be asking how double spend is prevented. An NRS name is not much different from Safecoin in this respect, although the latter is no longer a piece of data in the same way. Different mechanisms will now be at work for each, but the issue is the same.
There’s no issue with data propagating between sections. It is only the section controlling the data you are trying to update (that which controls the NRS name) which matters.
There’s no concept of different sections believing different things about a piece of data (NRS name or Safecoin balance). Only the section controlling that data knows its state, and if someone asks to update it, it doesn’t matter which section they are connected to, only the section controlling the data matters - and any request to update or access that data will be handled by the section controlling it.
Likening the creation of a SAFE site to initiating a Safecoin transaction really helps to clarify this, thank you! At its core it is the same double spend problem. As I understand it now, if it can be (or has been) solved for one, it can be (has been) solved for the other.
Yes all that is true BUT - and sorry I keep coming back to this- for some period of time a section will believe that safe://fluffykittens resolves to Whiskers, not Tibbles because a sufficient number of its members honestly believe (due to lag) that was the correct decision. And from here it may not be impossible that several sections could be persuaded otherwise.
Now eventually - and probably within a few seconds TBH, that situation will resolve itself. But we still have this period in which confusion is possible. Could this , by extension, also apply to double-spending? And could this theoretically be gamed? My gut feeling is No but gut feelings are not good enough.
I think this might be a question of how is ordering managed in the absence of time. Whether this is something that PARSEC manages or CRDT or something else, I too am unsure of the answer to that…
We know CRDT is faster, lighter than full-fat PARSEC and is “good enough” for certain operations.
Maybe it would help if we could get a table of network operations versus the minimum acceptable level of consensus mechanism required?
My (possibly flawed) understanding of NRS resolution:
See:
I don’t believe this is the case and I don’t understand why you think it is. Sorry I can’t bridge the gap!
OK lets put it in Cheltenham terms.
You have a tenner on Potential Dog Food at 150/1 in the 3:30.
I call you from the track “Potential Dog Food has just won by a nose!!! Result!! Get the beer in!” You rush out and buy a large cargo of the finest warm English beer.
Then… The official result is announced, turns out Glue In Waiting, the favourite is actually confirmed as winner once the stewards have looked at the photo.
What do we do with all that beer? Cos Ladbrokes is just going to laugh when you go in collect at the bookies with your line saying you backed the wrong horse. Cos Ladbrokes are going to believe the stewards, not your pal @southside, even though you know I have never lied to you before and have always told you in good faith what I think I saw and have no reason to disbelieve me. And you are skint - and its not my fault cos I told you what I honestly believed.
CRDT is not only eventual consistency it is strong consistency. The order is strongly consistent. When you update a data item then it’s certain only 1 update will exist. That is true regardless of length of time to get to consensus. (think more causal order and group consensus giving the authority here, so unlike at2 consensus == 1, we use casual order == consensus 1 but network agreed needs group consensus. i.e. Order is correct and follows business logic, then network agreement happens)
Now if you have dns like pointers to direct a url to content and another did the same than that’s also OK.
Unless I am missing your point here?
@drehb answered concisely above.
Like Maxwell originally, I am interested in what happens right at the start - before the current and voltage settle. Is it feasible that for a short period of time one sections view of what the NRS should be could be wrong, due to messages arriving - in that section - out of order due to lag? And how is that resolved? Does the owner of the second site to register the NRS link think it worked but then failed?
I know it sorts itself out eventually - but what happens before “eventually”?
No, the messages if section secured will have an identifier of the version (not really a version) they know, if it lags then they error back to get an updated view of the more re tn version. The trick here is crypto linked lists, so we can see we are behind and be sent signed updates we trust.