attoken create_tx testing

I haven't forgot your suggestion to test attoken create_tx command. I only haven't got time to work on it so far. But finally I've been able to make some testing.

I've did as following:

I've run deck show f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82 -i command and got the at_address from its output which was mmLRYBJMsLBrHCGQAwx4fwMt3egt1J3qbo,
then I've run attoken create_tx mmLRYBJMsLBrHCGQAwx4fwMt3egt1J3qbo 1 --send --sign to "donate" coins to that address,
the transaction went fine, its txid was e5ad970fa51f9475da82f72f1b4a071bd527769e6ad4a7d2ec19886ded9c1ea4,

then I've run

attoken claim  f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82 e5ad970fa51f9475da82f72f1b4a071bd527769e6ad4a7d2ec19886ded9c1ea4

to claim the tokens and got the long error message like this:

Traceback (most recent call last):
File "~/.local/bin/pacli", line 8, in <module>
sys.exit(main())
         ^^^^^^
File "~/.local/lib/python3.12/site-packages/pacli/__main__.py", line 479, in main
fire.Fire({
File "~/.local/lib/python3.12/site-packages/fire/core.py", line 143, in Fire
component_trace = _Fire(component, args, parsed_flag_args, context, name)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "~/.local/lib/python3.12/site-packages/fire/core.py", line 477, in _Fire
component, remaining_args = _CallAndUpdateTrace(
                            ^^^^^^^^^^^^^^^^^^^^
File "~/.local/lib/python3.12/site-packages/fire/core.py", line 693, in _CallAndUpdateTrace
component = fn(*varargs, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^
File "~/.local/lib/python3.12/site-packages/pacli/at_classes.py", line 101, in claim
return ei.run_command(eu.advanced_card_transfer, deck,
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "~/.local/lib/python3.12/site-packages/pacli/extended_interface.py", line 33, in run_command
result = c(*args, **kwargs)
         ^^^^^^^^^^^^^^^^^^
File "~/.local/lib/python3.12/site-packages/pacli/extended_utils.py", line 383, in advanced_card_transfer
inputs=provider.select_inputs(Settings.key.address, 0.02),
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "~/.local/lib/python3.12/site-packages/pypeerassets/provider/rpcnode.py", line 47, in select_inputs
raise InsufficientFunds("Insufficient funds.")
pypeerassets.exceptions.InsufficientFunds: Insufficient funds.

Which probably we can hide outputting a more user friendly one. However it seems like the attoken claim command has sent the change to another address, thus actually I had no balance, which was solved by sending some coin there.

the second attempt to run attoken claim f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82 e5ad970fa51f9475da82f72f1b4a071bd527769e6ad4a7d2ec19886ded9c1ea4 was successful and I've been able to produce the transaction with the following txid: 480270baf33b65cb78361f1190b3be17c90ac50cb505f923d9021addfe48b950,
however when I've tried to run token balances -t f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82 the output was:
```
{'mk9WFSTqgtTJbwb5g6pGpByTRbYKiSaX3w': 0}
```
_ Thinking the issue may be my old presumably corrupted wallet I've tried to run the same procedure for the new one:
I've sent 10 coins to the freshly created address of the new wallet mkbU3SGSMxt4tjVepPHGywWWJ7gYGrhoBG (txid:862e4a276463415e9e33e84c357815bb430066f76c0de2bec0bf87ea15d3195f),
then I've run attoken create_tx mmLRYBJMsLBrHCGQAwx4fwMt3egt1J3qbo 1 --send --sign from that address and got the txid 877682db4f35c8aae284621213f7f7685accd219d81918fb962a4fbaa2970e24
Here I've got an issue because when I've tried to send funds from the new wallet to its fresh address using sendtoaddress mkbU3SGSMxt4tjVepPHGywWWJ7gYGrhoBG 5 I've got Insufficient funds error and even 9 confirmation later after the "donation" transaction my new wallet's balance was still zero.
However I've sent 5 coins from another wallet (txid: 308cb9452c899110ccbb1aeb6ebb8345e0a1d1a0d689271812e71f79922b2892)
I've run attoken claim f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82 877682db4f35c8aae284621213f7f7685accd219d81918fb962a4fbaa2970e24 and got the txid: 9eb20ec23d3ac6a2abf2f6a9a58091c5a6fb992ee8ab8556fc50c92a7cb64f1b.
Then I've run token balances -t f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82 and got {'mkbU3SGSMxt4tjVepPHGywWWJ7gYGrhoBG': 0} although my coins balance on the same address has been incremented by 0.01.

What I've been doing wrong here?

After I've performed all the above I've further noticed an anomaly with the coins. In fact all the coins that was on my wallet has disappeared, so 13 confirmations after I've claimed the tokens the wallets balance I can see with slimcoind getbalance is still 0.01. Thus not only the previous 10 tSLMs has disappeared after I've run attoken create_tx command but also the 5 tSLMs I've sent to the my address latter are not visible by the wallet after I've run the attoken claim command.

_ Update: I've looked into my new address' transaction list and have found this two transactions: 9eb20ec23d3ac6a2abf2f6a9a58091c5a6fb992ee8ab8556fc50c92a7cb64f1b and 877682db4f35c8aae284621213f7f7685accd219d81918fb962a4fbaa2970e24 in which the "disappeared" amounts are being sent to one of my addresses of the old wallet. So I think the issue has to do with the fact I haven't flushed the addresses of the old wallet from my extended configuration file and thus haven't followed your suggestion yet. For that reason pacli perceives the old wallet's address mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP as "mine" and sends the change there.

So the sole question that remains is where are the tokens I've claimed. I've checked whether by chance they are on the address mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP but they are not. And the the token balances -w -t f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82 outputs no tokens neither on the old wallet nor on the new one.

I've looked into your claim transaction.

The "donation transaction" e5ad970fa51f9475da82f72f1b4a071bd527769e6ad4a7d2ec19886ded9c1ea4 looks good, the donation address is correct.

The claim transaction has the same sender than the donation address, and the token is credited to the sender (mk9WFSTqgtTJbwb5g6pGpByTRbYKiSaX3w) so this source of error is also discarded.

So the next thing to check would be pacli token transfers f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82. Here I get an IndexError which indicates that the token claim transaction was not considered by the algorithm (and should be catched anyway, this will come with the next update).

EDIT: I found the issue. The token had a "deadline" at block 250000. Obviously this one has been long passed. So the issued tokens are invalid.

You can see these deadlines with pacli token show f7b1af6d565898851878cb13c88bb52996a0a5380c4ea8803c248a69c7d00d82 -i looking at the "startblock" and "endblock" parameters.

I think about how this can be communicated better by the interface. attoken create_tx should issue a warning in this case, or directly abort the transaction.

EDIT 2: Commit a44844a contains usability improvements and new warnings when the transaction would be invalid e.g. because a deadline is reached. The command create_tx should now be called normally in the format pacli attoken create_tx DECK AMOUNT instead of pacli attoken create_tx ADDRESS AMOUNT, although the second mode continues to be valid (but will not perform checks).

The same mode was added to pacli pobtoken burn_coins but with the -i TOKEN option. Thus it continues to be possible to simply burn coins with pacli pobtoken burn_coins AMOUNT without having to bother with any deadline/validity checks.

EDIT 3: Changed behavior of token list -a. It will now not more show PoB decks, but only AT tokens which do not use the burn address. This makes it easier to find non-PoB AT tokens.

A token you can use for testing is 7a2ae406ddf44ddb17532d4888fdc14573f52749445e9e014075c9f83cbe556f, which has no deadline (global name ATTokenNewSpec).

Commit: 878f9de

... the second mode continues to be valid (but will not perform checks).

Wouldn't it make sense to drop the mode that doesn't perform checking?

_ I've tested attoken create_tx mmLRYBJMsLBrHCGQAwx4fwMt3egt1J3qbo 1 --send --sign and it seems like some else is missing in the code, because although I've answered "no" to the question contained in the starting dialog:

WARNING: If you send the coins directly to a gateway address, then possible incompatibilities (e.g. deadlines) will not be checked.
Consider using the token ID or label/name as first argument instead.
Enter 'yes' to confirm to continue

The command was still executed and I've got the following output:

Looking for chain reorganizations ...
Last checkpoint found: height 444851 hash 00000081bff4930b599f68592dfafc9537422b72bc7b391fdceb27850a323eef
No reorganization found. Everything seems to be ok.
Storing hash of block as a checkpoint to control re-orgs.
 Height: 444854 Hash: 0000003cb28285625dd72c45e988726ea8d7e9e9419e5f7bb0d6e3aaba93aed0
Stored checkpoint:
Label: 444854
Value: 0000003cb28285625dd72c45e988726ea8d7e9e9419e5f7bb0d6e3aaba93aed0
{
    'txid': '08854ffbd5b91a3dbf2c56a302bcbc6b3c1aa4baddb8f3c912afa736ca7e8f97'
}
hex: 01000000a4be55660150be7ed6d6e267b11dac9cc547c9aca2c10d3ffc9e1e98654ea2ba80e18427d90000000049483045022100c0fe468c2c91f1693f240b3021b5d4bd77ac89ef629a0a53e42fce04cf9fd61402200bd2bc646cad765f63cd6f45697a1cff001c69c66a3d747450d21e8dbcf002ee01ffffffff0240420f00000000001976a9143fd2ebbe379ae3d0a7ddf714b49ceb69d79071a188acc0f10b01000000001976a914b5a2ced9afd823cb142607e2d4e7e979cb73b87f88ac00000000

UPDATE

A token you can use for testing is 7a2ae406ddf44ddb17532d4888fdc14573f52749445e9e014075c9f83cbe556f, which has no deadline (global name ATTokenNewSpec).

I've tested the ATToken creation procedure with the deck you've suggested and it has worked smoothly.

Wouldn't it make sense to drop the mode that doesn't perform checking?

The command can be used also to make simple transactions from the current main address to another one. And for burn transactions checking should anyway not be necessary because burning can be done for probably many tokens and also for block rewards of course (you can of course also use the slimcoind command, but with the pacli command you will send the coins exactly from the current main address).

The command was still executed

Thank you for spotting this, I thought I had it fixed already but no. Fix will be uploaded in the next update.

(Should be fixed as of commit 4b3bea00c00e40e2f1ec4a0cd8f37655d26f356a. Can be closed if no more problems appear.)

Should be fixed as of commit https://github.com/slimcoin-project/pacli/commit/4b3bea00c00e40e2f1ec4a0cd8f37655d26f356a. Can be closed if no more problems appear.

I'm closing this issue everything works as expected on my end.

slimcoin-project / pacli

attoken create_tx testing #99