High Volume GAS Claim Improvement

[brianlenz]

What current issue(s) does this address, or what feature is it adding?

Addresses with thousands of UTXOs may have issues with transaction size preventing GAS claims from working in neo-python.

@localhuman: will be curious to hear your thoughts on this. Does the approach seem reasonable? Necessary? Anything that could be better about it?

How did you solve this problem?

Claim GAS for at most 200 UTXOs at a time.

How did you make sure your solution works?

Tested and used the process.

Are there any special changes in the code that we should be aware of?

No.

Please check the following, if applicable:

• Did you add any tests?
• Did you run make lint?
• Did you run make test?
• Are you making a PR to a feature branch or development rather than master?
• Did you add an entry to CHANGELOG.rst? (if not, please do)

[coveralls]

Coverage decreased (-0.003%) to 78.784% when pulling eec6e38 on brianlenz:chunk-gas-claim into 754325f on CityOfZion:development.

[localhuman]

Is there an example / test /use case where addresses with lots of claimable are currently failingl?

[brianlenz]

I've had this happen a couple of times, and the only fix I found was to chunk through the claims incrementally (which has worked without issue). The main use case for us was with our token sale SC address, which had 2k-3k claims available. At two different points in time (mid-sale and post-sale), I had tried using the standard claim process, and the tx would never go through. It would break the state of the wallet, and I'd have to rebuild the wallet. I suspected size was the issue, so I started playing around with it. I tried chunks of 500 claims at a time, and that didn't work. I found the only way around it was to chunk through the transactions in smaller increments, and 200 seemed to work in our case. It's definitely not scientific in any way, which is why I was curious to get your thoughts. If this is something that shouldn't technically be necessary, then perhaps there is some separate issue that needs to be addressed (and this approach scrapped altogether).

Unfortunately, I don't have an active example of this issue...

[localhuman]

Thanks for the explanation. I'd be interested in the root cause of the issue, but would have to be able to reproduce to determine that. I wonder if maybe we're running into the max size of a transaction?

Perhaps for now it would be best to allow users to pass in the size of the chunk, otherwise it defaults to current behavior?

[brianlenz]

I like that idea! I'll take a crack at it :)

[brianlenz]

Should be good to go now, I believe.

[localhuman]

Thanks for the changes!