Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-11 📝 Original message:On Wed, Jul 11, 2018 at ...
📅 Original date posted:2018-07-11
📝 Original message:On Wed, Jul 11, 2018 at 6:27 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev at 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.
📝 Original message:On Wed, Jul 11, 2018 at 6:27 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev at 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.