pobtoken create_tx advanced mode

[buhtignew]

I've run pobtoken create_tx mmSLiMCoinTestnetBurnAddress1XU5fu 1.101 (from my main address n3MtPoPaAREU5GEhAErBPuju83bVog2opz) and have produced transaction 7c8db9d1b18083b0cf440ec2b8ca0bee56afb55f5398ba185a2d80123fec4743.

After that I've run pobtoken claim ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 7c8db9d1b18083b0cf440ec2b8ca0bee56afb55f5398ba185a2d80123fec4743 and have produced transaction e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d.
But my token balances -t ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 output has remained unchanged after the claim transaction confirmation:

{'n3MtPoPaAREU5GEhAErBPuju83bVog2opz': 1.34}

However after that I've run pobtoken claim fb93cce7aceb9f7fda228bc0c0c2eca8c56c09c1d846a04bd6a59cae2a895974 7c8db9d1b18083b0cf440ec2b8ca0bee56afb55f5398ba185a2d80123fec4743 (transaction 14a450b1ba3eae8641ba00b931de9aaa771e20f06d07db1c025e037d14f84661) and my token balances -t fb93cce7aceb9f7fda228bc0c0c2eca8c56c09c1d846a04bd6a59cae2a895974 output has been increased from 3454.5677 to 3564.6677 as expected.

I'd don't know whether the "conflicting4" deck hasn't increased its token balance on my main address because it has the same burning address and it's somehow truly conflicting with the main PoB deck or there is something I've done wrong in this context.

At this point I've made an additional test by running pobtoken claim 95b24015ffb46d82015b709d774542fc4a53ccf27f72d973ed3fb18c384a80ca 7c8db9d1b18083b0cf440ec2b8ca0bee56afb55f5398ba185a2d80123fec4743 (transaction b752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6), however my token balances -t 95b24015ffb46d82015b709d774542fc4a53ccf27f72d973ed3fb18c384a80ca hasn't changed, it has remained

{'n3MtPoPaAREU5GEhAErBPuju83bVog2opz': 1.0}

My assumption at this point is that pobtoken create_tx advanced mode uses the standard PoB deck as default (if so, maybe we can mention it in the help).

[d5000]

I believe the issue is the same as in #150 : an inconsistency of the Slimcoin command listtransactions, which is the base for the token transfers and token balances commands. I saw the claim transaction you created here (e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d) and was not considered also has all the characteristics to be valid, but isn't shown neither in token transfers, not even with -s, neither in transaction list when using the P2TH address of the conflicting4 or ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 token.

So I'd say: let's close here and continue in #150.

By the way your assumption is wrong, the standard PoB token isn't taken into account in any way by that command.

[buhtignew]

Sorry for re-opening this one which was supposed to stay closed but I've set the n3MtPoPaAREU5GEhAErBPuju83bVog2opz address as main and I have re-checked transaction list ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 -c output right now and found the following claim transaction there:

{
    'TX ID': 'e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d',
    'Burn transaction': '7c8db9d1b18083b0cf440ec2b8ca0bee56afb55f5398ba185a2d80123fec4743',
    'Token amount(s)': [1.1],
    'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
    'Block height': 488870
}

Then I've run token transfers ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 and here is the output I've got:

+Card transfers of deck ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4:--------------------------------+------------------------------------+--------+-----------+
| txid                                                             | confirms | seq | sender                             | receiver                           | amount | type      |
+------------------------------------------------------------------+----------+-----+------------------------------------+------------------------------------+--------+-----------+
| 8c4d82de8205b8b53d1343ff6bac91a843c652f201fa9d4fb2ccea217045437f | 33215    | 0   | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | 1.23   | CardIssue |
| 45dbca7f9efddc24ad4dd26d1ef4c8c6a63f371409404a91e184dfee1d4aaa7e | 33196    | 0   | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | 1.34   | CardIssue |
| e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d | 30617    | 0   | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | n3MtPoPaAREU5GEhAErBPuju83bVog2opz | 1.1    | CardIssue |
| 30b944585e920a788dcf378eeea93c388f1ccdae44f6a5a7ad79853e1d27c9eb | 1346     | 0   | mkfuTykT6anzsRjYH7Lktc2hFuTqcGpha7 | mkfuTykT6anzsRjYH7Lktc2hFuTqcGpha7 | 1.23   | CardIssue |
+------------------------------------------------------------------+----------+-----+------------------------------------+------------------------------------+--------+-----------+

However my token balances -t ac0f950a8fd4a8ee8d710a2463ee3c42e3f8a8fc7779e43e63810d12117d7be4 is

{'n3MtPoPaAREU5GEhAErBPuju83bVog2opz': 3.67}

While the sum of token transfers is 4.9 so as the difference is 1.23.

So it seems like since the OP the situation has changed: the claiming transaction that I thought wasn't credited (e6602ce9f59c8894aa0a21858ab913869c19d2ff5bebe73e95526fa0852d383d) is now making part of the token balances, while one of the 1.23 tokens transactions (presumably the last one since it looks a bit anomalous compared to the other ones of the list) isn't.

So I'm asking myself whether while I assumed to have got the claiming transaction confirmation actually it was not in place yet or maybe there is some kind of latency in crediting the tokens?

[d5000]

Ah, this last transaction was made by me and is on my address mkfuTykT6anzsRjYH7Lktc2hFuTqcGpha7 :) So of course you will not see it as part of your token balance.

I think at least for this token I have found the problem, it was actually my fault: I forgot to rescan after initializing the token. After a rescan I see all transactions correctly.

I believe you may have had the same problem: When you first tested, you may have not rescanned the blockchain after initializing the new deck. You may have rescanned later for another reason and then it worked again.

That means that the unrealiability of listtransactions is not that severe I thought initially when I answered issue #150 . Nevertheless, I will probably add an -x (blockchain-based) mode to token transfers, as it will probably not be too difficult.

I have also added a sentence to the help of deck/token init about the rescan issue.

I believe this issue can be closed thus. I will open a new issue once I implement the -x mode for token transfers.