`iter_used_addresses` could be snapshot-proof if it looked at balances first, then transactions

[lunfardo314]

get_inputs behaves very differently depending on stop parameter (is it provided or not). That is due to different ways how addresses are generated and iterated. For example right after snapshot that would give two different results.

Suggestion: iter_used_addresses to iterate until encounters first address with balance=0 and not spent as per were_addresses_spent_from as opposed to current criteria of first address without transactions.
In standard cases that will give wallet's total balance and would be similar to result with big enough interval of start and stop

[todofixthis]

Hey @lunfardo314 interesting idea; thanks for bringing this up!

I like the idea, but I want to take care that PyOTA's behaviour stays consistent with the JS lib. Could you post this on the iota.lib.js issue tracker first? Once that's implemented, we can loop back and update the Python lib.

[lunfardo314]

yes, I agree compatibility with JS lib is important. I'm not familiar with iota.lib.js code but I guess get_inputs is not part of core API but rather extended one. How does it relate to the JS library then?

[todofixthis]

The core/extended distinction is actually something unique to PyOTA; I think the other libraries group them together. Both sets of commands are considered as part of the IOTA API, so we try to keep them consistent between the different libraries.

---

Here's how PyOTA delineates core vs. extended:

• Core is for commands exposed directly via the IRI's RPC API (https://iota.readme.io/v1.2.0/reference).
• Extended is for commands that provide additional functionality, by extending Core commands and/or incorporating offline actions like generating signatures.

(incidentally, there's also a set of Multisig commands, and I believe all of the API libraries – including PyOTA – treat these as a separate package; I like to think that PyOTA's just ahead of the curve 😸)