On Wed, Jul 11, 2018 at 6:27 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > I don't think that's a particularly useful policy, but certainly > Signers are allowed to implement any policy they like about what they > accept in signing.
Do we really want the specification to permit conforming implementations to refuse to sign because there is extra metadata? ISTM this would make it very hard to implement new features that require extra data. For example, say you have a checkmultisig with one key in it using schnorr multisignature which require the extra rounds to establish an R, and the other keys are legacy stuff. If the other signer(s) suddenly stop working when there are extra fields irrelevant to them, then this will create a substantial pressure to not extend the PSBT in the intended way, but to instead find places to stuff the extra data where it won't interfere with already deployed signers. This would be really unfortunate since PSBT was created specifically to avoid field stuffing (otherwise we could have accomplished all the intended goals by field stuffing a bitcoin transaction encoding). Obviously no signer should be signing data they don't understand, but extra data that they ignore which doesn't change their signature should not stop them. Another way of looking at it, perhaps somewhere someplace some idiot defined signatures starting with 0xdead to give away all the users funds or whatever. That's something you "can't understand" either, ... but no one would conclude because something could happen somewhere that you don't know about that you just can't sign at all... yet it is possible. :) If someone wants to make a non-conforming signer, that is cool too and they may have good reason to do so-- but I think it would be sad if new applications get gunked up, slowed down or forced to use ugly hacks, due to the intentional extension support in the protocol being blocked by things claiming to support the spec. The whole reason the spec doesn't lock in exactly the possible fields and allow no others is to allow extensions without breaking compatibility. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
