pobtoken claim with the -l flag

[buhtignew]

While my slimcoind was stuck at the block 485344 I've run pobtoken claim ATTokenNewSpec2_local f7d94d3391230e997c0120cab4ea6a8e02fe06408ddd0adc1fc1c4a9d70ed08c -l 485355 command and have produced the following output:

Using deck stored locally with label ATTokenNewSpec2_local and ID fb93cce7aceb9f7fda228bc0c0c2eca8c56c09c1d846a04bd6a59cae2a895974.
Looking for chain reorganizations ...
Last checkpoint found: height 485339 hash 8c0922683cacca87bb6d133af8e02550c37ac1a1f6bfe3828717e308d29f454e
No reorganization found. Everything seems to be ok.
Storing hash of block as a checkpoint to control re-orgs.
 Height: 485344 Hash: a54e7d64912d3a8cb3ffee1f2f986993c25eb2282a4a40902bcda447bdd80a3d
Stored checkpoint:
Label: 485344
Value: a54e7d64912d3a8cb3ffee1f2f986993c25eb2282a4a40902bcda447bdd80a3d
{
    'txid': 'f5be5c9ffe46fc4dbc209e786644ab8316bd85f25217abdd7a24db9eb4c89de6'
}
hex: 010000002faa8d6603474b7f37aa0a3c9dcab265d104c4dec79a00cb42bbea93b2199137a2bfa4f1b8020000006a47304402207b23e9ecca836bdbab51eabcfc22e8ffe33b05a00acb331bd4a079033dbf9e1502204cd00b0bd337a39e760f1c3ba282270b1c853c93ffc64b2bf434e88a729b1e9301210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffff474b7f37aa0a3c9dcab265d104c4dec79a00cb42bbea93b2199137a2bfa4f1b8030000006a4730440220216e2522d5c046106a7de6fd73c1e55cfbf97d064d75d8347988aa030a47796902202a8eb3b2f0fb0d8687464f9ba0e5345c737f3a5a59918e14b485529301c22c3601210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffff474b7f37aa0a3c9dcab265d104c4dec79a00cb42bbea93b2199137a2bfa4f1b8040000006b483045022100918e61f37a070a2e6d2ade13dff275c18a06bcdc5337b29823a1af475054f80502201d668f5227bb7df8242994d5eec1413ff811512dcddae3a046fcded0ca2a0c2901210222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffff0410270000000000001976a9143b73a98afce267f672a4c70c6c2ea108b2d0138d88ac10270000000000002f6a2d0801120387ad4b180422220a20f7d94d3391230e997c0120cab4ea6a8e02fe06408ddd0adc1fc1c4a9d70ed08c10270000000000001976a914ef9bc46b51278e60631ca709fd21bf9d2d0abf1588ac3023ae08000000001976a914b5a2ced9afd823cb142607e2d4e7e979cb73b87f88aceb670700

Then I've seen with the transaction list fb93cce7aceb9f7fda228bc0c0c2eca8c56c09c1d846a04bd6a59cae2a895974 -b -u command that the transaction was still considered unclaimed so without restarting slimcoind (so it was still at the block 485344) I've run pobtoken claim ATTokenNewSpec2_local f7d94d3391230e997c0120cab4ea6a8e02fe06408ddd0adc1fc1c4a9d70ed08c --payto new_after_refill8 and got the following output:

Using deck stored locally with label ATTokenNewSpec2_local and ID fb93cce7aceb9f7fda228bc0c0c2eca8c56c09c1d846a04bd6a59cae2a895974.
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 141, 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 398, in advanced_card_transfer
    issue_tx = pa.card_transfer(provider=provider,
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pypeerassets/__main__.py", line 271, in card_transfer
    script=p2pkh_script(address=addr,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/pypeerassets/transactions.py", line 241, in p2pkh_script
    addr = Address.from_string(network=network_params,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/btcpy/structs/address.py", line 61, in from_string
    return ClassicAddress.decode(string, network=network)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/btcpy/structs/address.py", line 70, in decode
    return cls.get_codec().decode(string, network=network)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/btcpy/lib/codecs.py", line 61, in decode
    hashed_data = bytearray(b58decode_check(string))[1:]
                            ^^^^^^^^^^^^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/btcpy/lib/base58.py", line 67, in b58decode_check
    result = b58decode(v)
             ^^^^^^^^^^^^
  File "~/.local/lib/python3.12/site-packages/btcpy/lib/base58.py", line 46, in b58decode
    acc += p * alphabet.index(c)
               ^^^^^^^^^^^^^^^^^
ValueError: substring not found

(I don't know whether this error message is important to consider though).

Then I've restarted slimcoind and it got updated. I've looked into transaction show f5be5c9ffe46fc4dbc209e786644ab8316bd85f25217abdd7a24db9eb4c89de6 -s output:

{
    'inputs': [
        {'sender': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 0.01},
        {'sender': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 0.01},
        {'sender': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 145.65}
    ],
    'outputs': [
        {'receivers': ['mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 145.63}
    ],
    'blockheight': 485353
}

And have seen that the transaction was confirmed earlier the block I've set up originally with the -l flag.

By the way what is the format to set up the lock time? _ Update 10-07-2024

I've burned other coins using pobtoken burn_coins 3.21 command and have produced transaction 5f72d5894fa789920ca2073b22ee8145069f0c9c0e54fa05fd39269dba528077. Later on when my slimcoind was on the block 485804 I've run pobtoken claim ATTokenNewSpec2_local 5f72d5894fa789920ca2073b22ee8145069f0c9c0e54fa05fd39269dba528077 -l 0 and have produced transaction bb11f5a66a702432f1d9fa4a3c3e281bb5d53717ec906e80bae3f224fac35eeb. While my slimcoind was still on the same block I've launched pobtoken claim ATTokenNewSpec2_local 5f72d5894fa789920ca2073b22ee8145069f0c9c0e54fa05fd39269dba528077 -l 100 from the same main address, n3MtPoPaAREU5GEhAErBPuju83bVog2opz, and have produced the transaction 4ac754e9d34d025babd3d7c6cc411e0cb15f8c8008c8f5910ba6de34fb224c8c. Then I've restarted slimcoind and both transactions were confirmed at the block 485808. Here is the transaction show bb11f5a66a702432f1d9fa4a3c3e281bb5d53717ec906e80bae3f224fac35eeb -s output:

{
    'inputs': [
        {'sender': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 165.48}
    ],
    'outputs': [
        {'receivers': ['mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 165.44}
    ],
    'blockheight': 485808
}

and here is the transaction show 4ac754e9d34d025babd3d7c6cc411e0cb15f8c8008c8f5910ba6de34fb224c8c -s output:

{
    'inputs': [
        {'sender': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 100.73}
    ],
    'outputs': [
        {'receivers': ['mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik'], 'value': 0.01},
        {'receivers': [], 'value': 0.01},
        {'receivers': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'value': 0.01},
        {'receivers': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP'], 'value': 100.69}
    ],
    'blockheight': 485808
}

After that I was not able to produce claim transactions from the same burn transaction (5f72d5894fa789920ca2073b22ee8145069f0c9c0e54fa05fd39269dba528077). The PoB balance of the address n3MtPoPaAREU5GEhAErBPuju83bVog2opz has been increased by the expected balance 321 PoB tokens. My token transfers ATTokenNewSpec2_local -s output shows the transaction bb11f5a66a702432f1d9fa4a3c3e281bb5d53717ec906e80bae3f224fac35eeb but doesn't show the transaction 4ac754e9d34d025babd3d7c6cc411e0cb15f8c8008c8f5910ba6de34fb224c8c.

[d5000]

1. The reason for the first error you got was: the combination --payto without --payamount didn't work due to a bug in a code branch. Even if it was not mentioned in the help, the function supports this (in this case all is paid to the address mentioned after --payto). So I fixed the branching and now it should work (pre-tested here, it works).

2. Improved error catching (all errors should now be shown in red, to get details use --debug).

3. By the way what is the format to set up the lock time?

Locktime should be the same than in Bitcoin, i.e. under 500000000 (500 million) it's assumed to be a number of blocks, and from 500000000 on it should be Unix time.

4.

And have seen that the transaction was confirmed earlier the block I've set up originally with the -l flag.

Strange. The locktime was correctly set (you can see it in slimcoind getrawtransaction 37c876eee0a186a1fe1536bb00c2b9e203b94991da83f0b85ac8098ae5cbe96d 1 but you're correct, it was confirmed two blocks earlier. Looks like a Slimcoin bug, can't do anything about that :(

I generally think we should discourage the use of the Locktime parameter. For now I added "not recommended, buggy in SLM" to the help. I will think about eliminating it completely for PoBtoken, ATtoken and dPoDtoken commands (in some, I saw I already trashed it) and leave it intact only for vanilla commands. Will have to think if there are any significant use cases.

5. Regarding low locktimes like 0 and 100, as far as I understand the mechanism this would be simply ignored, as the blocks 0 and 100 have passed a long time ago.

6. Regarding the test you made with two transactions in the same block the result is expected (even if you put locktime values on them). One of both transactions - the one later in the block - will be ignored (and not even shown by token transfers) because it will be deemed as "duplicate". You can see with the getblock command that the tx starting with bb1 ... was indeed earlier than the tx starting with 4ac... .

While a claim transaction was not confirmed, you can still claim but the transaction will be invalid.

Commits of the changes is: 13a41bc

Can be closed if there are no open questions nor problems.

[buhtignew]

Strangely enough my slimcoind getrawtransaction 37c876eee0a186a1fe1536bb00c2b9e203b94991da83f0b85ac8098ae5cbe96d 1 output is:

error: {"code":-5,"message":"No information available about transaction"}

both on client as on server. _ If I run pobtoken claim ATTokenNewSpec2_local f7d94d3391230e997c0120cab4ea6a8e02fe06408ddd0adc1fc1c4a9d70ed08c --payto new_after_refill8 I'm getting:

  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 132, 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 162, 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)
                                                                                                                                    ^^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'receiver_list' where it is not associated with a value

Since the transaction f7d94d3391230e997c0120cab4ea6a8e02fe06408ddd0adc1fc1c4a9d70ed08c is already claimed, as per OP, by picking the unclaimed transaction aa1cbf418cb440b32e84e53002602aef616a5873c0fecaab8785c9b6ad377350 from my transaction list ATTokenNewSpec2_local -b -u output and running pobtoken claim ATTokenNewSpec2_local aa1cbf418cb440b32e84e53002602aef616a5873c0fecaab8785c9b6ad377350 --payto new_after_refill8 I'm getting the same error. The same if I replace the label of the --payto address with the address itself (like this pobtoken claim ATTokenNewSpec2_local aa1cbf418cb440b32e84e53002602aef616a5873c0fecaab8785c9b6ad377350 --payto mkxLRzTvrEpPbFxkp4tnRGXQ6UKcKH25TA). _

I will think about eliminating it completely for PoBtoken, ATtoken and dPoDtoken commands

Probably it would make sense. I thought it was needed for the dex operations, but if there no particular reason to keep it getting rid of it would make the command's usage easier.

[d5000]

Uh, I confused the block hash with the tx hash, sorry. What you check to see the locktime is of course slimcoind getrawtransaction f5be5c9ffe46fc4dbc209e786644ab8316bd85f25217abdd7a24db9eb4c89de6 1. :)

37c876eee0a186a1fe1536bb00c2b9e203b94991da83f0b85ac8098ae5cbe96d is the block where it was confirmed. So with slimcoind getblock 37c876eee0a186a1fe1536bb00c2b9e203b94991da83f0b85ac8098ae5cbe96d you can see the height.

---

Second error (UnboundLocalError) was a small mistake I made when fixing the issue with the -r flag of that command. Fixed in commit 5705843.

Having thought a bit about use cases of the Locktime parameter, the main use case I see is, apart from one command of the dex, the burn_coins/create_tx commands in the case of PoB or AT tokens with block limits (i.e. where only burn transactions from a certain block on are taken into account). In addition, the claim command of dPoD tokens also could benefit from it because claiming is only allowed from a certain block on.

For AT/PoB tokens claiming I see no benefit for the Locktime parameter instead, because once the transaction is confirmed you can claim. So I'll remove the parameter from attoken/pobtoken claim.

I hope this can be closed now :)