4

I still do not understand the whole side-tangle problem after reading the article by Dom. So this side-tangle starts by referencing some milestone and then grows further by adding txs which are only referencing their own sub-tangle txs.

Then it can happen that a walk (initiated by calling getTransactionsToApprove) ends up in this side-tangle (by stepping from that initial milestone from the maintangle into the sidetangle) and consequently has to validate a lot of txs. This consumes a lot of resources and results in the node freezing and getting out of sync. I can fully understand this.

So now v1.5.2 came up with a more sophisticated walk preventing this. But why doesn't the max-depth parameter already (available in versions < v1.5.2) prevent this from happening?

Can somebody explain where my reasoning fails?

  • 1
    The walk ends up on the side Tangle by landing on a transaction that "stitches" the two tangles together by picking one parent on the main Tangle and one on the side Tangle. I don't know why max-depth doesn't prevent that – Johnny Milkshakes Jul 26 '18 at 0:02
6

MAX_DEPTH prevents against malicious getTransactionsToApprove calls that give a huge depth and therefore create a large "Subtangle" to walk in.

But in this case, a user gives a normal depth (e.g. 5), so MAX_DEPTH cannot prevent this.

Assume that the current milestone is M and the side tangle has been forked off milestone M-1000. Also, assume that there is a transaction (we'll call it stitching transaction) which approves both a recent transaction of the side tangle (e.g. 1000 transactions after the last milestone) - let's call that transaction S - and the milestone M-3.

When now starting a random walk [blue] at depth 5 [M-5], it may (does not have to) end up at milestone M-3. From there, there is a certain chance that it continues walking to the stitching transaction S. As soon as this happens, the node has to validate that this transaction is indeed valid. Therefore, its both approved transactions have to be validated. Validating M-3 is simple (it's a milestone), but validating S takes a long time, since most of the side tangle [orange] needs to be validated.

The current fix prevents that such transactions S or the stitching transaction get chosen by the random walk (because the milestone approved by them is M-1000 and therefore too old).

Tangle

  • Is this the scenario you described @mihi? May I add the picture to your answer? – Zauz Jul 26 '18 at 22:29
  • @Zauz pedantic people might notice that there have to be at least two other nodes (milestones) on the path between M and M-3 (being M-1 and M-2), but apart from that it looks fine to me (perhaps you can add M-4 between M-3 and M-5 as well). Since this is stackoverflow, feel free to edit my answers with your illustrations. :) – mihi Jul 27 '18 at 20:48
  • 1
    @Zauz perhaps it is also a good idea to color the transactions of the side tangle that are not (indirectly) approved by S in a slightly different shade of yellow (to emphasize which transactions have to be validated) – mihi Jul 27 '18 at 20:51
  • Is a depth 5 random walk starting at M-5 or M-4? – Zauz Jul 27 '18 at 21:07
  • 1
    thanks @Zauz for your graphical additions!!! very illustrative! – GJEEE Aug 3 '18 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.