2

The official docs for getTransactionsToApprove state

The higher your depth value, the more "babysitting" you do for the network (as you have to confirm more transactions).

I don’t exactly understand why a greater depth forces me to confirm more transactions. Am I not suppose to always confirm just two transactions?

Or is this a matter of not-so-precise language? Does “you” in the above quote refer to the node, as the node, when requested for tx to approve has to validate every tx it passes while traversing the tangle?

Related question: While we are having the COO, will this always return one milestone TX and one “normal” TX?

Improve this question

2 Answers 2

Reset to default
1

You are supposed to confirm 2 transactions directly (and one of them being the latest milestone), but you confirm more transactions indirectly.

The depth parameter impact the starting point of the random walk to select the other transaction. This starting point will be an older milestone, the depth determine how old this older milestone should be. (As far as I understand the code the index of the old milestone will be index_of_latest_milestone -depth - 1 ).

Note that by default the depth is maximum 15 (but it can be configured through the MAX_DEPTH parameter)

Improve this answer
3
  • Clear but I didn't understand "(and one of them being the latest milestone)"
    – blockmined
    Commented Jan 31, 2018 at 15:37
  • When you look at the code, you see that one of the 2 tips selected (when you call getTransactionToApprove) is the latest milestone
    – ben75
    Commented Jan 31, 2018 at 15:39
  • Ben, thanks for taking the time (again). My issue might be purely semantical in nature. The docs say "as you have to confirm more transactions" as if this would mean "more work" or "more intensive computing" for the node. If I understand you correctly, this is not what is happening. If I select a higher depth, it will require slightly more compute power, because the random walk will be longer. However, I will still just confirm exactly two transactions. The the amount of compute power for the actual confirmation is exactly the same. Is this correct?
    – ralf
    Commented Jan 31, 2018 at 15:47
0

You will always approve two transactions. The node will have to search these two transactions, and when it starts to search deeper, it will have to validate more transactions on the way (and your transaction will indirectly confirm more unconfirmed transactions). The PoW for you will always be the same (only depending on the number of transactions your own bundle has).

The current algorithm will start tip selection once from an older milestone (depending on depth) and once from the latest milestone. If there is no other transaction from the latest milestone (or only inconsistent ones), one of the returned tips will be the latest milestone, otherwise it can be a more recent transaction attached to the latest milestone. The second tip will be most likely not a milestone: when you start walking from an old milestone, the node you end up can never be an older milestone than the current one (as you could always walk from that one to the latest milestone without causing conflicts), and the probability you get a different transaction here is quite high.

So, the chance of getting 2 milestones is pretty slim (although I have seen it on testnets consisting of almost only milestones), the most likely case being 2 non-milestones on an active tangle and one milestone (the latest one) on a less active tangle (where there are no more recent transactions).

You can, however, be sure that at least one of your tips will confirm the latest milestone (and the other probably not; making the probability higher when you use a higher depth).

Improve this answer
4
  • Excellent as always, @mihi. One more question: A snapshot wipes all transactions and creates a new milestone. So there will be a short period of time, where there is exactly one milestone. Is that correct? How does the algo work then?
    – ralf
    Commented Jan 31, 2018 at 21:59
  • More generally speaking, if your depth is higher than the amount of available milestones, the second tip selection will start at the initial milestone. If there is only one milestone, both walks start from there. In case there are no other transactions to walk to (yet), getTransactionsToApprove will return the initial milestone twice.
    – mihi ♦
    Commented Feb 1, 2018 at 21:39
  • Revisiting this, @mihi, I’d like to add that in my understanding at the time I probably confused approve and validate. Just to confirm: During the random walk, IRI validated each transaction it walks by, is that correct? Does that mean for each transaction along the walk it checks whether it’s solid and valid?
    – ralf
    Commented Jul 29, 2018 at 8:29
  • @ralf There is some caching involved, but yes, during the walk, IRI has to make sure each transaction is solid and valid (and consistent with the latest known solid snapshot)
    – mihi ♦
    Commented Jul 29, 2018 at 11:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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