There has been a lot of discussions of the new proposal since I released the fourth part of this blog post. I have somewhat expected something like this to happen, which is the reason why I planned to have a separate part that addresses the trade offs and attack vectors.
Since all of the votes are publicly known and part of the tangle, an attacker does not have too many options to mess with the system (at least not without everybody being aware).
Attack vectors
There are essentially 3 things that an attacker can do:
Not following the heavier reality
As soon as one of the outcome of a conflict is favored and has more weight than the competing options, nodes are supposed to switch their opinion and follow the majority by attaching their next transaction to the corresponding FLC. This mechanism allows the opinions in the network to tip and the nodes to reach consensus.
An attacker node that does not follow this rule, even though he sees a different “winner” in the voting, does not help the network to tip further but he also does not really hurt the network. If one of the opinions is already heavier, then this means that the network started to tip already, which means that other honest nodes will follow this heavier opinion anyway and the attacker already lost its influence.
Not issuing any statements for a while, to later tip the weights
An attacker could also stay silent for a while and then come in later to tip the favored opinion into another direction, when it previously looked like a different opinion was winning.
This is probably one of the most dangerous attacks as it would allow the attacker to double spend. This however only works, if the attacker controls a relatively large amount of mana.
The longer he waits, the more mana will have committed to the first transaction already. If we use the “collaborative transaction issuing” (where we always include a statement of another large mana holder in the transaction) then the attacker will essentially loose control after a few seconds already.
Especially for larger payments, merchants should wait a few seconds until the amount of mana that has “liked” a transaction is large enough to make a reversal impossible (every recipient can individually decide how much “confidence” he wants to have before “accepting the payment”).
Note: If we assume that most of the mana is held by i.e. 1000 top mana holders and we would have something like 500 TPS, then most of the big mana holders will have made their statements already after just a few seconds .
Keeping conflicts undecided by keeping the opinions in balance
This point has currently created the most controversy and discussions (mostly between me and Serguei Popov) because it is the equivalent of the “splitting attack”, which is one of the most devastating attacks on the original “white paper version” of the tangle which could potentially force a very large amount of transactions to reattach once the conflict is finally resolved.
In contrast to the “original” splitting attack where preventing a decision from being made affected all transactions that attached to the conflicting transactions, here it only affects the conflicting transactions themselves because honest transactions behind a conflict are able to grow their own FLC independently (by disagreeing nodes setting the branch like flag accordingly).
I have to admit that even with mana it might in theory still be possible to keep a conflict undecided for a prolonged period of time, but it will definitely be MUCH harder than in a “Proof-of-Work” version of the tangle. Since mana is bounded, an attacker would have to very carefully manage this equilibrium. As soon as the network has tipped by more mana than what the attacker controls, he essentially looses control and is not able to tip it back anymore.
Since he does not know the local perceptions of all the other nodes it is very hard for him to “predict” when he should issue the next transactions that would tip the network into the opposing direction again (we have a lot of “natural randomness” in the system: random network delays, random solidification times, random collaborators chosen by the transaction issuers, secret network topology).
Furthermore, to get into a situation where there is some form of equilibrium between two conflicts, the attacker would have to issue both of the conflicting transactions more or less at the same time. If he waits too long with issuing the second spend, he also looses influence because too much of the honest mana will have committed to the first transaction already (similarly to the previously discussed attack).
Especially the last aspect makes me think, that this “attack vector” is not really an “attack vector”, because if a merchant sees that a customer is trying to double spend in the first 2–3 seconds, then he can just wait until the network has really tipped. If he sees that none of the two options manages to get a super majority of the votes then he can just wait with handing out the goods.
I want to give a short summary about my point of view: A conflict can only be considered to be a double spend if it is able to revert a spend that looked like it has been confirmed before. If everybody can see the double spend attempt within the first two seconds then it does not even hurt to keep this conflict undecided and we can not even call this a double spend. After all, the only effect of keeping this conflict undecided is that the funds of the attacker are essentially blocked until a decision has been made.
It is pretty much the same as sending a bitcoin transaction with too low fees, where the transaction can stay in the mempool for an undefined amount of time. If a merchant does not wait for the necessary confirmation then that is his own fault and not a problem of the protocol.
Possible solution to this “splitting attack”: I have anyway thought of ways to break these kind of balances. One option would for example be to use an “binary exponential backoff algorithm” to locally delay messages of nodes that are switching their opinion too often. This would make it much harder for an attacker to predict when other nodes would see its transactions which might be able to “break its influence” on the voting.
Outlook and open questions
I am pretty confident that the proposed voting mechanism is close to the absolute optimum (not just regarding the message overhead but also regarding the amount of existing attack vectors and its non-reliance on a fixed size committee), but I am not really sure if mana has a strong enough incentive to make nodes stay honest.
Since the all of the votes are public and out in the open, it might be possible to design a different kind of mana to weigh the votes which is closer tied to a nodes actual behavior. I have a few ideas around this but nothing is concrete enough to give specs, yet. I would really like to see some discussions and input regarding this — maybe we can design something that makes this approach even better.
