Topic: [IOTA] Крипто-токен для "интернета вещей" (Internet-of-Things) - page 72. (Read 226867 times)

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.