Closed buhtignew closed 2 months ago
You can do pacli transaction list DECK -c | grep BURN_TXID
. A dedicated mode does not exist for this.
It would be possible to add this mode without new flag for transaction list
if in -c
mode we disallow using the origin address as positional argument (-o
would then have to be used always). If you think it's helpful, it's an easy addition.
I think it's not a big deal if we introduce the -o
flag in this case, because the link between the burning transactions and the claim transactions seems to be missing, or at least it requires some additional work to establish that relation.
What would be the usage mode in this case?
Something like transaction list DECK [burning_or_claiming_trasaction_id] [-o ORIGIN_ADDRESS] -c
?
I've decided to integrate that function in the transaction show
command instead, as only one transaction will be shown.
Command is transaction show DECK -c TXID
.
As I'm currently working on another function which is incomplete I have still not pushed the commit.
Edit: Pushed. Commit is ad9449c. Includes also a new debugging function attoken/pobtoken check_claim
.
I've tested transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c 0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa663
for the burn transaction mentioned in the OP and got a long list of transactions:
[{'TX ID': 'c5d7ec7fafbbe814dd625c3d5ff46971fbc3c864deae0397b3a125fa44e47cf4', 'Burn transaction': '5351ad8a5723456d56e72c4d26eaf936d27eacf4385748da9d5f65946e3a34f8', 'Token amount(s)': [1.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491604}, {'TX ID': 'b296982f1e2a698e77a727046885e537abda59613919431487379d85b2b3429e', 'Burn transaction': '7327b93a674b843b5551e460fdc6fdf71876155a4f363b3d1d86671c906028e0', 'Token amount(s)': [2.0], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491555}, {'TX ID': 'db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934', 'Burn transaction': 'a45563c27360f25637f0cc12ca4d4d9b44849656ac3f56ce37125f220aa77331', 'Token amount(s)': [1.0], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 490772}, {'TX ID': '0dc2575496706449469425e753c042cb29ab83ad0052bc5e88a785cd294eb601', 'Burn transaction': '0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa6639', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491569}, {'TX ID': '848569c0a447cb6e439a22ea90a21065cabae28f42cbc3968af3dea83a883910', 'Burn transaction': '204a5a2a07538a8ef6fa92fb1592c78aefbd6832c3278af897af60bf5f79a046', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491597}, {'TX ID': 'fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63', 'Burn transaction': 'bcc8bf6db27a6a2de191ed7f31dddd4dd170eab34688147767961786a88124eb', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491555}, {'TX ID': '8bf6ee9a80820439c10345d931fe3c25484b58b63414fa425588bda99ee819f6', 'Burn transaction': '1e6d5cac17511fd76e4a672d74becff65fc1de687da5f3f97fc0e8abfad3891f', 'Token amount(s)': [1.0], 'Receiver(s)': ['mwzox84gMy8TKdeBftrfpmwGVZnJJdaReg'], 'Block height': 506682}]
[
{
'TX ID': 'c5d7ec7fafbbe814dd625c3d5ff46971fbc3c864deae0397b3a125fa44e47cf4',
'Burn transaction': '5351ad8a5723456d56e72c4d26eaf936d27eacf4385748da9d5f65946e3a34f8',
'Token amount(s)': [1.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491604
},
{
'TX ID': 'b296982f1e2a698e77a727046885e537abda59613919431487379d85b2b3429e',
'Burn transaction': '7327b93a674b843b5551e460fdc6fdf71876155a4f363b3d1d86671c906028e0',
'Token amount(s)': [2.0],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491555
},
{
'TX ID': 'db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934',
'Burn transaction': 'a45563c27360f25637f0cc12ca4d4d9b44849656ac3f56ce37125f220aa77331',
'Token amount(s)': [1.0],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 490772
},
{
'TX ID': '0dc2575496706449469425e753c042cb29ab83ad0052bc5e88a785cd294eb601',
'Burn transaction': '0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa6639',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491569
},
{
'TX ID': '848569c0a447cb6e439a22ea90a21065cabae28f42cbc3968af3dea83a883910',
'Burn transaction': '204a5a2a07538a8ef6fa92fb1592c78aefbd6832c3278af897af60bf5f79a046',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491597
},
{
'TX ID': 'fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63',
'Burn transaction': 'bcc8bf6db27a6a2de191ed7f31dddd4dd170eab34688147767961786a88124eb',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491555
},
{
'TX ID': '8bf6ee9a80820439c10345d931fe3c25484b58b63414fa425588bda99ee819f6',
'Burn transaction': '1e6d5cac17511fd76e4a672d74becff65fc1de687da5f3f97fc0e8abfad3891f',
'Token amount(s)': [1.0],
'Receiver(s)': ['mwzox84gMy8TKdeBftrfpmwGVZnJJdaReg'],
'Block height': 506682
}
]
I've also tested the transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63
using the claim transaction mentioned in the OP and the output was:
[{'TX ID': '8bf6ee9a80820439c10345d931fe3c25484b58b63414fa425588bda99ee819f6', 'Burn transaction': '1e6d5cac17511fd76e4a672d74becff65fc1de687da5f3f97fc0e8abfad3891f', 'Token amount(s)': [1.0], 'Receiver(s)': ['mwzox84gMy8TKdeBftrfpmwGVZnJJdaReg'], 'Block height': 506682}, {'TX ID': 'b296982f1e2a698e77a727046885e537abda59613919431487379d85b2b3429e', 'Burn transaction': '7327b93a674b843b5551e460fdc6fdf71876155a4f363b3d1d86671c906028e0', 'Token amount(s)': [2.0], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491555}, {'TX ID': 'c5d7ec7fafbbe814dd625c3d5ff46971fbc3c864deae0397b3a125fa44e47cf4', 'Burn transaction': '5351ad8a5723456d56e72c4d26eaf936d27eacf4385748da9d5f65946e3a34f8', 'Token amount(s)': [1.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491604}, {'TX ID': 'db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934', 'Burn transaction': 'a45563c27360f25637f0cc12ca4d4d9b44849656ac3f56ce37125f220aa77331', 'Token amount(s)': [1.0], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 490772}, {'TX ID': '848569c0a447cb6e439a22ea90a21065cabae28f42cbc3968af3dea83a883910', 'Burn transaction': '204a5a2a07538a8ef6fa92fb1592c78aefbd6832c3278af897af60bf5f79a046', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491597}, {'TX ID': '0dc2575496706449469425e753c042cb29ab83ad0052bc5e88a785cd294eb601', 'Burn transaction': '0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa6639', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491569}, {'TX ID': 'fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63', 'Burn transaction': 'bcc8bf6db27a6a2de191ed7f31dddd4dd170eab34688147767961786a88124eb', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491555}]
[
{
'TX ID': '8bf6ee9a80820439c10345d931fe3c25484b58b63414fa425588bda99ee819f6',
'Burn transaction': '1e6d5cac17511fd76e4a672d74becff65fc1de687da5f3f97fc0e8abfad3891f',
'Token amount(s)': [1.0],
'Receiver(s)': ['mwzox84gMy8TKdeBftrfpmwGVZnJJdaReg'],
'Block height': 506682
},
{
'TX ID': 'b296982f1e2a698e77a727046885e537abda59613919431487379d85b2b3429e',
'Burn transaction': '7327b93a674b843b5551e460fdc6fdf71876155a4f363b3d1d86671c906028e0',
'Token amount(s)': [2.0],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491555
},
{
'TX ID': 'c5d7ec7fafbbe814dd625c3d5ff46971fbc3c864deae0397b3a125fa44e47cf4',
'Burn transaction': '5351ad8a5723456d56e72c4d26eaf936d27eacf4385748da9d5f65946e3a34f8',
'Token amount(s)': [1.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491604
},
{
'TX ID': 'db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934',
'Burn transaction': 'a45563c27360f25637f0cc12ca4d4d9b44849656ac3f56ce37125f220aa77331',
'Token amount(s)': [1.0],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 490772
},
{
'TX ID': '848569c0a447cb6e439a22ea90a21065cabae28f42cbc3968af3dea83a883910',
'Burn transaction': '204a5a2a07538a8ef6fa92fb1592c78aefbd6832c3278af897af60bf5f79a046',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491597
},
{
'TX ID': '0dc2575496706449469425e753c042cb29ab83ad0052bc5e88a785cd294eb601',
'Burn transaction': '0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa6639',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491569
},
{
'TX ID': 'fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63',
'Burn transaction': 'bcc8bf6db27a6a2de191ed7f31dddd4dd170eab34688147767961786a88124eb',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491555
}
]
I've also tested the command with a casual sting balbalagaga
(transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c balbalagaga
) and got:
[{'TX ID': '0dc2575496706449469425e753c042cb29ab83ad0052bc5e88a785cd294eb601', 'Burn transaction': '0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa6639', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491569}, {'TX ID': 'b296982f1e2a698e77a727046885e537abda59613919431487379d85b2b3429e', 'Burn transaction': '7327b93a674b843b5551e460fdc6fdf71876155a4f363b3d1d86671c906028e0', 'Token amount(s)': [2.0], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491555}, {'TX ID': 'c5d7ec7fafbbe814dd625c3d5ff46971fbc3c864deae0397b3a125fa44e47cf4', 'Burn transaction': '5351ad8a5723456d56e72c4d26eaf936d27eacf4385748da9d5f65946e3a34f8', 'Token amount(s)': [1.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491604}, {'TX ID': 'fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63', 'Burn transaction': 'bcc8bf6db27a6a2de191ed7f31dddd4dd170eab34688147767961786a88124eb', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491555}, {'TX ID': '8bf6ee9a80820439c10345d931fe3c25484b58b63414fa425588bda99ee819f6', 'Burn transaction': '1e6d5cac17511fd76e4a672d74becff65fc1de687da5f3f97fc0e8abfad3891f', 'Token amount(s)': [1.0], 'Receiver(s)': ['mwzox84gMy8TKdeBftrfpmwGVZnJJdaReg'], 'Block height': 506682}, {'TX ID': '848569c0a447cb6e439a22ea90a21065cabae28f42cbc3968af3dea83a883910', 'Burn transaction': '204a5a2a07538a8ef6fa92fb1592c78aefbd6832c3278af897af60bf5f79a046', 'Token amount(s)': [0.111], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 491597}, {'TX ID': 'db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934', 'Burn transaction': 'a45563c27360f25637f0cc12ca4d4d9b44849656ac3f56ce37125f220aa77331', 'Token amount(s)': [1.0], 'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'], 'Block height': 490772}]
[
{
'TX ID': '0dc2575496706449469425e753c042cb29ab83ad0052bc5e88a785cd294eb601',
'Burn transaction': '0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa6639',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491569
},
{
'TX ID': 'b296982f1e2a698e77a727046885e537abda59613919431487379d85b2b3429e',
'Burn transaction': '7327b93a674b843b5551e460fdc6fdf71876155a4f363b3d1d86671c906028e0',
'Token amount(s)': [2.0],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491555
},
{
'TX ID': 'c5d7ec7fafbbe814dd625c3d5ff46971fbc3c864deae0397b3a125fa44e47cf4',
'Burn transaction': '5351ad8a5723456d56e72c4d26eaf936d27eacf4385748da9d5f65946e3a34f8',
'Token amount(s)': [1.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491604
},
{
'TX ID': 'fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63',
'Burn transaction': 'bcc8bf6db27a6a2de191ed7f31dddd4dd170eab34688147767961786a88124eb',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491555
},
{
'TX ID': '8bf6ee9a80820439c10345d931fe3c25484b58b63414fa425588bda99ee819f6',
'Burn transaction': '1e6d5cac17511fd76e4a672d74becff65fc1de687da5f3f97fc0e8abfad3891f',
'Token amount(s)': [1.0],
'Receiver(s)': ['mwzox84gMy8TKdeBftrfpmwGVZnJJdaReg'],
'Block height': 506682
},
{
'TX ID': '848569c0a447cb6e439a22ea90a21065cabae28f42cbc3968af3dea83a883910',
'Burn transaction': '204a5a2a07538a8ef6fa92fb1592c78aefbd6832c3278af897af60bf5f79a046',
'Token amount(s)': [0.111],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 491597
},
{
'TX ID': 'db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934',
'Burn transaction': 'a45563c27360f25637f0cc12ca4d4d9b44849656ac3f56ce37125f220aa77331',
'Token amount(s)': [1.0],
'Receiver(s)': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz'],
'Block height': 490772
}
]
_
I've run pobtoken check-claim 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa663
and got
Error: Label '0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa663' not found. Please provide a valid deck.
Then I've looked better into the help
and have inverted the transaction id with the deck (like this pobtoken check-claim 0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa663 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7
) and got:
'Complete transaction:'
{'code': -5, 'message': 'No information available about transaction'}
General error raised by PeerAssets. Check if your input is correct.
Thus I've understood that there is no such claim transaction which is true, because I've been using the corresponding burn transaction.
So I've run pobtoken check-claim fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7
and got a long output that contains the right burning transaction which, however, is mentioned as donation_txid
and Spending txid
.
Another thing I've noticed is the final conclusion in the output:
Claimed value wrong: expected 111.3000, claimed 111.
Claim transactions appears invalid, contains 1 errors.
Which is not exactly true, since the transaction went through.
But maybe we doesn't need to focus on this since we've already put the checks to avoid this situations in the future.
In case you consider it important maybe we can write something like: Claiming transaction is valid, but contains 1 warning
.
_
I think it would be nice to introduce a flag for this or for another command that would help finding just the burning transaction by inputting the relative claiming transaction.
Does the claiming transaction necessarily need the DECK to derive its burning transaction?
If so IDK, maybe it would make sense to consider inverting the DECK and the TX_ID as positional arguments of the `pobtoken check_claim command?
The long output was of course a bug, I don't know how I missed that one actually. Fixed in commit 25a9d9e.
I think it would be nice to introduce a flag for this or for another command that would help finding just the burning transaction by inputting the relative claiming transaction.
I agree. I now changed the command a bit, for this purpose:
transaction show DECK -c CLAIMTX
shows the claim transaction, corresponding burn, donation or gateway transaction and other data. This should fit your request.
transaction show DECK -c -t BURNTX/GATEWAYTX/DONATIONTX
works now like the mode with only -c TX
before, i.e. you enter the burn/gateway/donation tx after -t
and get the corresponding claim transaction (if it exists).
Claimed value wrong: expected 111.3000, claimed 111.
Also a bug. Fixed. (commit 7602f5a)
Does the claiming transaction necessarily need the DECK to derive its burning transaction?
The deck is necessary for other reasons. However, it can also be derived from the claim transaction itself, which is slower but maybe it's worth it. I made check_claim a quick and dirty debugging command.
I put this on hold however because the needed function to derive a deck from a claim transaction is in a module I'm reorganizing currently.
I've tried the above mentioned transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c 0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa663
(using the burn transaction) and transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c balbalagaga
(using a casual sequence) and got:
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/extended_classes.py", line 1525, in show
return ei.run_command(self.__show, label_or_idstr, claim=claim, txref=txref, quiet=quiet, structure=structure, decode=decode, txid=id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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/extended_classes.py", line 1534, in __show
txes = eu.show_claims(deck_str=idstr, quiet=quiet, claim_tx=claim)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "~/.local/lib/python3.12/site-packages/pacli/extended_utils.py", line 565, in show_claims
claim = bundle[0]
~~~~~~^^^
IndexError: list index out of range
The correct command transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63
works as expected.
_
I've run transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c -t balbalagaga
, transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c -t fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63
and transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c -t 0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa663
and got:
No claim transactions found.
[]
Which is expected for the first two and not expected for the last one, since in #155 the 0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa663
transaction is mentioned as a burn transaction.
_
Update
I've tested attoken check_claim 4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8 ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58
and got the following output:
'Complete transaction:'
{
'hex':
'01000000f3e1a06602ca60f4e42c393a794a85fc6bf5c0e438bc78965db1879374c2b'
'4698d1387ea41010000006b483045022100a3db675c2aad539542565ac8b31493edef'
'032b0bd5290a90ecbdc415a0057b6002201e9df16f347a118ecd25c0e29cdcd7522c8'
'5f4faec0f3a1e444771e3eac4948b01210222cb84a16ecd0fbb092bd104e3fb0b59db'
'069932a711bfaf7c0c0c7a1b627534ffffffff4675f2c69c1fe381a51376f8da4707f'
'c17ba4187a3f2bbf05d8a8004105b7359010000006b483045022100e46adf29d8234a'
'a70e56a7646eae99445480ad68900a6d81e819aa74bbd53d7f022000d0ab83a4ae008'
'3080865aab82d69252c7b2a9bdb5b35c0d75fd91b3f8ddb4601210222cb84a16ecd0f'
'bb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b627534ffffffff0240420f000'
'00000001976a914ef9bc46b51278e60631ca709fd21bf9d2d0abf1588ac30244c0000'
'0000001976a914b5a2ced9afd823cb142607e2d4e7e979cb73b87f88ac00000000',
'txid': '4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8',
'version': 1,
'time': 1721819829,
'locktime': 0,
'IsBurnTx': False,
'vin': [
{
'txid': '41ea87138d69b4c2749387b15d9678bc38e4c0f56bfc854a793a392ce4f460ca',
'vout': 1,
'scriptSig': {
'asm':
'3045022100a3db675c2aad539542565ac8b31493edef032b0bd5290a90ecb'
'dc415a0057b6002201e9df16f347a118ecd25c0e29cdcd7522c85f4faec0f'
'3a1e444771e3eac4948b01 '
'0222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b6'
'27534',
'hex':
'483045022100a3db675c2aad539542565ac8b31493edef032b0bd5290a90e'
'cbdc415a0057b6002201e9df16f347a118ecd25c0e29cdcd7522c85f4faec'
'0f3a1e444771e3eac4948b01210222cb84a16ecd0fbb092bd104e3fb0b59d'
'b069932a711bfaf7c0c0c7a1b627534'
},
'sequence': 4294967295
},
{
'txid': '59735b1004808a5df0bbf2a38741ba17fc0747daf87613a581e31f9cc6f27546',
'vout': 1,
'scriptSig': {
'asm':
'3045022100e46adf29d8234aa70e56a7646eae99445480ad68900a6d81e81'
'9aa74bbd53d7f022000d0ab83a4ae0083080865aab82d69252c7b2a9bdb5b'
'35c0d75fd91b3f8ddb4601 '
'0222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b6'
'27534',
'hex':
'483045022100e46adf29d8234aa70e56a7646eae99445480ad68900a6d81e'
'819aa74bbd53d7f022000d0ab83a4ae0083080865aab82d69252c7b2a9bdb'
'5b35c0d75fd91b3f8ddb4601210222cb84a16ecd0fbb092bd104e3fb0b59d'
'b069932a711bfaf7c0c0c7a1b627534'
},
'sequence': 4294967295
}
],
'vout': [
{
'value': 1.0,
'n': 0,
'scriptPubKey': {
'asm':
'OP_DUP OP_HASH160 ef9bc46b51278e60631ca709fd21bf9d2d0abf15 '
'OP_EQUALVERIFY OP_CHECKSIG',
'hex': '76a914ef9bc46b51278e60631ca709fd21bf9d2d0abf1588ac',
'reqSigs': 1,
'type': 'pubkeyhash',
'addresses': ['n3MtPoPaAREU5GEhAErBPuju83bVog2opz']
}
},
{
'value': 4.99,
'n': 1,
'scriptPubKey': {
'asm':
'OP_DUP OP_HASH160 b5a2ced9afd823cb142607e2d4e7e979cb73b87f '
'OP_EQUALVERIFY OP_CHECKSIG',
'hex': '76a914b5a2ced9afd823cb142607e2d4e7e979cb73b87f88ac',
'reqSigs': 1,
'type': 'pubkeyhash',
'addresses': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP']
}
}
],
'blockhash': '0000004dffd4394c5dd03be453fe7a060a1e8f670bf0ecfd4e4ba84baf9c6366',
'confirmations': 24112,
'blocktime': 1721819829
}
P2TH address wrong: expected n4di1EHkFnSGYpJCLNpHfheAPhuTm8VG2j, used n3MtPoPaAREU5GEhAErBPuju83bVog2opz
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 188, in check_claim
return ei.run_command(eu.get_claim_tx, txid, deckid, quiet=quiet, debug=debug)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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/extended_utils.py", line 794, in get_claim_tx
print("Spending txid:", donation_txid)
^^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'donation_txid' where it is not associated with a value
The same with another transaction done for another AT deck:
attoken check_claim c3fddd3abc662979dff8ab3424e19f34f59b77cb7277ff2b3e1d0f5d8a5a5018 8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012
.
But surprisingly enough I've also got some output while I've tested the erroneous command
attoken check_claim 8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012 8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012
in which I've mentioned the deck id twice instead of the transaction id:
'Complete transaction:'
{
'hex':
'01000000e439a2660151f2a27ffc00a2334292469705152984cbc4f8892e409e344e7'
'999fde9a712af010000006a4730440220715d8e8663cb46f8c412a11ee6df23fcbb1e'
'da61f34679d1822e44cfb8338ceb02201ea208e1c730088eff8595aa5053d5f5f3a13'
'b4e1355052df833cff459578bb101210222cb84a16ecd0fbb092bd104e3fb0b59db06'
'9932a711bfaf7c0c0c7a1b627534ffffffff0310270000000000001976a9141e667ee'
'94ea8e62c63fe59a0269bb3c091c86ca388ac1027000000000000366a340801120e6a'
'6f686e735f6174746f6b656e32180220012a1c100240014a147fdb0894d162bfacd9f'
'189491245a70254cd7e63500210cd0e00000000001976a914b5a2ced9afd823cb1426'
'07e2d4e7e979cb73b87f88ac00000000',
'txid': '8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012',
'version': 1,
'time': 1721908218,
'locktime': 0,
'IsBurnTx': False,
'vin': [
{
'txid': 'af12a7e9fd99794e349e402e89f8c4cb842915059746924233a200fc7fa2f251',
'vout': 1,
'scriptSig': {
'asm':
'30440220715d8e8663cb46f8c412a11ee6df23fcbb1eda61f34679d1822e4'
'4cfb8338ceb02201ea208e1c730088eff8595aa5053d5f5f3a13b4e135505'
'2df833cff459578bb101 '
'0222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b6'
'27534',
'hex':
'4730440220715d8e8663cb46f8c412a11ee6df23fcbb1eda61f34679d1822'
'e44cfb8338ceb02201ea208e1c730088eff8595aa5053d5f5f3a13b4e1355'
'052df833cff459578bb101210222cb84a16ecd0fbb092bd104e3fb0b59db0'
'69932a711bfaf7c0c0c7a1b627534'
},
'sequence': 4294967295
}
],
'vout': [
{
'value': 0.01,
'n': 0,
'scriptPubKey': {
'asm':
'OP_DUP OP_HASH160 1e667ee94ea8e62c63fe59a0269bb3c091c86ca3 '
'OP_EQUALVERIFY OP_CHECKSIG',
'hex': '76a9141e667ee94ea8e62c63fe59a0269bb3c091c86ca388ac',
'reqSigs': 1,
'type': 'pubkeyhash',
'addresses': ['miHhMLaMWubq4Wx6SdTEqZcUHEGp8RKMZt']
}
},
{
'value': 0.01,
'n': 1,
'scriptPubKey': {
'asm':
'OP_RETURN '
'0801120e6a6f686e735f6174746f6b656e32180220012a1c100240014a147'
'fdb0894d162bfacd9f189491245a70254cd7e635002',
'hex':
'6a340801120e6a6f686e735f6174746f6b656e32180220012a1c100240014'
'a147fdb0894d162bfacd9f189491245a70254cd7e635002',
'type': 'nulldata'
}
},
{
'value': 0.97,
'n': 2,
'scriptPubKey': {
'asm':
'OP_DUP OP_HASH160 b5a2ced9afd823cb142607e2d4e7e979cb73b87f '
'OP_EQUALVERIFY OP_CHECKSIG',
'hex': '76a914b5a2ced9afd823cb142607e2d4e7e979cb73b87f88ac',
'reqSigs': 1,
'type': 'pubkeyhash',
'addresses': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP']
}
}
],
'blockhash': '0000005d5740329e8e1624d9fcea2d900eb5124067a6f6e5da304d737f544f5d',
'confirmations': 23159,
'blocktime': 1721908218
}
P2TH address wrong: expected mhQqLnhv856S44xAsmG8rNBWtj4dqvYD8X, used miHhMLaMWubq4Wx6SdTEqZcUHEGp8RKMZt
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 188, in check_claim
return ei.run_command(eu.get_claim_tx, txid, deckid, quiet=quiet, debug=debug)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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/extended_utils.py", line 794, in get_claim_tx
print("Spending txid:", donation_txid)
^^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'donation_txid' where it is not associated with a value
transaction show 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 -c -t 0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa663
You forgot a "9" at the end. With the correct TXID it works. I added a small check which throws a more comprehensive error if any transaction is given in wrong format.
Regarding check_claim
: None of the transactions you tried is a valid claim transaction (they may be gateway transactions). I catched the UnboundLocalError and changed the error messages so it becomes clearer when this is the case.
Commit: 93d50d4
Can be closed.
Regarding check_claim: None of the transactions you tried is a valid claim transaction (they may be gateway transactions). I catched the UnboundLocalError and changed the error messages so it becomes clearer when this is the case.
You are right! I should've taken the transactions from the token transfers
output.
However after the update if I run any of the above mentioned command, for instance attoken check_claim 8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012 8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012
I'm getting:
'Complete transaction:'
{
'hex':
'01000000e439a2660151f2a27ffc00a2334292469705152984cbc4f8892e409e344e7'
'999fde9a712af010000006a4730440220715d8e8663cb46f8c412a11ee6df23fcbb1e'
'da61f34679d1822e44cfb8338ceb02201ea208e1c730088eff8595aa5053d5f5f3a13'
'b4e1355052df833cff459578bb101210222cb84a16ecd0fbb092bd104e3fb0b59db06'
'9932a711bfaf7c0c0c7a1b627534ffffffff0310270000000000001976a9141e667ee'
'94ea8e62c63fe59a0269bb3c091c86ca388ac1027000000000000366a340801120e6a'
'6f686e735f6174746f6b656e32180220012a1c100240014a147fdb0894d162bfacd9f'
'189491245a70254cd7e63500210cd0e00000000001976a914b5a2ced9afd823cb1426'
'07e2d4e7e979cb73b87f88ac00000000',
'txid': '8d91514b31e9c134ae96cfc3837239200b66383bcac7924d981618f0c7895012',
'version': 1,
'time': 1721908218,
'locktime': 0,
'IsBurnTx': False,
'vin': [
{
'txid': 'af12a7e9fd99794e349e402e89f8c4cb842915059746924233a200fc7fa2f251',
'vout': 1,
'scriptSig': {
'asm':
'30440220715d8e8663cb46f8c412a11ee6df23fcbb1eda61f34679d1822e4'
'4cfb8338ceb02201ea208e1c730088eff8595aa5053d5f5f3a13b4e135505'
'2df833cff459578bb101 '
'0222cb84a16ecd0fbb092bd104e3fb0b59db069932a711bfaf7c0c0c7a1b6'
'27534',
'hex':
'4730440220715d8e8663cb46f8c412a11ee6df23fcbb1eda61f34679d1822'
'e44cfb8338ceb02201ea208e1c730088eff8595aa5053d5f5f3a13b4e1355'
'052df833cff459578bb101210222cb84a16ecd0fbb092bd104e3fb0b59db0'
'69932a711bfaf7c0c0c7a1b627534'
},
'sequence': 4294967295
}
],
'vout': [
{
'value': 0.01,
'n': 0,
'scriptPubKey': {
'asm':
'OP_DUP OP_HASH160 1e667ee94ea8e62c63fe59a0269bb3c091c86ca3 '
'OP_EQUALVERIFY OP_CHECKSIG',
'hex': '76a9141e667ee94ea8e62c63fe59a0269bb3c091c86ca388ac',
'reqSigs': 1,
'type': 'pubkeyhash',
'addresses': ['miHhMLaMWubq4Wx6SdTEqZcUHEGp8RKMZt']
}
},
{
'value': 0.01,
'n': 1,
'scriptPubKey': {
'asm':
'OP_RETURN '
'0801120e6a6f686e735f6174746f6b656e32180220012a1c100240014a147'
'fdb0894d162bfacd9f189491245a70254cd7e635002',
'hex':
'6a340801120e6a6f686e735f6174746f6b656e32180220012a1c100240014'
'a147fdb0894d162bfacd9f189491245a70254cd7e635002',
'type': 'nulldata'
}
},
{
'value': 0.97,
'n': 2,
'scriptPubKey': {
'asm':
'OP_DUP OP_HASH160 b5a2ced9afd823cb142607e2d4e7e979cb73b87f '
'OP_EQUALVERIFY OP_CHECKSIG',
'hex': '76a914b5a2ced9afd823cb142607e2d4e7e979cb73b87f88ac',
'reqSigs': 1,
'type': 'pubkeyhash',
'addresses': ['mx5MdsenFDZufFuwT9ND7BKQBzS4Hy9YUP']
}
}
],
'blockhash': '0000005d5740329e8e1624d9fcea2d900eb5124067a6f6e5da304d737f544f5d',
'confirmations': 23902,
'blocktime': 1721908218
}
P2TH address wrong: expected mhQqLnhv856S44xAsmG8rNBWtj4dqvYD8X, used miHhMLaMWubq4Wx6SdTEqZcUHEGp8RKMZt
This is not a valid PeerAssets token transaction, it contains no card data. Stopping.
Claim transactions appears invalid. Checks failed: 2 from 2.
So I'm wondering what is the long output before the error message. _
This should fit your request.
transaction show DECK -c -t BURNTX/GATEWAYTX/DONATIONTX works now like the mode with only -c TX before, i.e. you enter the burn/gateway/donation tx after -t and get the corresponding claim transaction (if it exists).
Would it make sense to merge the two flags into one?
So I'm wondering what is the long output before the error message.
The idea of this command is to print out both the transaction and the card (PeerAssets data of a token transaction). As you provided a correct transaction (decks are also transaction IDs) the transaction (the deck spawn tx) is printed out. The deck spawn data is also PeerAssets data so you see OP_RETURN, but it's not a card (token transaction).
Would it make sense to merge the two flags into one?
I think you mean to suppress the -c flag in this case and only use -t? I think it's better for usability that -c stays as in both variants you want to know a claim transaction. In addition, perhaps -t in the future could also be used for other purposes where a txid is provided.
The idea of this command is to print out both the transaction and the card (PeerAssets data of a token transaction).
I've got it now.
I think it would make sense inverting the deck and the claim transaction ids in the Usage mode of this command because the corresponding outputs are in that order.
Maybe it may make sense merging two command into one token check_claim
, since it's basically the same command and it seems like it provides exactly the same results regardless if one uses them with attoken or pob token decks.
I've inverted TOKEN and TXID, will be pushed with next update.
About merging, it is one of the commands of the attoken class inherited by the pobtoken class as it only can be used with these two kinds of tokens. The token/card class normally is for commands which can be used with all kinds of tokens (including PoD).
While checking the issue #155 I've discovered that the first claim transaction I did (
fbf3a4a60e2c9864627628472ad2e192a082239006de3dedbb0e25a41781ae63
) went through after the commit implementation on my side without me having done anything else, while I was not able to detect the claiming transactions which corresponds to the burn transaction0f80484cbb1cfb173975724468f3f7775a949082a41219321f791d825efa6639
mentioned in the same thread. Do we have a command for it? Or maybe it would be against people's privacy?