pobtoken create_tx with PoBtoken decks testing

[buhtignew]

I've tested pobtoken create_tx for all initialized PoB decks I have and one not initialized.

• I've run pobtoken create_tx fb93cce7aceb9f7fda228bc0c0c2eca8c56c09c1d846a04bd6a59cae2a895974 1, produced aebca94448d05baab622feb6f2b4a59841b5ba863fee6b906218193e3c988f9a transaction, claimed it with pobtoken claim fb93cce7aceb9f7fda228bc0c0c2eca8c56c09c1d846a04bd6a59cae2a895974 aebca94448d05baab622feb6f2b4a59841b5ba863fee6b906218193e3c988f9a (transaction 88e134cc04dc08f426a0b72ebc5e2f9277435c51c900491a700d57703e84e93f) and my address for the standard PoB token deck has been increased by 100.

• I've run pobtoken create_tx ATTokenNewSpec2 1.34 and after the yes/no dialog I've got Error: No valid address string or non-existing label in the extended configuration file.

• Then I've run pobtoken create_tx 95b24015ffb46d82015b709d774542fc4a53ccf27f72d973ed3fb18c384a80ca 1 and pobtoken claim 95b24015ffb46d82015b709d774542fc4a53ccf27f72d973ed3fb18c384a80ca 8be48f92244dbe49fd2bee66878c93622d98f6448fd2fb4010b7c74dbe6cca04 and my token balances -t 95b24015ffb46d82015b709d774542fc4a53ccf27f72d973ed3fb18c384a80ca output was {'n3MtPoPaAREU5GEhAErBPuju83bVog2opz': 1.0}.

• Then I've run pobtoken create_tx a843d6bec0da495ea0cc03fcd36942598ba9f786547a800721c0e78b99c0adca 1, for the testEne24 token which is not initialized on my side and when I've run pobtoken claim a843d6bec0da495ea0cc03fcd36942598ba9f786547a800721c0e78b99c0adca 19346a211d38a43366b40334cf63f76a34a136579ed8750878acbc1f365d8a35 I've got Error: Deck not initialized. Initialize it with 'pacli deck init DECK'.

• Then I've run pobtoken create_tx conflicting4 1.234 and pobtoken claim conflicting4 d8d9c1253fd7e68a9f7b66c48e0a7de45b6469e2a4f93af803d40d9db0c5845c and have produced the claim transaction 8c4d82de8205b8b53d1343ff6bac91a843c652f201fa9d4fb2ccea217045437f however my token balances -t ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 output was {'n3MtPoPaAREU5GEhAErBPuju83bVog2opz': 0}, then I've tried to claim the same burn transaction with pobtoken claim ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 d8d9c1253fd7e68a9f7b66c48e0a7de45b6469e2a4f93af803d40d9db0c5845c command (transaction 48ba90a7b9c9da6f896fe30d13517da2b8c08c4176566a53f1ddd051838bfc59, but the conflicting4 deck balance has remained zero.

• Then I've run pobtoken create_tx ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 1.34 and pobtoken claim ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 57d9d21e15cc3a624c532ccda2375fe7ae8985d6af6eb642b4d4f4d1534531e7 (for the conflicting4 deck) and this time my token balances -t ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 was {'n3MtPoPaAREU5GEhAErBPuju83bVog2opz': 1.34}

So it seems like the pobtoken create_tx command doesn't consider the labels in the right way.

[d5000]

The create_tx command is only to be used on AT tokens within the attoken command category. The PoBtoken equivalent is the burn_coins command.
I have now disabled it manually refactoring the ATToken and PoBtoken classes in a way pobtoken can't be called anymore with create_tx and it won't be shown in pacli pobtoken -h. (Commit: 5de100d)

Anyway the logic of these commands is identic, the only problem is that it created confusion.

So I looked if there was a bug triggered by your commands and how your problems with labels could be explained. But I wasn't able to produce an unexpected output when creating txes and claiming the tokens you wrote about here. I created exactly the same transaction (with attoken create_tx) from one of my addresses for the token conflicting4 (ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4), claimed tokens and they were credited correctly.

Possibly the bug was already fixed with one of the last updates, as I have already worked with the create_tx and claim commands recently.

PS: I've got indeed some unexpected results when working with token "conflicting4" (on my side it's initialized):

• I can't explain why your claim transaction 8c4d82de8205b8b53d1343ff6bac91a843c652f201fa9d4fb2ccea217045437f is not valid.
• Deck conflicting4 is not shown in the deck list -p output. It is a PoB token so it should be shown.

I will leave this open thus and look deeper into it.

[buhtignew]

Deck conflicting4 is not shown in the deck list -p output. It is a PoB token so it should be shown.

Did you mean deck list -b in this case?

[d5000]

Oh, my fault. It's actually correctly shown with deck list -b.

The other problem however remains. I made some more tests and the culprit seems to be again the unreliable listtransactions command from slimcoind, because the claim transaction looks valid (the OP_RETURN data is not corrupted and it spends to the correct P2TH address), but it is not shown if I do transaction list n1o3664EJiDZxFr918q1oncWATsVbiKwXS, which is the P2TH address of this token. This explains that token transfers conflicting4 does also not show it, because it relies also on listtransactions.

Will do some more tests with a fresh wallet later. It's possible we will need an -x mode (looking directly at the blockchain, like in transaction list) for some more commands. Would not be rocket science but of course take time.

[buhtignew]

After I've re-checked the #151 and replied there I've also checked the "missing" transaction from this thread.
And since token transfers conflicting4 output is still:

Using deck stored locally with label conflicting4 and ID ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4.
+Card transfers of deck ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4:--------------------------------+------------------------------------+--------+-----------+
| txid                                                             | confirms | seq | sender                             | receiver                           | amount | type      |
+------------------------------------------------------------------+----------+-----+------------------------------------+------------------------------------+--------+-----------+
| 8c4d82de8205b8b53d1343ff6bac91a843c652f201fa9d4fb2ccea217045437f | 33240    | 0   | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | 1.23   | CardIssue |
| 45dbca7f9efddc24ad4dd26d1ef4c8c6a63f371409404a91e184dfee1d4aaa7e | 33221    | 0   | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | 1.34   | CardIssue |
| e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d | 30642    | 0   | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | 1.1    | CardIssue |
| 30b944585e920a788dcf378eeea93c388f1ccdae44f6a5a7ad79853e1d27c9eb | 1371     | 0   | mkfuTykT6anzsRjYH7Lktc2hFuTqcGpha7 | mkfuTykT6anzsRjYH7Lktc2hFuTqcGpha7 | 1.23   | CardIssue |
+------------------------------------------------------------------+----------+-----+------------------------------------+------------------------------------+--------+-----------+

I'd say the "missing" transaction from this thread (8c4d82de8205b8b53d1343ff6bac91a843c652f201fa9d4fb2ccea217045437f) is not missing anymore as well.

Since the original burn transactions (7c8db9d1b18083b0cf440ec2b8ca0bee56afb55f5398ba185a2d80123fec4743 and d8d9c1253fd7e68a9f7b66c48e0a7de45b6469e2a4f93af803d40d9db0c5845c) of both 8c4d82de8205b8b53d1343ff6bac91a843c652f201fa9d4fb2ccea217045437f and e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d (mentioned in the #151) had the number of decimals after the comma not in line with the number_of_decimals of conflicting4 (token show conflicting4 -i -p number_of_decimals) I assume they were just pending until you haven't solved the bug here.
_
I can also see them with transaction list n1o3664EJiDZxFr918q1oncWATsVbiKwXS | grep -e 8c4d82de8205b8b53d1343ff6bac91a843c652f201fa9d4fb2ccea217045437f -e e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d:

    'txid': 'e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d',
    'txid': '8c4d82de8205b8b53d1343ff6bac91a843c652f201fa9d4fb2ccea217045437f',

[d5000]

Yes, as written in #151 the issue was probably related to me (and you before) having forgot rescanning after initializing the new deck.

The number of decimals issue was almost for sure not related, because it was only affecting the interface of the claim process. As soon as the claim transaction is created, always an integer value of tokens will be credited (e.g. if you have a token with 2 decimals and try to claim 1.235, 123 token units will be created but later they will be shown as 1.23).

Issue can be closed, I think.