Topic: IOTA - page 740. (Read 1473405 times)
That's quite a significant change to the design, which should be carefully thought over.
Indeed. The algorithm works good, now I'm running simulations with slightly different formulas trying to find not so computationally intensive one (without exp and log).
P.S. Probably, that means that the cumulative weights shouldn't be used to decide which tx is legit (at least for "not very old" transactions). Instead, just run the tip selection algorithm and see which of the two tx's it approves.
That's quite a significant change to the design, which should be carefully thought over. 
P.S. Probably, that means that the cumulative weights shouldn't be used to decide which tx is legit (at least for "not very old" transactions). Instead, just run the tip selection algorithm and see which of the two tx's it approves.
P.P.S. Sure, I should have moved the red tx to the beginning of the parasite chain, but, anyhow, that probably changes nothing due to the reasons exposed above.
P.P.S. Sure, I should have moved the red tx to the beginning of the parasite chain, but, anyhow, that probably changes nothing due to the reasons exposed above.
Here: http://docdro.id/CXDq93a
Upd.: in (1), there should be exp in the sum as well (so that the transition probabilities sum to 1). Already uploaded the corrected version to docdroid.
Thanks for the update. You described an interesting tip selection algorithm. Probably it makes a lot of sense. It makes lazy tips (nice term btw) less likely to be confirmed. However those lazy tips can still be connected to the recent part of the DAG by interested parties. I'm not sure though, that we are considering exactly the same scenario.Upd.: in (1), there should be exp in the sum as well (so that the transition probabilities sum to 1). Already uploaded the corrected version to docdroid.
The first question. On fig. 1 you placed the second doublespending transaction not to the root of the parasitic subtangle but significantly higher. So the question is: is there a reason why the attacker would want to accumulate PoW not above but below the second doublespending transaction?
The second question. When the attacker reveals his parasitic subtangle, the resulting united tangle contains two contradicting transactions (the doublespends). And the second doublespend (included in the parasitic subtangle) has much more PoW confirming it. So is it just a matter of tip selection? Or should the first doublespend and all transactions depending on it be excluded from the DAG at this point?
P.S. "Excluded from the DAG" isn't the right phrase. I meant shouldn't they be excluded from candidates for confirmation, because they confirm the less confirmed doublespend?
I think there is no way to prevent the attacker to publish a parasite chain that contains a double-spend that, at the moment, has more PoW in it than the legit tx. The idea is that the nodes won't select the attacker's tips, so his double-spend will eventually fall to limbo (and the legit tx will continue to gain weight), even if it had initially more cumulative weight. For that exact reason, the nodes won't use the rule "confirm the more confirmed double-spend", it's rather "the tip that I found first has the priority".
Hope that answers all questions
Here: http://docdro.id/CXDq93a
Upd.: in (1), there should be exp in the sum as well (so that the transition probabilities sum to 1). Already uploaded the corrected version to docdroid.
Thanks for the update. You described an interesting tip selection algorithm. Probably it makes a lot of sense. It makes lazy tips (nice term btw) less likely to be confirmed. However those lazy tips can still be connected to the recent part of the DAG by interested parties. I'm not sure though, that we are considering exactly the same scenario.Upd.: in (1), there should be exp in the sum as well (so that the transition probabilities sum to 1). Already uploaded the corrected version to docdroid.
The first question. On fig. 1 you placed the second doublespending transaction not to the root of the parasitic subtangle but significantly higher. So the question is: is there a reason why the attacker would want to accumulate PoW not above but below the second doublespending transaction?
The second question. When the attacker reveals his parasitic subtangle, the resulting united tangle contains two contradicting transactions (the doublespends). And the second doublespend (included in the parasitic subtangle) has much more PoW confirming it. So is it just a matter of tip selection? Or should the first doublespend and all transactions depending on it be excluded from the DAG at this point?
P.S. "Excluded from the DAG" isn't the right phrase. I meant shouldn't they be excluded from candidates for confirmation, because they confirm the less confirmed doublespend?
I can assure every interested party that anyone that follows IOTA either in this thread, the newsletter or www.twitter.com/iotatoken will be notified in due time and not miss out a single thing.
ICO is expected? Or what options will be available to early-stage investment?
Yes ICO.
?OMG don't start with this.
ICO is expected? Or what options will be available to early-stage investment?
Yes ICO.
When?
when?
? ICO is expected? Or what options will be available to early-stage investment?
Yes ICO.
When?
ICO is expected? Or what options will be available to early-stage investment?
Yes ICO.
Here: http://docdro.id/CXDq93a
Upd.: in (1), there should be exp in the sum as well (so that the transition probabilities sum to 1). Already uploaded the corrected version to docdroid.
Upd.: in (1), there should be exp in the sum as well (so that the transition probabilities sum to 1). Already uploaded the corrected version to docdroid.
So that's what I asked. Is there a fix already?
Yes, the fix is done, we were just discussing another issue weren't we?
If it's fixed, may we see an updated whitepaer?
Eclipse attack is irrelevant to this scenario. The attacker only needs to delay publishing some of his transactions.
I thought we were talking about the standard case of a non-delayed transaction issued by an up-to-date node. If you do delay a transaction then the picture has the same profile as one with an eclipse attack.
Well, the issue was improbability of your picture because it had a sign of successfully conducted eclipse attack (if the transaction was published), that case was not what we were talking about. The discrepancy between the words and the picture made me argue, otherwise someone digging deeper would be confused.
Updating whitepaper is not that simple as typing few words, it will take some time.
Eclipse attack is irrelevant to this scenario. The attacker only needs to delay publishing some of his transactions. Updating whitepaper is not that simple as typing few words, it will take some time.
That is the same issue, which I beleive, mthcl and you admitted to exist.
If it's fixed, may we see an updated whitepaer?
If it's fixed, may we see an updated whitepaer?
Well, the issue was improbability of your picture because it had a sign of successfully conducted eclipse attack (if the transaction was published), that case was not what we were talking about. The discrepancy between the words and the picture made me argue, otherwise someone digging deeper would be confused.
Updating whitepaper is not that simple as typing few words, it will take some time.
So that's what I asked. Is there a fix already?
Yes, the fix is done, we were just discussing another issue weren't we?
If it's fixed, may we see an updated whitepaer?
So that's what I asked. Is there a fix already?
Yes, the fix is done, we were just discussing another issue weren't we?
You claim that your design allows mergers of split subtangles. The merchant sees something like that. Your algo, described in the whitepaper, shows good confirmation score. Do you want merchants to analyze the DAG manually?
No, of course. The software will do that.
Jump to: