Non-pertinent transactions included into the transaction list TOKEN -g -u output for the newly spawned ATToken deck

[buhtignew]

I think I've at least partially found the cause of the issue please have a look into the last update here beneath.

I've run token list -a and picked my freshly spawned deck johns_first_ATtoken (ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58).

Then I've run transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u to get a list of transactions to use with attoken claim command and picked the following transaction from the list:

{
    'txid': 'caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a',
    'value': Decimal('19.31'),
    'outputs': [3],
    'height': 60670
}

Then I've run attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a and got the following error:

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

The attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a --debug command outputs the following:

  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 140, in claim
    asset_specific_data, amount, receiver = ei.run_command(au.create_at_issuance_data, deck, txid, Settings.key.address, amounts=amounts, receivers=receivers, payto=payto, payamount=dec_payamount, debug=debug, force=force)
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  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/at_utils.py", line 191, in create_at_issuance_data
    if deck.at_address in output["scriptPubKey"]["addresses"]: # changed from tracked_address
                          ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
KeyError: 'addresses'

Seeing that the output number of that transaction is different from 1, I've also tried attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a:3 --debug with the same result as well as attoken claim 7a2ae406ddf44ddb17532d4888fdc14573f52749445e9e014075c9f83cbe556f caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a.

However when I've run attoken claim 7a2ae406ddf44ddb17532d4888fdc14573f52749445e9e014075c9f83cbe556f 1008fea9dc5d1117c4f371cfbaaa835acc2390ae754c536cdcd0b1c0c89b3d0f I've got a different message:

Error: This transaction does not spend coins to the tracked address

Which is expected, since differently from the PoB decks the ATtoken decks have a different gateway address each.

Then I've run attoken claim 7a2ae406ddf44ddb17532d4888fdc14573f52749445e9e014075c9f83cbe556f 384bce3ae91b6fac5e76b1f69d519c6372302ea38f4f16cbe55be871f126001c for the transaction I know for sure was a burn transaction for the ATTokenNewSpec deck and everything went smoothly (transaction bca273987792b2c56e4f1e7df242e66523d836dec6b34f74aae7c4ff5a885b39).

Thinking the issue had to do with the fact that the decks I'm running this command for weren't spawned at that height yet I've picked the first transaction from my transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u output:

{
    'txid': 'db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934',
    'value': Decimal('0.01'),
    'outputs': [2],
    'height': 490772
}

and run attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934. The error was still there.

However I've inquired further and have noticed that the list of transaction I'm seeing as transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u output is not perfectly ordered by the blockheight, i.e. they have the ascending order from the transaction I've mentioned above till transaction 83bf2fd400671fcc0f9b192bcefdbac73579b9489e07afae065ffa9bb3de2a85 (block 499311), then they restart from the transaction 09e04a9ff7ef2b8218ff3a5c4ea5320b00d2f2151b8c0747b9f5bf68e8d3be78, which is on the block 480421 and go on in ascending blockheight order till the transaction
b752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6:

{
    'txid': 'b752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6',
    'value': Decimal('0.01'),
    'outputs': [2],
    'height': 488907
}

and then there are the following 4 transactions:

{
    'txid': '1008fea9dc5d1117c4f371cfbaaa835acc2390ae754c536cdcd0b1c0c89b3d0f',
    'value': Decimal('0.8'),
    'outputs': [1],
    'height': 156823
}
{
    'txid': 'efe3ab74f01cb560571320b5f2dab69d09d9dadb737c17d0c0fac6a784dbab13',
    'value': Decimal('0.77'),
    'outputs': [2, 3],
    'height': 156895
}
{
    'txid': 'efe3ab74f01cb560571320b5f2dab69d09d9dadb737c17d0c0fac6a784dbab13',
    'value': Decimal('0.77'),
    'outputs': [2, 3],
    'height': 156895
}
{
    'txid': 'caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a',
    'value': Decimal('19.31'),
    'outputs': [3],
    'height': 60670
}

(for your convenience here
is the transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u output I was getting)

Moreover by inquiring further I've discovered that the transaction db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934 I was trying to use to claim my attoken for is mentioned in the issue #153 as the claim transaction of the following command: pobtoken claim 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 a45563c27360f25637f0cc12ca4d4d9b44849656ac3f56ce37125f220aa77331.

Having understood all that, I've picked the oldest transaction I'm seeing in my transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u output:

{
    'txid': 'b752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6',
    'value': Decimal('0.01'),
    'outputs': [2],
    'height': 488907
}

and tried to run attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 b752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6 and got the General error raised by PeerAssets. Check if your input is correct. again.

I've searched in our issues here again and have discovered in the #151 that the b752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6 is the claim transaction of the pobtoken claim 95b24015ffb46d82015b709d774542fc4a53ccf27f72d973ed3fb18c384a80ca 7c8db9d1b18083b0cf440ec2b8ca0bee56afb55f5398ba185a2d80123fec4743 command.

Looking into the transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u output I've realized that none of the listed transaction is similar to the burning transactions I've created, because their amounts are different from what I've been typically burning for my tests.
The only one that seemed similar to me was 4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8:

{
    'txid': '4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8',
    'value': Decimal('1.0'),
    'outputs': [0],
    'height': 499309
}

so I've run attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8 and was lucky this time, producing the claim transaction 02a0081d8707ee274e02474f8e489af378050892a149de9c77ff7f519ce061c7.

I think it's possible that the majority of the transactions included into my transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u are not burning transactions and also they doesn't have to do with the deck johns_first_ATtoken because the majority of them has happened earlier than the deck was spawned (on the 499309 block).

By the way the deck spawning transaction is also included into my transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u output and of course I'm not able to claim it, receiving General error raised by PeerAssets. Check if your input is correct. if I try to run attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58.
_
Update1 25-07-2024
I don't know whether the issue has to do with the fact that my newly spawned deck johns_first_ATtoken has the same at_address and issuer as the one I've been burning coins from.
I'm going to make tests in the next hours trying to understand whether it's relevant.
_
Update2 25-07-2024
I've run transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u again and compared its output with the same command's output I've got yesterday and have discovered that the transaction 4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8 has disappeared, as expected.
But surprisingly the two claim transactions bca273987792b2c56e4f1e7df242e66523d836dec6b34f74aae7c4ff5a885b39 and 02a0081d8707ee274e02474f8e489af378050892a149de9c77ff7f519ce061c7 I've mentioned here above yesterday were included into the newer version.
I've also noticed that there are many transactions included more than once both in the today's and the yesterday's outputs, for instance this one 35645ed307256f7ca9182b7c2d83fcbc1b15e8fa8e84e9bd00f5fa2427f23e65.
_
Update3 25-07-2024
I've spawned another deck, johns_attoken2. Making tests with that deck I've discovered that if the burn transaction is done from its at_address the claim transaction remains in the transaction list johns_attoken2 -g -u output.
I've also discovered that if I run transaction list johns_attoken2 -g -u or transaction list johns_first_ATtoken -g -u from any main address that is different from their at_address no unclaimed transaction is returned (the list is empty).
However for the moment I don't have any hypothesis about the origin of the other transactions that are in the transaction list johns_first_ATtoken -g -u output, because some of them are clearly not claim transactions and many of them were created even before the deck was spawned.

[d5000]

I started to work on this yesterday. Will update this post while I progress.

I think the first couple of errors, when you got the "red" PeerAssets general error should now be solved, as they were also occurring in another cases.

By the way the deck spawning transaction is also included into my transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u output and of course I'm not able to claim it

If the deck spawn transaction spends to the gateway address, then you should be able to claim it, regardless of it's a deck spawn transaction or not. I see that this is the case: as you spawned the deck from the same address you used as gateway address, the deck spawn transaction is also a gateway transaction because the change of the transaction went to the same address again.

I can of course not claim that transaction as the gateway address is not in my wallet, but now that the other issue is resolved you could try to claim it again.

However for the moment I don't have any hypothesis about the origin of the other transactions that are in the transaction list johns_first_ATtoken -g -u output, because some of them are clearly not claim transactions and many of them were created even before the deck was spawned.

All transactions to the gateway address are gateway transactions where you could claim tokens for. So if the address was used before for other purposes, then all the transactions that went to it are gateway transactions.

In theory, the issuer of an AT token could "cheat" spending coins all the time to his own AT token gateway address, and thus claiming tokens while he will benefit from that too. That's a problem of all ICO-style distributions so we can do nothing about it.

He could even spend coins to the AT address and then re-spend them again to the address claiming tokens again and so on. This however would be detected easily by those willing to get these tokens who would for sure not tolerate this behaviour.

---

By the way: I'm strongly suspecting that we can close this topic, because I think most related bugs are already fixed and the other main questions were answered here?

[buhtignew]

I think the first couple of errors, when you got the "red" PeerAssets general error should now be solved, as they were also occurring in another cases.

I was trying to check the firsts command mentioned in the OP and have discovered that probably the transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u command mentioned there doesn't work as expected.
In fact I've run it from two different main addresses (specifically mjXqewNUxUCW4v6bQ7CzhRAVMLHmQ6ktxN and myHPHhnncUaiFQGqN1FK2qFtwcfPE4Bkqc) and both outputs contain the claim transaction caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a which I've used in the beginning of this thread for my testing.
But the transaction show caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a -s output is:

{
    'inputs': [
        {'sender': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 20.0}
    ],
    'outputs': [
        {'receivers': ['mpF9FcfSps5jPSG2vDdGVF883xNFez1UGT'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['n1xC4Dkp48mbsJsMV3yYEho6adBmbjgqNV'], 'value': 0.66},
        {'receivers': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 19.31}
    ],
    'blockheight': 60670
}

So the sender is not one of the two addresses I've used as main above.
I assume that in case of the transaction list DECK [-o [ORIGIN_ADDRESS]] -g [-u] Usage mode the clause "In the case -o is given without address, the main address is used." doesn't work as intended.

[d5000]

I don't exactly understand what you mean (if I understand wrong then please elaborate ...) but I think the potentially confusing thing here is simply that if you use transaction list DECK -g -u without -o then you will see all gateway transactions your wallet knows about, so transaction caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a will be shown, as clarified in the help.

Or have you used the command with -o but forgot to mention it in your post? In this case I'd say it's a bug but would need more information.

[buhtignew]

Sorry you are right, I haven't paid enough attention to the line that I myself have cited:
The -o is necessary if one wants to see the results for the main address. It seemed to me that without the address and without the -o flag the main address would be used.
I'm not closing this issue yet, because I want to re-check everything again.
If there is no question on my side, I'll just close.

[buhtignew]

All transactions to the gateway address are gateway transactions where you could claim tokens for.

I've set n3MtPoPaAREU5GEhAErBPuju83bVog2opz address as main.
Then I've run transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -o -g -u and got the following output

Searching transactions (this can take several minutes) ...
54 unclaimed total transactions to address n3MtPoPaAREU5GEhAErBPuju83bVog2opz in this wallet.
Showing only transactions sent from the following address: n3MtPoPaAREU5GEhAErBPuju83bVog2opz
{
    'txid': 'caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a',
    'value': 19.31,
    'outputs': [3],
    'height': 60670
}
{
    'txid': '1008fea9dc5d1117c4f371cfbaaa835acc2390ae754c536cdcd0b1c0c89b3d0f',
    'value': 0.8,
    'outputs': [1],
    'height': 156823
}
{
    'txid': 'efe3ab74f01cb560571320b5f2dab69d09d9dadb737c17d0c0fac6a784dbab13',
    'value': 0.77,
    'outputs': [2, 3],
    'height': 156895
}
{
    'txid': '09e04a9ff7ef2b8218ff3a5c4ea5320b00d2f2151b8c0747b9f5bf68e8d3be78',
    'value': 0.01,
    'outputs': [2],
    'height': 480421
}
....

Then I've tried to claim some transaction that, if understand it right, wasn't originally meant as the burn transactions for that ATToken deck.

For instance: attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a, attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 efe3ab74f01cb560571320b5f2dab69d09d9dadb737c17d0c0fac6a784dbab13 and attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 09e04a9ff7ef2b8218ff3a5c4ea5320b00d2f2151b8c0747b9f5bf68e8d3be78.
For all the three transactions I've got the following error:

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

With the -d flag the output is as following:

 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 114, in claim
    ei.run_command(self.__claim, **kwargs)
  File "~/.local/lib/python3.12/site-packages/pacli/extended_interface.py", line 34, in run_command
    result = c(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/at_classes.py", line 146, in __claim
    asset_specific_data, amount, receiver = au.create_at_issuance_data(deck, txid, Settings.key.address, amounts=amounts, receivers=receiver_list, payto=payto, payamount=dec_payamount, debug=debug, force=force)
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pacli/at_utils.py", line 192, in create_at_issuance_data
    if deck.at_address in output["scriptPubKey"]["addresses"]: # changed from tracked_address
                          ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
KeyError: 'addresses'

While when I've run attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 1008fea9dc5d1117c4f371cfbaaa835acc2390ae754c536cdcd0b1c0c89b3d0f everything went smoothly and I was able to produce the claim transaction 5fd0950a422ce67d9805ad09359b9ee9e8f260cbe84bcbcef751dc473d254cc9.

What's wrong with the 3 transactions mentioned above?

Update:
I've also tried to claim tokens for the above mentioned claim transaction 5fd0950a422ce67d9805ad09359b9ee9e8f260cbe84bcbcef751dc473d254cc9 since its transaction show 5fd0950a422ce67d9805ad09359b9ee9e8f260cbe84bcbcef751dc473d254cc9 -s outputs as following:

{
    'inputs': [
        {'sender': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 60.24}
    ],
    'outputs': [
        {'receivers': ['n4di1EHkFnSGYpJCLNpHfheAPhuTm8VG2j'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 60.2}
    ],
    'blockheight': 526705
}

and I can see it with transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -o -g -u | grep 5fd0950a422ce67d9805ad09359b9ee9e8f260cbe84bcbcef751dc473d254cc9.
But the attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 5fd0950a422ce67d9805ad09359b9ee9e8f260cbe84bcbcef751dc473d254cc9 command has provided me the same error as above:

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

_

So if the address was used before for other purposes, then all the transactions that went to it are gateway transactions.

Even for the transactions that were created before the deck spawn?
Does it mean that for our PoB token when we launch it people will be able to claim their PoB token for the burn transactions they did long time ago?

[d5000]

Thank you for the output with --debug, I saw the problem now and fixed it with commit 574deb6. Actually claiming in the previous version would not have worked with outputs with OP_RETURN outputs (the ones you see in the transaction show -s view with the "empty" receiver list). This was the reason why in some cases it worked and in some others not.

Even for the transactions that were created before the deck spawn?
Does it mean that for our PoB token when we launch it people will be able to claim their PoB token for the burn transactions they did long time ago?

If the token has no start deadline, then all PoB transactions from the genesis block on are valid for tokens.

Just for this purpose of course the start and end deadline feature for PoB and AT tokens was implemented, so the official PoB token could have a start deadline near the deck spawn to prevent to dilute it too much. I'm still undecided on this, both approaches have pros and cons, should be discussed in a dedicated thread once launch approaches.

UPDATE: Pushed commit after re-checking that claiming for transactions with OP_RETURN outputs works now.

[buhtignew]

Thank you for the output with --debug, I saw the problem now and fixed it with commit 574deb6. Actually claiming in the previous version would not have worked with outputs with OP_RETURN outputs (the ones you see in the transaction show -s view with the "empty" receiver list). This was the reason why in some cases it worked and in some others not.

I've tested attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a, attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 efe3ab74f01cb560571320b5f2dab69d09d9dadb737c17d0c0fac6a784dbab13 and attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 09e04a9ff7ef2b8218ff3a5c4ea5320b00d2f2151b8c0747b9f5bf68e8d3be78 mentioned in my previous post and for all the three commands I'm getting:

Error: Duplicate. You already have claimed the coins from this transaction successfully.

However I've made some check in my logs it doesn't seem to me to have claimed them after you've published the new upgrade.
Is it possible that despite the error message I was getting the claim transaction was executed by the code?

The attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 5fd0950a422ce67d9805ad09359b9ee9e8f260cbe84bcbcef751dc473d254cc9 command has produced a regular claim transaction f97b8580523f005813e745cd9dc8d4c51a5700188f23bc2252e01ecc7a4c244b
_

If the token has no start deadline, then all PoB transactions from the genesis block on are valid for tokens.

I've tested whether it's possible to claim tokens for the burn transaction occurred earlier than the initial block of the deck. For that purpose I've created the deck `my3` with the startblock `538869` and being on the main address `n3MtPoPaAREU5GEhAErBPuju83bVog2opz` and using the transaction `1a7fb3b69cde609467e5067e8573a189d6277aa9d71e0ddf8784d44fb480c931` which was created on the block `518555`, picked from my `transaction list -b` output, I've run `pobtoken claim 5b15a52c08554c2f3859fb274338622d52ce6702e2fcaca73e63ab445f1c29f1 1a7fb3b69cde609467e5067e8573a189d6277aa9d71e0ddf8784d44fb480c931` and have produced the claim transaction `0a130476b6d86ed0823f328bb6a8d4320f45fe1569f019c0d2674f359e8bc6a2`, but my `token balances -t 5b15a52c08554c2f3859fb274338622d52ce6702e2fcaca73e63ab445f1c29f1` is still 0.

I'd like to make the same test with the ATtoken, but because of the issue #185 I'm not able to for the moment.

[d5000]

Your transactions were already claimed indeed (from the output of transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -c):

• caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a => claimed by transaction 9647946b2f5ad02fb8f90742ba7eab32dec803240a5d13ec4ca97c7023a260a4 (block height 527476)
• efe3ab74f01cb560571320b5f2dab69d09d9dadb737c17d0c0fac6a784dbab13 => claimed by transaction b2dc223e37171c7dac23c75e3c0a4d11a2d39eb5a8d356daaedb89de6b897ab5 (block height 527476)
• 09e04a9ff7ef2b8218ff3a5c4ea5320b00d2f2151b8c0747b9f5bf68e8d3be78 => claimed by transaction cfebf8d2908d03a6fbde37f6890f56931b7c79b6925c42cd53247b35a28a84fc (block height 527476)

Is it possible that despite the error message I was getting the claim transaction was executed by the code?

At least for the error you provided me the --debug output in this post I think it's not possible, because it was generated in a step where the data for the claim transaction is collected.

Your post about the error was also before the block these transactions were included in.

Block 527476 was very likely after I provided that upgrade. I see my comment was on August 23, and the block including these transaction was on August 24. Maybe you claimed these transactions correctly after my upgrade?

I've tested whether it's possible to claim tokens for the burn transaction occurred earlier than the initial block of the deck.

As expected the balance is 0 because the referenced burn transaction was confirmed about 20000 blocks before the deck's startblock.

Do you mean you want a warning for that so the claim tx is not created? That wold be a feature request, please open a new issue for that or even better put it into the "Nice to have..." issue.

---

By the way: I've commented now on almost all of the issues that were still open. There are several I consider fixed or completed. Do you want me to close them? I left them open only for the case you wanted to review them, at least on some I don't really need new testing steps.

[buhtignew]

Maybe you claimed these transactions correctly after my upgrade?

Probably I did, but I'm not able to find that claim transactions in my logs. I'm closing this issue for the moment. Should we have some additional evidence there is an issue with this transactions we'll discuss it separately.

Do you mean you want a warning for that so the claim tx is not created? That wold be a feature request, please open a new issue for that or even better put it into the "Nice to have..." issue.

Yes I think we should add a compatibility check for the pobtoken claim command, I'm putting it into "Nice to have...".

By the way: I've commented now on almost all of the issues that were still open. There are several I consider fixed or completed. Do you want me to close them? I left them open only for the case you wanted to review them, at least on some I don't really need new testing steps.

I apologize, for I've been busy for about 10 days in the end of the August/beginning of September and as result I wasn't still be able to see all of your replies.
At the moment I'm finishing the work on the issues I've been working before I left (those to which you are replying these days) and then I'll begin working on the queue of the other replies I've got from you.
Please don't close them, I'd like to work on them thoroughly.