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

[robwoodgate]

Closes #319

This PR proposes an optional digest 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.

[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.