This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.
For the record, peer discovery is irrelevant to consensus in Byteball. Even if Sybiled, a node cannot select a wrong branch, by design. The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline. CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalksearch.org/topic/obyte-totally-new-consensus-algorithm-private-untraceable-payments-1608859.
This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:
The whitepaper says:
Quote
There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.
Quote
In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.
The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).
Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:
1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.
If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch. The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues. Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.
@Tonych, thanks for clearing that up. Nothing to worry about then. Keep up the good work!
), but is there any way to see in 
