Timeline for Understanding getTransactionsToApprove
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 29, 2018 at 11:58 | comment | added | mihi♦ | @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) | |
| Jul 29, 2018 at 8:29 | comment | added | ralf | 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? | |
| Feb 1, 2018 at 21:39 | comment | added | mihi♦ | 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. | |
| Jan 31, 2018 at 21:59 | comment | added | ralf | 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? | |
| Jan 31, 2018 at 20:01 | history | answered | mihi♦ | CC BY-SA 3.0 |