Right, we need to require silent payments aware signers to never use ACP at all if there are any silent payment outputs present. If there are no silent payment outputs they can sign with whatever sighash they wish. I suppose we don’t need to track that state for Constructor and Updater, since in BIP174 the Signer has the check:
- If a sighash type is provided, the signer must check that the sighash is acceptable. If unacceptable, they must fail.
which for silent payment aware signers they would check for any ACP on any inputs and fail if there are any silent payment outputs. I’m not sure why there is a Has Sighash Single flag though and we shouldn’t extend the PSBT_GLOBAL_TX_MODIFIABLE to have a Has Silent Payments flag to track this state in the same way. That way Constructors won’t add silent payment outputs if there have been any ACP sigs and Updaters won’t add any ACP sighashes to inputs if there are any silent payments. It should be backwards compatible too to add a flag to that field.
However, the next rule for Signer needs to be modified for silent payment aware signers:
- If a sighash type is not provided, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish.
should be:
- If a sighash type is not provided and there are silent payment outputs present, the signer must sign using SIGHASH_ALL. If a sighash type is not provided and there are no silent payment outputs present, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish.
How about adding the shares and proofs as globals, and the key data would be the scan key followed by the set of input outpoints instead of input indexes? That would let the psbt change input order and would not duplicate the shares and proofs for each input.
This would be less work for the verifier too, right? Less proofs to verify.