BIP352: PSBT support

[andrewtoth]

@josibake

@andrewtoth

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 don’t think a silent payment signer cares if anyone else has used ACP.

I think I see the confusion. What I meant was the silent payment aware signers must check for any ACP on any inputs they will sign for and fail if there are any silent payment outputs. If all signers are following the BIP spec, then there should not be any inputs signed with ACP anyways. Actually, the signer should probably fail if there is any sighash flag other than ALL if there are any silent payment outputs.

@josibake

@andrewtoth

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.

I don’t have a strong opinion here. If we have nnn inputs covered by the same proof, this would be n\cdot 36 + (33 + 64)n⋅36+(33+64)n\cdot 36 + (33 + 64) bytes vs n\cdot (33 + 64)n⋅(33+64)n\cdot (33 + 64) bytes. So better in some cases, worse in others?

One other possibility that could simplify things. If a signer is able to sign for all inputs, they could add a global share and proof covering all inputs with the key data being the scan key. If a signer is unable to sign for all inputs, then they add a per input share and proof covering only that input as described by @achow101 above. This keeps the key data clean and optimizes for the common scenario of a single signer wallet using a hardware signing device.