NUT-11: Optional P2PKWitness.digest for multi-party SIG_ALL

[robwoodgate]

Closes #319

This PR proposes an optional digest and mts ("message to sign") keys be added to the P2PKWitness object. This allows the receiver/co-ordinator to pass around a token containing the Proof(s) to sign to other parties.

The P2PKWitness.digest tells the other party the message to sign for that Proof.

The P2PKWitness.mts is the raw message for use in cases where signers require the detail of the inputs and outputs.

[gudnuf]

It seems important for the signers to be able to verify what they are signing. In this proposal signers would just get the digest, so they can't be sure what outputs they are authorizing to be created.

[robwoodgate]

I thought that too initially, but when a group decides who the recipient/coordinator of the swap will be, it is really down to them to construct the outputs.

Collating blinded messages from other parties and proving the message digest matches expectations is really an out of band operation in cases where parties are splitting outputs.

But if we are willing to accept a longer string in the token, we could use the raw aggregated message to sign instead.

That way, each party can supply their own blinded message outputs out of band and see they are all aggregated. If one "cheats" the inputs and outputs won't match and the swap will fail.

[robwoodgate]

Collating blinded messages from other parties and proving the message digest matches expectations is really an out of band operation in cases where parties are splitting outputs.

Let me unpack that a bit more:

Multi-party signature, single receiver transactions

The receiver should construct the outputs. They can't really cheat themselves. The others are signing to release the funds only. If the other signers want extra oversight into exactly how the receiver is choosing to receive (keyset, denominations, spending conditions etc), that's an out of band issue.

Multi-party signature, multi receiver transactions

Each receiver should send the blind message string for their own output(s) to the agreed (and hopefully trusted) co-ordinator. They can try and cheat, but if they do, the aggregate amount won't match the inputs and the transaction will fail.

Collating the blind messages and proving the digest includes the expected inputs/outputs is the co-ordinator's out of band responsiblity. We are only facilitating the actual signing.

HOWEVER, if we are willing to use the "message to sign" instead of its digest, then all parties can SEE the inputs and the fact their blind message is included in the outputs, which does reduce the burden of proof dramatically.

Multi-party signature, third party receiver transactions

In this case, the third party would have to trust / nominate a signatory to create blinded messages for them (or receive them on their behalf) and then sign they are in the transaction.

In this circumstance, it would be better/easier if the witness contained the raw message to sign, not the digest. That way, they can see the third party's outputs are included directly.

Summary

I've started with the most conservative case (digest only = smaller token), but we could use the message to sign instead to cover the "are we spending the right inputs and are my outputs actually in this transaction" question.

In all cases, if the other signers need to see the RAW unblinded message and confirm actual secrets for the other parties, that is an out-of-band issue. I don't believe we want to be passing around blinding factors under any circumstance.

[robwoodgate]

We may not need both, but I've added a witness.mts field for flexibility.

[SatsAndSports]

Nice idea!

It's good to see the message (or, more precisely, the outputs which will be blind-signed by the mint) for another reason:

If the swap is executed but the BlindSignatures are not successfully distributed to all parties, then the receivers will be able to use Nut09 (Restore Signatures) to get their outputs. Without the outputs, they cannot do this

[robwoodgate]

Nice idea!

It's good to see the message (or, more precisely, the outputs which will be blind-signed by the mint) for another reason:

If the swap is executed but the BlindSignatures are not successfully distributed to all parties, then the receivers will be able to use Nut09 (Restore Signatures) to get their outputs. Without the outputs, they cannot do this

Great point! And thanks for spotting the misplaced comma too

[SatsAndSports]

Do we want to add a note to this advising wallets that they should not (or should?) include these two fields when they are finally submitting the fully-signed swap/melt to the mint?

The message isn't really super secret, the mint is going to have to reconstruct the message and digest anyway itself while it verifies the spending conditions, so it doesn't really matter

But it might be good to suppress this extra data, so that we don't make it obvious to the mint that this is a multi-party SIG_ALL

[robwoodgate]

Do we want to add a note to this advising wallets that they should not (or should?) include these two fields when they are finally submitting the fully-signed swap/melt to the mint?

The message isn't really super secret, the mint is going to have to reconstruct the message and digest anyway itself while it verifies the spending conditions, so it doesn't really matter

But it might be good to suppress this extra data, so that we don't make it obvious to the mint that this is a multi-party SIG_ALL

Good point, although it doesn't strictly matter, it is wallet-side data the mint isn't expecting so it should be removed before swap.

EDIT - Now added in 91cbd4e

[SatsAndSports]

ACK

I made a couple of tiny comments just a few minutes ago, but otherwise this look good

[a1denvalu3]

what does mts stand for?

[a1denvalu3]

"message to sign". gotcha.