In the new IRI version 1.5.2, a call to getTransactionsToApprove provides a set of transactions that can be used as the trunk and branch of a new transaction.

Given that some of the returned tips barely meets the minimum Milestone depth requirement, maxdepth minus one let's say, then when it is used in a subsequent new transaction Tn, that transaction will no longer meet the minimum requirement.

Would Tn have its Milestone reference set too deep to be considered as a valid response to a subsequent getTransactionsToApprove?

Am I missing something here or is this a flaw in the new system?

  • Flaw as a software bug or as a flaw in business logic? – Come-from-Beyond Jul 29 at 8:21
  • flaw in business logic – Austin Powers Jul 29 at 9:17
  • That's not how it was supposed to be, also there is a fix for a problem looking very similar. – Come-from-Beyond Jul 29 at 10:40
  • OK - so it is an issue at the moment?? – Austin Powers Jul 29 at 10:55
  • I am not sure if you misunderstood something or I am misunderstanding you. To make it clear, when adding a transaction (which is not a milestone itself), its milestone depth will be the minimum of the two milestone depths of the approved transaction, so as long as no new milestone is issued, the new transaction is equally eligible to the old one. Of course, when a milestone is isuued, some transactions may "become too old". And when one of the tips was too old, the new tip also becomes too old. – mihi Jul 29 at 11:53

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.