То ли с вечера они там в фаундейшине перебрали с веществами, то ли в Белоруссии уже все спали, но Chat-for-Ban не успел, как это он
делает обычно, забанить в слэке человека, задающего неудобные вопросы, и тот таки успел задать свой вопрос. Но отдуваться пришлось другому Сергею - Попову, одному из трёх основателей Ёты, автору whitepaper. Безуспешно.
segfaultsteve [11:49 PM] .. do you have any thoughts about the DoS attack I asked about above which continually splits the tangle? The idea is to issue N conflicting transactions, no two of which the other nodes on the network can confirm, effectively splitting the tangle into N subtangles. Eventually one wins out, but everybody who submitted transactions to losing tangles would have to resubmit them, and by that time the attacker could have issued another N conflicting transactions.
The goal wouldn't be to double-spend (or N-spend), but to prevent most transactions from being confirmed.
После нескольких уточняющих вопросов Сергей Попов не нашёл ничего лучше, как
предложить челу провести эту атаку на Ёту:
Serguei Popov [3:05 AM]
well, you are welcome to try to conduct this attack
so far, I'm not convinced that it could be successful
То есть Сергей Попов не опроверг аргументы человека фактами из whitepaper, а
опять сослался на свою интуицию.
Далее подтянулся автор труда "
IOTA Transactions, Confirmation and Consensus"
https://github.com/noneymous/iota-consensus-presentation/blob/master/README.mdи совместно с тем неудобным, но пока незабаненным человеком
сформулировал атаку:
homo efficio [3:24 AM]
if the time between 'w' and '5' is long, the amount of the orphaned tx will be huge. So it needs some time to reattach all those orphaned, and in the meanwhile another 'w' will be submitted and the same resolution process will happen which leads most of the tx orphaned.
Кстати, Попов тогда ответить не смог, и обратился к помощи зала:
Serguei Popov [3:29 AM]
so let me go and get some sleep, and in a few hours CfB will come and explain why we both were wrong
но помощь не последовала, Chat-for-Ban,
как всегда, просто отмахнулся:
EDIT: далее
segfaultsteve проявил настойчивость:
segfaultsteve [3:23 PM] Can you please elaborate a bit?
Chat-for-Ban снова пытается отмахнуться:
Chat-for-Ban [10:25 PM]
> I don't understand why that would be.
Latency
но
segfaultsteve, рискуя быть забаненным, не отступает, и Chat-for-Ban начинает нехотя отвечать, логических аргументов не находит, и вынужденно прибегает к их обычному "
you are welcome to try to conduct this attack" aka "
You should run simulations":
Chat-for-Ban [10:25 PM]
> I don't understand why that would be.
Latency
segfaultsteve [11:18 PM]
If the attacker controls only one node, then I'm not sure that latency makes much of a difference. If he issues his transactions from multiple nodes, though, then it seems to me that the attack would get _more_ effective as the latency between them increases (compared to the latency between each node and other nearby nodes).
Chat-for-Ban [11:20 PM]
Latency doesn't allow to do attack, run simulations to see that
segfaultsteve [11:20 PM]
what do you mean?
Chat-for-Ban [11:20 PM]
> Are you implying that the attacker would need to be able to see the whole network? I don't understand why that would be.
segfaultsteve [11:21 PM]
Why would the attacker need to see the whole network?
Chat-for-Ban [11:21 PM]
To conduct attack apparently
segfaultsteve [11:22 PM]
I don't follow. Are you saying you've already simulated this attack and shown that it fails?
Chat-for-Ban [11:23 PM]
yes, a lot of attacks were simulated years ago
segfaultsteve [11:24 PM]
That's good to know. :slightly_smiling_face: If you have time, would you mind explaining a bit about how this attack fails?
Chat-for-Ban [11:25 PM]
the same way as https://en.wikipedia.org/wiki/Arbiter_(electronics)
segfaultsteve [11:28 PM]
Are you referring to this part?
> The probability of not having reached a stable state decreases exponentially with time after inputs have been provided.
Chat-for-Ban [11:28 PM]
Refer to them if you don't want to run simulations
> The probability of not having reached a stable state decreases exponentially with time after inputs have been provided.
It suits, but too simplified
There are a lot of whitepapers about arbiters
can't tell them all
segfaultsteve [11:30 PM]
I'm just trying to understand the analogy you're making to an arbiter. I think you're saying that the split state of the tangle is metastable, and eventually one subtangle will "win" while the other(s) will be orphaned. Is that what you're saying?
Chat-for-Ban [11:30 PM]
yes
but it's for subtangle in the past
I mean very old txs will get consensus
old txs will still be without consensus
but over time they'll get consensus too
by that time they'll be called "very old txs"
and new txs will be called "old txs"
and there will be "new txs"
segfaultsteve [11:32 PM]
> but over time they'll get consensus too
This is only possible if they don't confirm transactions that conflict with the transactions in the "winning" tangle.
Chat-for-Ban [11:33 PM]
I suspect you didn't take into account that txs can be reattached
segfaultsteve [11:35 PM]
Reattached transactions are closely related to what I'm describing. In that case, though, only the freshly submitted transaction will have any significant chance of being confirmed. The other one has already been orphaned with a very high probability, because the tangle has built up so much more weight along paths that don't confirm it.
Or were you saying that the transactions that the attack orphans can be reattached?
Chat-for-Ban [11:37 PM]
can't decipher your phrase, too hard for my little English
why only freshly?
if there are 100 txs without consensus and you conduct the attack after a while 7 will be confirmed and there will be 93 without consensus + some new txs
segfaultsteve [11:40 PM]
Ah, ok I see what you're saying now.
At that time, though, the attacker just submits another set of conflicting transactions and the process repeats. Another ~90% of transactions will again need to be resubmitted.
As long as he continues the attack, he can disrupt 90% of transaction traffic.
By submitting 100 conflicting transactions instead of 10, he could potentially split the tangle into 100 subtangles, denying service to ~99% of transactions for a brief period.
Chat-for-Ban [11:43 PM]
you assume omnipresence, right?
segfaultsteve [11:43 PM]
No, I don't think so...
Did I?
Chat-for-Ban [11:43 PM]
looks so
otherwise others will see that the txs are conflicting and won't reference most of them
you definitely assume that attackers sees _more_ than an ordinary node
segfaultsteve [11:47 PM]
He doesn't need to be anywhere near omnipresent. Nodes propagate transactions to their peers without first verifying them, right? So even if he broadcast his transactions from the same node, they would still permeate the network. Some nodes would approve one, some would approve the other, and some would attempt to approve both, see that they conflict, and approve neither.
But the attack would be more effective if he controlled multiple nodes, ideally ones that are topologically far from each other.
That still doesn't require him to be omnipresent, though, just present in a few places.
Chat-for-Ban [11:48 PM]
You should run simulations, I didn't observe such behavior despite of simulating a lot of combinations
Probably one of those counterintuitive cases
segfaultsteve [11:49 PM]
Yeah, it definitely could be. I think I'll try to code up a few simulations (with a lot of simplifying assumptions) to see what happens.
Chat-for-Ban [11:49 PM]
out of 100 conflicting txs only 13 will be referenced by others
and number of references will be bell curve (not sure, probably)
because of... unstable equilibrium
once one of the txs gets majority of references it will be prioritized further
segfaultsteve [11:51 PM]
Agreed. But this can't happen _too_ quickly or else it is likely that different nodes will choose different "winning" transactions.
For example, if attacker node A submits one of the transactions and the transaction rate is high, then A's neighbors will likely have confirmed it before they even see the conflicting transaction from node B.
If the MCMC algorithm chooses the winning transaction too quickly, then A's neighbors will end up following one winning tangle and B's neighbors will follow a different winning tangle.
Chat-for-Ban [11:54 PM]
it's cross-cluster communications
segfaultsteve [11:55 PM]
(I'm assuming the transaction rate is high enough that the time between incoming transactions is small compared to the latency between A and B.)
Chat-for-Ban [11:55 PM]
if Alice sees a conflicting txs which is confirmed as well then it's clearly from another cluster
segfaultsteve [11:56 PM]
Yeah--exactly. I think the result would be similar to economic clustering, except it would be impossible to later join the clusters.
Each cluster would have achieved near-100% consensus on a different conflicting transaction, so a new transaction that references both clusters would be invalid.
Chat-for-Ban [11:58 PM]
This leads to a simple thought: what if your scenario is possible only when adversary has 34% of power?
with 34% everything breaks
segfaultsteve [11:59 PM]
Yeah, if it's only possible in that case then I'm not worried at all.
