Investigate possibility of sign-to-contract scheme for RGBv2

[dr-orlovsky]

Copy of discussion from RGBv1 audit:

@dr-orlovsky> do you remember why we originally stick to pay-to-contract and not sign-to-contract commitments?

@fedsten> there were some issues with the multisig, as the co-signer may easily destroy the tokens by not putting the commitment in his signature

@dr-orlovsky>
yes, this applies to pay-to-contract multisig, and was solved by LNPBP-2, where we commit to the sum of keys, so at least one of the signers must produce correct signature. Now, with switching sign-to-contract will:

• allow wallets not to keep tweaking information and simplify situations when tweak has to go into output owned by some other party
• make LNPBP-3 redundand and will solve fee problem (lexicographic ordering of inputs/outputs etc), however it will result in generally larger anchors (since all commitments to all assets from some output must go into the same input, and not distributed across all witness transaction outputs)
• on the other hand we would not need to store output script information as the part of anchor data, so final impact on the size of the client-validated-data probably would not change

@fedsten> that indeed the problem was only due to the old design on multisig commitments
rgb-archive/spec#10

@giacomozucco> Yes, i remember the same. some divergence in security model between bitcoin multisig and rgb multisig (always manageable, but potentially confusing, since the security assumptions would radically change, while with p2c they stayed more consistent). Also, I remember some incompatibility between the s2c commitment model and eltoo. Which wouldn't be a big deal if not for the fact that the commitment scheme is one of the things we can't easily change anymore.

@dr-orlovsky> yes. But now with LNPBP-2 this should not be a problem anymore

@giacomozucco> Yes, it would be much simpler in many ways

@dr-orlovsky> Thank you, I think we will need to provide rational for that decision in the spec anyway. Not sure that it will conflict with Eltoo, so I will leave this issue opened

@giacomozucco> Ack

[dr-orlovsky]

Not required anymore once we have a Tapret commitments