reissuance tokens can not be exercised from unblinded outputs

[instagibbs]

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]

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

[nkostoulas]

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]

@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]

@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]

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

[nkostoulas]

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]

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

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

[stevenroose]

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]

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]

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

[shesek]

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?