Really exited to see the Whitepaper released! Have been waiting on this day since 2013
I must admit I have a hard time getting my head around it though. So perhaps my question is already answered in the paper and I just didn't understand it...
So the Universe is split up in X shards. Each shard is a part of the network contain transaction information, right?
Now what happens if a bad actor (Bob) sets up a lot of nodes that store, say, Shard (2) of the network and by that stores all or at least the majority of that shard.
Now Bob sends a a payment to Alice in shard (3). Alice now asks a node serving Shard (2) if that transaction is valid. But as Shard(2) is controlled by Bob, can't he return false information and thus double spend transactions over and over?
Bob has a few challenges to overcome here:
Challenge 1Bob can never be sure that he controls a shard or a set of them. He can't prevent anyone else from maintaining that shard, nor them being asked about Bob's transactions.
Say Bob constructs an Atom(x) which Alice receives. If there are any nodes that Bob doesn't control, they will also receive Atom(x), either from one of Bob's nodes, or from Alice's or someone else. Bob can't prevent these nodes from receiving it, because he has got to broadcast it to Alice somehow.
Bob later presents Atom(x') which conflicts with Atom(x). Bob can not be sure that nodes that aren't his don't have Atom(x). If they do, when they receive Atom(x') from Carol, they can inform Carol that it is not legit..with proof of Bob's previous transaction.
Challenge 2Bob will have to manipulate his commitments in order to fool Carol and anyone that may have Atom(x'). He would have to create Atom(x) to Alice first, somehow let Alice know about it without Atom(x) information leaking to the network. Later present the Atom(x') to Carol, then submit Atom(x) and the commitment information for him to "prove" Alice was first....double spending x.
Alice might also be part of the ploy.
This is quite the challenge for a number of reasons:
If Bob places Atom(x) into a commitment and makes that commitment known, he is then very likely to be asked to verify that commitment at a future time by a node he doesn't control; Such as when connecting to it, submitting Atoms to it, or when part of a Temporal Proof Provisioning with it.
If Bob doesn't verify any commitments he has submitted when asked, then the node he is connected with will not accept anything from him, nor send anything to him until he does.
If Bob creates two commitments, one which he keeps to himself containing Atom(x) for later use and another without it which he presents to the network. When he eventually presents the original, it will break his commitment sequence in the network.
Recall from the paper that a commitment references the previous one.
Say Bob creates C(2) which contains Atom(x) and keeps it to himself. To preserve his commitment sequence, C(2) contains a reference to C(1).
Bob then creates Atom(x') that is sent to Carol. He can't create C(3), because if he does, he has to reference C(2) which contains Atom(x). To preserve his commitment sequence and for it to be accepted, C(3) also has to contain a reference to C(1).
Later when Bob presents C(2) to prove the existence of Atom(x) BEFORE Atom(x'), there will then be TWO commitments from Bob that reference C(1).
The only way for that to happen is if Bobs nodes are either faulty, or he has manipulated his commitments. Nodes do not modify what they have unless there is verifiable proof that they should. Bob can not have 2 commitments that reference C(1), therefore it can not be proven that Atom(x) was first.
Challenge 3
Because Tempo operates with relative time, not absolute time, nodes stick to a "I'll keep what I've witnessed unless proven otherwise" and even then, their logical clocks still count up.
For example, say Node(A) witnessed an Atom(x') at LogicalClock(5), then it received a conflicting Atom(x) that supposedly happened before. It doesn't matter what the time stamp on those Atoms are, it will always reference its local ledger first to discover information that it can verify against. For Atom(x) to be proven to be before, then it must have in it's ledger some information about Atom(x) where the logical clock value is less than 5. If it is proven that Atom(x) was first, and is accepted by Node(A), its logical clock will still increment and it will keep a record of Atom(x').
This is where commitments come into play and why reliable gossiping is important, as a node never "takes anyones word for it".
For Node(A) to alter its ledger, accept Atom(x) and disregard Atom(x'), it must have a commitment containing Atom(x) in a Temporal Proof that it saw BEFORE Atom(x'). If, when Atom(x) is presented with commitment "proof", the node can not find the commitment hash in its ledger that should have been previously submitted, it assumes that Atom(x) was created in a faulty manner.
Because of the inability to tamper with the commitment sequence, Node(A) will not have such a commitment, otherwise it would discover Bob's scam.
The paper details that Node(A) will also contact a number of its neighbours to perform a more intense order determination. This will also fail, as none of those nodes will have any commitments in their ledgers either that match the supposed "proof".
Bob could continue to create a sequence of Atoms, TPs and commitments independently, even sniffing legit Atoms from the main-net in order to try and increase the viability of his "proof" and then submit them all in one go. It is still detectable that Bob was faulty or dishonest as no node will have any commitments from Bob since before Atom(x') and Atom(x) were created. Which indicates a high likelihood that he was not part of the main-net at that time and should have ceased processing Atoms.
The fact that he didn't stop, also suggests a fault or dishonesty.
Brilliant! Thanks a lot for your detailed reply.
The main parts I initially missed where that atoms are signed by the owner and as such if one node has a record of the atom, it is verifiable that it is ledig (I some how had a model in mind where the majority of the nodes have to agree that a transaction happened). As well as that the commitments are chained together.
Reading your reply and again the whitepaper helped a lot. Thanks!
Does a node have to keep record of its commitments (or rather the data/atoms used to build them) for ever, or can it start deleting old atom data after a given time/LogicalClock time?
