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

reissuance tokens can not be exercised from unblinded outputs #259

Open
instagibbs opened this issue Sep 13, 2017 · 13 comments
Open

reissuance tokens can not be exercised from unblinded outputs #259

instagibbs opened this issue Sep 13, 2017 · 13 comments

Comments

@instagibbs
Copy link
Collaborator

instagibbs commented Sep 13, 2017

In the current logic, CAssetIssuance's assetBlindingNonce being null implies that the issuance is an initial issuance. When re-issuing, this field is re-used to expose the asset blinder for the spent output.

Clearly this is in direct conflict when the output itself has a null blinder.

If the user attempts to make a reissuance with the null blinder output, it will be interpreted as an initial issuance, using the reissuance token purely as the entropy.

@maaku
Copy link
Contributor

maaku commented Sep 13, 2017

I'm going to think on if there is a clever way of handling this.

@nkostoulas
Copy link

Hello, I too came across this issue when trying to reissue from an unblinded issuance, leading to validation (VerifyAmounts()) failing and TX getting rejected.

Do you think there is any better way of doing this other than maybe having an additional flag in CAssetIssuance to differentiate between issuance and reissuance?

@instagibbs
Copy link
Collaborator Author

@nkostoulas No great answers on this yet. Note that the outputs during an issuance should generally be blinded, it's just the issuance itself that will be unblinded(input-side). So ideally in an "all spendable outputs are blinded" world this won't even occur.

This is why I'm a little hesitant to change serializations just for this. Thoughts?

@nkostoulas
Copy link

@instagibbs I guess I've introduced this by allowing unblinded outputs through configuration. In the standard config though where this is not the case, how does this become an issue given that the issuance token output should always be blinded and assetBlindingNonce (when reissuing) non zero?

@instagibbs
Copy link
Collaborator Author

You could send the reissuance token to an unblinded output if you strip the blinding pubkey from a destination address using validateaddress.

@nkostoulas
Copy link

Ah okay now I understand! I'll try and look into it, but I'll be keen to fix this if there's no alternative.

@instagibbs
Copy link
Collaborator Author

Right, this is pretty unfortunate in the completely unblinded chain case 👎

Definitely will get fixed if/when serialization changes are on the table.

@stevenroose
Copy link
Member

So once upside of this issue is that reissuance tokens amounts don't really matter at all. The only thing that matters is whether they are 0 or non-0. So even in a situation where one wants a chain with total transparency (Elements isn't the greatest option for that, though), blinded token amounts wouldn't change that much.

@altafan
Copy link

altafan commented Jun 17, 2020

Hello, I just bumped into this without knowing it was a known issue already.

Since I made some attempts using the CLI, that of course failed, maybe it could be useful having a script for anyone interested in reproducing this paritcular case.

Check out this gist.

@instagibbs
Copy link
Collaborator Author

would be good to have a test case in functional tests with reference to issue

@shesek
Copy link
Contributor

shesek commented Jun 11, 2022

I ran into this issue 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.

Does it make sense to use blinding in this case? How would that work?

@shesek
Copy link
Contributor

shesek commented Jun 12, 2022

would be good to have a test case in functional tests with reference to issue

I created #1119 with a test case.

@philippem
Copy link
Contributor

philippem commented Mar 22, 2023

I ran into this with 22.1.1rc1 trying to reissue using a token that had been received with a non-CT address.
The error manifested as:

$ ./run-cli.sh reissueasset e229add0f6babad85ef7e3ee74d87c4398e72242d2a7dd15373cd5bfd1cfcc3c 0.01
error code: -4
error message:
Unable to blind the transaction properly. This should not happen.

I worked around it by sending the reissuance token back to the same wallet but to a CT address.

$ ./run-cli.sh -named sendtoaddress address="el1qqferrx4cd57v0spcdf67hgfpgmf7emuxmgues7wwwuuasnsv7y59y686z80j3eyp3ejgdulgypnnw902sl7ycetsr4kev2syg" amount="0.00000001" assetlabel="8d1c5d87a739d54e56a423fffe393c6d6f868a0243a7c7827a3526c2cc6b136f"
37b0fd470e9441d4cda024d1c1ec179c5a328be89522130a1fce23cadc3d6502

and the reissuance now succeeds:

$ ./run-cli.sh reissueasset e229add0f6babad85ef7e3ee74d87c4398e72242d2a7dd15373cd5bfd1cfcc3c 0.01
{
  "txid": "5abc3fbe079a7671e13dc7950708f0201297e9918792e3e54084d9d810b2debe",
  "vin": 0
}

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

No branches or pull requests

7 participants