attoken claim with multiple receivers

[buhtignew]

I was about to claim the transaction c6a73f51fc3d336689e43c60a6715110486fca80b9940cafb38c6ddba0b90ddd created for the deck johns_attoken2 (8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012) for the multiple receivers, here is my transaction list johns_attoken2 -g -u output:

{
    'txid': 'c6a73f51fc3d336689e43c60a6715110486fca80b9940cafb38c6ddba0b90ddd',
    'value': Decimal('1.13'),
    'outputs': [0],
    'height': 505864
}

but when I've run attoken claim johns_attoken2 c6a73f51fc3d336689e43c60a6715110486fca80b9940cafb38c6ddba0b90ddd -r "[myHPHhnncUaiFQGqN1FK2qFtwcfPE4Bkqc, n2nSbZYLV77NFHSD3P4ZdFKyp65rtTHP1b, mtYvCVBtEayA5y6szGSrSgGwHQfe44Bgh2, mxTq1JuXLMZjaKA8LkdySk3sMwhRz4FEG2, mgUkRF2eosnFQpMKqAYxuzVLxccTPyNxYw]" -a "[0.7, 0.1, 0.01, 0.3, 0.02]" I've got the following message:

Error: Amount of cards does not correspond to the spent coins. Use --force to override.

_ I've also run attoken claim johns_attoken2 c6a73f51fc3d336689e43c60a6715110486fca80b9940cafb38c6ddba0b90ddd -r "[usage_checked, old_default, new_after_refill9, fresh_after_refill9, flag-l]" -a "[0.7, 0.1, 0.01, 0.3, 0.02]" replacing the addresses with its labels and got the following message:

Error: Receiver/Amount mismatch: You have 76 receivers and 5 amounts.

The strange thing here is that, differently from the previous case, the comma (together with the following space) isn't considered the addresses' separator, but each character, including the commas and the white spaces, seems to be treated as if it was a distinct address.

[d5000]

Error: Amount of cards does not correspond to the spent coins.

Fixed in commit 57b90c8.

In the same commit, support for labels in receivers was added (previously only addresses were permitted.) This may have caused the Receiver/Amount mismatch and should work now.

Unfortunately I couldn't reproduce the "funny" error that each character is considered a different address. :)

It seems that the label flag-1 causes problems due to the dash. I created a label with dash myself and also was not able to claim tokens to it.

So I have decided to disallow dashes for labels and only allow letters, numbers and underscores. You can still change labels with disallowed characters, but not set new labels with these. This is valid for all labels, not only address labels, which use the extended configuration file or the keyring.

Commit: e5bba26 + 42aa635 (second one is a bugfix for keyring labels)

[buhtignew]

From the main address n3MtPoPaAREU5GEhAErBPuju83bVog2opz I've run transaction list johns_attoken2 -g -u and got:

{
    'txid': '2a224d0c1dd16cfa5551b4cc12fb1cf689d5ea16dacc8985339ce29b136de196',
    'value': Decimal('1.123456'),
    'outputs': [0],
    'height': 506909
}

Then I've launched attoken claim johns_attoken2 2a224d0c1dd16cfa5551b4cc12fb1cf689d5ea16dacc8985339ce29b136de196 -r "[myHPHhnncUaiFQGqN1FK2qFtwcfPE4Bkqc, n2nSbZYLV77NFHSD3P4ZdFKyp65rtTHP1b, mtYvCVBtEayA5y6szGSrSgGwHQfe44Bgh2, mxTq1JuXLMZjaKA8LkdySk3sMwhRz4FEG2, mgUkRF2eosnFQpMKqAYxuzVLxccTPyNxYw]" -a "[0.7, 0.1, 0.01, 0.3, 0.12456]" and got the following error:

Error: Amount of cards (1.2345599999999999) does not correspond to the claimable amount (1.123456).

I've run attoken claim johns_attoken2 c6a73f51fc3d336689e43c60a6715110486fca80b9940cafb38c6ddba0b90ddd -r "[usage_checked, old_default, new_after_refill9, fresh_after_refill9, flag-l]" -a "[0.7, 0.1, 0.01, 0.3, 0.02]" and got:

Error: Receiver invalid: [

Then I've run attoken claim johns_attoken2 c6a73f51fc3d336689e43c60a6715110486fca80b9940cafb38c6ddba0b90ddd -r "[usage_checked, old_default, new_after_refill9, fresh_after_refill9, flag_l]" -a "[0.7, 0.1, 0.01, 0.3, 0.02]" and got:

Error: Receiver invalid: flag_l

In fact I haven't renamed flag-l to flag_l yet, so this message seems to be meaningful, but the previous one (Receiver invalid: [) doesn't make it clear what is the exact issue.

Then I've renamed flag-l to flag_l and the error was gone. However since my main address was different from the address of the original burn transaction I've got the expected error:

Error: You cannot claim coins for another sender.

So I've set the address mjXqewNUxUCW4v6bQ7CzhRAVMLHmQ6ktxN as main and tried to run attoken claim johns_attoken2 c6a73f51fc3d336689e43c60a6715110486fca80b9940cafb38c6ddba0b90ddd -r "[usage_checked, old_default, new_after_refill9, fresh_after_refill9, flag_l]" -a "[0.7, 0.1, 0.01, 0.3, 0.02]" again, but got:

General error raised by PeerAssets. Check if your input is correct.

Maybe it worth mentioning that if I run attoken create_tx 8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012 1 I'm also getting the same error. _ I'm not able to reproduce the Error: Receiver/Amount mismatch: You have 76 receivers and 5 amounts. error as well as you for the moment, probably it's gone. I'll try again once the above is solved.

[d5000]

The "General Error" was a side effect of my new label restrictions. Fixed.

Error: Receiver invalid: [

This is exactly the type of error you will get when using dashes or potentially other special characters in labels. As these characters are no longer allowed now, this error won't appear again.

Error: Amount of cards (1.2345599999999999) does not correspond to the claimable amount (1.123456).

This should be fixed in commit dfedfb2.

I discovered however a problem I thought I had fixed long ago with the numbers of decimals, so you will have probably still problems with this command. I hope to fix it later today.

EDIT: I now disallowed claiming with more decimal places than the token supports with commit c2a2ca4. While this is also "solved" at pypeerassets level, it would lead to confusion if you claim e.g. 1.23456 tokens and only get credited 1.23.

If there are no more problems this issue can be closed.

[buhtignew]

I now disallowed claiming with more decimal places than the token supports

Maybe we should add the allowed decimal places check for pacli attoken create_tx TOKEN AMOUNT and pacli pobtoken burn_coins AMOUNT -i TOKEN Usage modes, to avoid people being disappointed for having chosen the modes that are supposed to check the compatibility and to lose some of their coins because there was no complete compatibility in this case.

[d5000]

I like the idea and have implemented it now (commit 71e4095):

If your amount is not optimized, then you will be prompted with the option to optimize it (you have to enter 'yes' for that).

BTW: I'm thinking about renaming the create_tx command to something less generic, but have not found an optimal word. Simply gateway or gate I think is not really meaningful, and spend could be misinterpreted that it means "spend the tokens".

[buhtignew]

I was thinking about just send_coins instead of create_tx, could it work for you? _

If your amount is not optimized, then you will be prompted with the option to optimize it (you have to enter 'yes' for that).

I've tested attoken create_tx ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 1.111 and received the following output:

Sending transaction of 1.111 coins to burn or AT gateway address: n3MtPoPaAREU5GEhAErBPuju83bVog2opz
NOTE: You are spending an amount which will not be fully credited due to the number of decimals the token offers.
Do you want to optimize the reward spending exactly 1.11 coins?
(To abort the transaction, use KeyboardInterrupt, e.g. Ctrl-C)
Enter 'yes' to confirm to continue

Then I've replied no and the transaction went through in any case (5016f38e29488b2a5eaf0800692a071301f0b95c992d3a3b687dd955828ccb9d). I'd suggest to make some change in the above dialog: 1) I'd edit the line (To abort the transaction, use KeyboardInterrupt, e.g. Ctrl-C), if possible: since for those using pacli_env, like me, aborting with Ctrl-C would lead to aborting the pacli_env itself. So I'd prefer if the command could be aborted with whatever word except yes (I assume it will be typically a no). 2) I suppose the line Enter 'yes' to confirm to continue is making part of the standard yes/no dialog, so it wouldn't be that comfortable changing it for this specific case. If my assumption were wrong I think it would be better to write something like Enter 'yes' to optimize or Enter 'yes' to optimize the amount to ... coins.

[d5000]

send_coins is an improvement I think so I have change it to this. Thanks for the suggestion.

I've changed the dialog now in the way that a "yes" optimizes, a "no" sends the tx like originally planned, and a blank entry or any other entry aborts the transaction, so we have all three options. Commit: 8fb0f67

[buhtignew]

I think this can be closed now.