The behaviour of getAccountData, getInputs and getNewAddress for addresses with balance and without transactions

[pdecol]

Description

I noticed that the IOTA Python library has implemented these commands in a none snapshot resistant and none intuitive way (iotaledger/iota.py#217). To keep the behaviour of the client libraries consistent I tested these commands with the JavaScript library. I noticed odd results if a start parameter is given but no end for addresses that have a balance but no transactions due to a snapshot.

getInputs stops searching at such addresses and does not continue to search for more inputs. It certainly would be expected and convenient if it would continue to search for more inputs.

newAddress returns such an address. This is strange because it will not return such an address if there is a balance and a zero value transaction. Also, I would not consider such an address as "new".

getAccountData stops searching at such an address and does not return the balance. This seems like a bug to me. It should return the balance and continue searching.

In my opinion, getInputs and getAccountData should stop only if they find an address where it was not spent from and has no balance and has no transaction. newAddress should return the first address that was not spent from and has no balance and has no transaction.

Motivation

The methods should work in a consistent and expected way. All IOTA libraries should implement it in the same way.

Am I planning to do it myself with a PR?

No. I want to discuss and clarify how IOTA libraries should implement these methods and implement it that way for the Python library.

[chrisdukakis]

Hi @pdecol those issues are solved in account module, which persists inputs in a database. Could you have a look at it?

In my opinion, getInputs and getAccountData should stop only if they find an address where it was not spent from and has no balance and has no transaction

There might be an address at any index that isn't spend and has no balance/transactions. This wouldn't include addresses at higher index. getNewAddress should always return the address right above the latest known index, and this is implemented in account module, alongside input selection.

[pdecol]

Hey @chrisdukakis thanks for your response. No, I have never used the account module. But of course, with the statefulness of this module, you should not have these issues. I just thought It would make sense to correct this on the lower API level. I think this would be useful for applications that don't (want to) use the account module and rather work directly with the APIs. Does this make sense? Or is it recommended to always use the account module and there is no need to use these APIs directly?

There might be an address at any index that isn't spend and has no balance/transactions. This wouldn't include addresses at higher index.

Sure, there is no perfect solution with only the stateless APIs because eventually, it has to stop searching at some point. But with these changes, there would be some cases where more inputs would be found which makes it a bit more convenient to use.

[lzpap]

Hey @chrisdukakis and @pdecol,
Indeed account module solves the issues mentioned above, but I can also understand why it would make sense to reduce weird after snapshot behavior on lower level API.

I would like to point out however, that as a user of the IOTA libs, I have certain expectations from the API. If I call a method called getNewAddresses, I would like it to return a completely new one, and in that sense the suggestion of @pdecol (that a new address should be one that doesn't have transactions, was never spent from and has no balance) is a good one.

Also from a user perspective, it is a bit strange for me to have API call getAccountData which is in no way related to account module, and relies heavily on me to specify the index range to return the correct result. I understand that the only perfect solution for this is using the account module due to the stateless nature of the API, so there is not much we can do about it on API level.

The one thing we could do is to add that extra "and has no balance" check to getNewAddresses API call. @chrisdukakis , would this have serious effects on the JS lib? Are there higher level methods that rely on the "has no transactions and was not spent from" type of result from getNewAddress? If so, what if we have different API calls, something like getFirstUnusedAddress and getNextNewAddress?

I'm just brainstorming, let me know what you think :)

[chrisdukakis]

Hey @lzpap , in any case it won't work reliably unless we add state.

[obany]

Closing as this relates to an unmaintained branch of the library, which will be incompatible with the new Chrysalis release of the network.