Skip to content
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

Add a failing test case for reissuance from an unblinded output (#259) #1119

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

shesek
Copy link
Contributor

@shesek shesek commented Jun 12, 2022

A failing test case for #259.

@instagibbs mentioned that it would be good to have a test for this, hopefully this might nudge someone to give this issue some more thought :-)

(To give some context, I ran into this while experimenting with 'scripted assets', where the reissuance token is under an 'anyone can spend if you follow the rules' covenant rather than managed by an issuing entity. It seems that not blinding the token makes more sense for this use-case?)

@sanket1729
Copy link
Member

To the best of my knowledge, this is not possible to do. The workaround for my use-case was to use blinding, but fix the blinding factors and assert that the blinded asset is some fixed asset. There is more nuance to this as the input and output confidential assets cannot be the same according to elements consensus rules. So, it required oscillating between two fixed confidential assets with initially decided blinding factors.

If something like this is of interest, I can elaborate more.

@tiero
Copy link

tiero commented Aug 18, 2022

It may be slightly related, but I can't make a (blinded) re-issuance in the same tx where I am issuing a control asset.

Also this useful in covenant scripts :)

#1103

@apoelstra
Copy link
Member

@tiero my understanding is that your other issue is caused by the blindrawtransaction RPC doing dumb stuff and not having enough flexibility. The PSET also has these problems :) but with PSET we're actively developing and have the ability to basically add arbitrary extra fields to handle new requirements. So that one I hope we can address just by making PSET more powerful.

The problem in this issue unfortunately seems to be caused by bad consensus logic, and there's nothing we can do about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants