-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a way to find out the claim transaction knowing the corresponding burn transaction? #169
Comments
You can do It would be possible to add this mode without new flag for |
I think it's not a big deal if we introduce the What would be the usage mode in this case? Something like |
I've decided to integrate that function in the Command is 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 |
I've tested
I've also tested the
I've also tested the command with a casual sting
_
Then I've looked better into the
Thus I've understood that there is no such claim transaction which is true, because I've been using the corresponding burn transaction.
Which is not exactly true, since the transaction went through. 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 agree. I now changed the command a bit, for this purpose:
Also a bug. Fixed. (commit 7602f5a)
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
The correct command
Which is expected for the first two and not expected for the last one, since in #155 the
The same with another transaction done for another AT deck: But surprisingly enough I've also got some output while I've tested the erroneous command
|
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 Commit: 93d50d4 Can be closed. |
You are right! I should've taken the transactions from the
So I'm wondering what is the long output before the error message.
Would it make sense to merge the two flags into one? |
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).
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. |
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 |
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?
The text was updated successfully, but these errors were encountered: