fail spending allocations received with an opret+tapret transfer #275
Comments
In #271 the receiver was failing to validate the consignment with the following error: while here the receiver is able to validate the consignment but then fails to spend the received assets.
Yes, the branch I asked you to check (https://github.com/zoedberg/rgb-tests/tree/tapret_wlt_receiving_opret_fix_271) is using #272 |
|
So do I understand it right that this is not a regression from the successful test as you reported in #272 (review)
You just added further testing to cover whether the asset can be spent after acceptance? |
|
When I reviewed the PR I assumed that the test was good enough to confirm that spending both a tapret and opret allocation was fixed but, by debugging the non-deterministic behavior, I understood that the test was incomplete. So I've added a 4th and 5th transfer and tried again the fix in #272, discovering that this fix was insufficient, since the consignment validation passes but then the recipient is unable to spend the received assets. I haven't debugged this further, so the issue could be on the consignment creation and/or validation, I'll leave this to you. |
|
Now I can't replicate the issue: |
|
Ok, I can replicate it using a different branch
|
That branch has been used on RGB-WG/rgb-tests#16 to show the bug is deterministic (it asserts 0 bundles/transitions and it removes the 4th and 5th transfers) Use branch |
|
Ok, as I thought: this is not a bug, but a lack of UX, as I described in #246 (comment) The opret wallet has funds on a UTXO with an assignment, which spending requires creation of tapret commit. But WPKH wallet can't do a tapret output! Thus, it can't use that funds. Use of tapret funds received to an opret wallet (i.e. non-P2TR wallet) would require manual human work - from the wallet support or something. |
|
Correcting myself: I do not know where I was looking at, but now I see that the One other thing I've noticed is that the transfer of the 3rd transaction is listed as "tentative" by the Anyway, to do a proper debugging I need fixes which I did in the Here is the setup I need: The last commit in https://github.com/RGB-WG/rgb-tests/tree/tapret_wlt_receiving_opret contains all these changes |
I haven't already fixed them. I usually make changes to the tests when I have PRs to review and in the last weeks there were none. I'll make the fixes and let you know when I push
Ok, please note that we should not merge that branch, I'll rebase |
|
Fixed and pushed on https://github.com/zoedberg/rgb-tests/tree/tapret_wlt_receiving_opret_develop |
|
Thank you. What do you think about
Which status transaction 3 must have by the time we do transaction 4? |
|
From what I see, the wallet sees the output of 300, but as tentative (after the test is aborted due to panic): |
|
Ok, I was confused by the fact that there are actually two outputs having 300 of asset and coming from different transactions (one is change from the second transfer, one is created in the third transfer). So I changed the third payment from 300 to 290 and, with that, was able to understand and properly debug what's going on. While Thus, the bug is in the |
|
Huh, finally was able to find the source of the bug. It was unrelated to taprets/oprets, and was just caused by the fact that if a secret seal has more than one terminal, it gets removed from the terminal index due to just a coding mistake. You can easily see what was going on in f77e76f I've added fix to #273 |
|
There Is another bug revealed by the tests after the fixed one - I am working on fixing it too |
This was referenced Oct 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Trying to spend the allocations received with a transfer that spent opret and tapret at the same time, the transfer fails with this error:
This can be seen using this branch and running the
tapret_wlt_receiving_oprettest.The text was updated successfully, but these errors were encountered: