Flexibility in using commitment schemes with P2C being the default one

[fedsten]

In the current specification, the choice on the commitment scheme to be used for transactions is left to the issuer. However, different users of an asset may had different preferences. For example, a private user may prioritize the minimization of the on-chain footprint (either for privacy or efficiency) and prefer the pay-to-contract scheme, while an exchange may prefer the OP_RETURN based commitments to enable easier HSMs support. Therefore, forcing all future users to the same commitment scheme may result limiting.

I don't see why this sort of limitation is necessary. Probably the choice could be left to the two parties involved in each transaction rather than to the issuer, with the receiving party signalling through an invoice which scheme(s) it supports.

[dr-orlovsky]

After the discussing during RGB team weekly call on the 10th of June it was decided:

1. Release requirement on all proofs to follow the same commitment scheme
2. Remove contract header field specifying the commitment scheme
3. Add field to the proof to specify the used commitment scheme
4. Use pay-to-contract scheme as the default and recommended scheme. OP_RETURN will be reserved only for the cases of (a) public asset issuing contract commitments and (b) for asset transfers that have to be compatible with HSM/hardware wallets.

The reason of pay-to-contract default is to reduce Bitcoin blockchain pollution with asset transfer data and force the higher privacy.

I will be working on a PR to add all of these into the specification.