PSET spec updates

[jgriffiths]

Following discussion with achow101

[apoelstra]

utACK 7ef6c44

[apoelstra]

utACK 28c3836

[apoelstra]

For the record -- in an offline discussion with @jgriffiths he suggested that the existing text advises people to remove the explicit values. But it looks like it says "either remove the values, or add a proof". I'm happy to clean up this text but I'm not sure what a good alternate would be. (Also, basically the same text is repeated verbatim for all the proofs which is super annoying to maintain and read.)

BTW are we good to merge this PR?

[jgriffiths]

But it looks like it says "either remove the values, or add a proof". I'm happy to clean up this text but I'm not sure what a good alternate would be. (Also, basically the same text is repeated verbatim for all the proofs which is super annoying to maintain and read.)

Agreed that the text is technically correct, my confusion comes from the elements behaviour differing from the spec, and trying to infer the correct behaviour and rationale.

Given a value V, its commitment C and blind value proof B, the following states are possible:

V C B Valid? Description
y n n Yes    Unblinded
n y n Yes    Blinded with value removed
y y y Yes    Blinded with value present and proof of valid commitment 

n n n No     Invalid: mandatory value is not present
n n y No     Invalid: blind proof for a value and commitment that are not present
y n y No     Invalid: blind proof for a commitment that is not present
n y y No     Invalid: blind proof for a value that is not present
y y n No     Invalid: missing proof that the commitment commits to the value (1)

(1) Is claimed invalid according to the spec, but Elements does not reject it when parsing. From this, 'remove the value or add a commitment' in the spec is misleading. Its not clear to me that this is invalid when having a commitment with no value is valid; both cases imply trusting that the commitment was generated honestly/correctly, while (1) implies also trusting that the value is correct, which is no different.

I think a single section on commitments and their proofs would be clearer, perhaps including the rationale for why one might allow an unproven commitment in the blinded psbt vs not. Also we should clarify whether 'you are trusting that the commitment is valid' is always a fatal state for parsing or merely a decision for the processing entity to make regarding their workflow (and if so, remove the text making the blind proof mandatory if a value and commitment are present).

If the blind proofs were added to allow adversarial construction/blinding/signing by untrusted parties, I think some of these use cases should be fleshed out/validated somewhere. Or perhaps they are obvious and I just haven't thought them through enough. A blind value proof allows you to prove the commitment is valid, but it doesn't let you hide the unblinded value from those you are a sharing the psbt with to complete it. So it seems the only value is in detecting malicious participants in mutual tx construction protocols? If that is the case then for the vast majority of uses where this isn't a requirement, the blind proof should not be mandatory.

BTW are we good to merge this PR?

I would appreciate it (along with the code fixes PR), I'm happy to start another PR for the changes discussed here and further fixes/cleanups.

[apoelstra]

(1) Is claimed invalid according to the spec, but Elements does not reject it when parsing.

If you try to sign or run analyzepsbt with this you will get a specific error. Would you prefer an opaque "parse error"?

[apoelstra]

Its not clear to me that this is invalid when having a commitment with no value is valid; both cases imply trusting that the commitment was generated honestly/correctly, while (1) implies also trusting that the value is correct, which is no different.

If you have no value, you can't "trust that the commitment was generated honestly/correctly" because there is nothing to trust. You don't know the value and there's no way to fool yourself into thinking you do. If this is a problem for your wallet/workflow then you should refuse to sign the PSET.

So the two cases seem very different to me.

If the blind proofs were added to allow adversarial construction/blinding/signing by untrusted parties, I think some of these use cases should be fleshed out/validated somewhere. Or perhaps they are obvious and I just haven't thought them through enough.

Sure, the "obvious" usecase is that no hardware wallets on the market are able to generate, validate or rewind rangeproofs. So you need a powerful but untrustworthy host to generate them, and the hww needs a way to vet this.

But yes, we should add a section explaining all this.

If that is the case then for the vast majority of uses where this isn't a requirement, the blind proof should not be mandatory.

I think it would be extremely rare that signing hardware would not need to know the values. This is probably the case in certain coinjoin constructions where your hww only cares about a subset of the transaction, but such users should probably be using dicemix instead which obviates this. The other case where these are unneeded is where the blinder and signer are the same, but this is also very rare due to lack of hardware.

[apoelstra]

Cool, I'll merge this and we can take up the blind proof stuff in a new PR.