Open todofixthis opened 5 years ago
Related: #175
I was facing the same issue recently and I took my time to dig deeper into this. I found more problems. But also solutions :)
On the most fundamental level, it boils down to defining the terms used address
and new address
. Currently, in PyOTA a used address
is defined as an address that has transactions and a new address
is defined as an address that has no transactions. This approach is not snapshot resistant.
Therefore, in my opinion, in PyOTA there are currently the following problems that should be fixed:
stop=x: int
because it first checks which addresses have transactions and executes getBalance only for addresses that have transactions. This leads to strange results that are mentioned in this issue.stop=None
use the function iter_used_addresses
where a used address
is defined as an address that no transaction. I think this iteration stops too early in cases where the address has a balance or was already spent from.In my opinion the definitions of used address
and new address
should be changed like this:
used address
is an address that was spent from OR has a balance OR has a transaction.new address
is an address that was not spent from AND has no balance AND has no transaction.These definitions are snapshot resistant. The above commands would work in a consistent (an address is either in the state used
or new
) and expected way. getAccountData, getTransfers and getInputs would iterate in some cases over more addresses and that makes them more convenient to use.
Of course, it is important to stay consistent with other IOTA libraries. Therefore I checked the behaviour of the JavaScript library. It seems that the JavaScript library, in general, follows the definitions I suggested above but there are one or two cases where this is not true. I think that this is more likely an unexpected behaviour than intentional design. Within the next days, I will open an issue in the JavaScript GitHub repository where I will document my findings of the JavaScript library and where we can discuss the behaviour that the client libraries should have.
😻 Awesome analysis, thanks @pdecol !
Important: Co-ordinate this change with the other IOTA API libraries, to ensure behaviour remains consistent.
If there are no transactions for the generated addresses (e.g., after a snapshot),
get_account_data()
always returns an empty result, even if one or more of the generated addresses have a balance.This behaviour makes sense when specifying
get_account_data(stop=None, ...)
(the address generator would stop at the 0th address because there are no transactions), but it is not intuitive when specifying a value forstop
(see #212 for an example).