Skip to content
This repository has been archived by the owner on Jan 13, 2023. It is now read-only.

get_account_data() always returns empty result if there are no transactions #217

Open
todofixthis opened this issue Dec 28, 2018 · 3 comments
Labels

Comments

@todofixthis
Copy link
Contributor

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 for stop (see #212 for an example).

@todofixthis
Copy link
Contributor Author

Related: #175

@pdecol
Copy link
Contributor

pdecol commented Sep 24, 2019

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:

  • getAccountData is wrong with 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.
  • getAccountData, getTransfers and getInputs with 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.
  • getNewAddresses returns an address if there is no transaction on this address. Therefore, it returns addresses that have a balance or even addresses that were already spent from. The last case is of course pretty bad.

In my opinion the definitions of used address and new address should be changed like this:

  • A used address is an address that was spent from OR has a balance OR has a transaction.
  • A 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.

@todofixthis
Copy link
Contributor Author

😻 Awesome analysis, thanks @pdecol !

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants