📅 Original date posted:2014-10-13
📝 Original message:On Tue, Oct 14, 2014 at 2:34 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> Hi all,
>
> while working on a BIP62 implementation I discovered yet another type
> of malleability: the interpretation of booleans.
>
> Any byte array with non-zero bytes in it (ignoring the highest bit of
> the last byte, which is the sign bit when interpreting as a number) is
> interpreted as true, anything else as false. Other than numbers,
> they're not even restricted to 4 bytes. Worse, the code for dealing
> with booleans is not very consistent: OP_BOOLAND and OP_BOOLOR first
> interpret their arguments as numbers, and then compare them to 0 to
> turn them into boolean values.
>
> This means that scripts that use booleans as inputs will be inherently
> malleable. Given that that seems actually useful (passing in booleans
> to guide some OP_IF's during execution of several alternatives), I
> would like to change BIP62 to also state that interpreted booleans
> must be of minimal encoded size (in addition to numbers).
>
> Any opinions for or against?
An argument against is that you can currently do something like this:
OP_DUP OP_IF OP_HASH160 PUSH OP_EQUALVERIFY OP_ELSE <stuff>
OP_CHECKSIGVERIFY OP_ENDIF
E.g. if your input is non-zero you're giving a hash, if it's zero
you're skipping that and running another branch.
Of course you could just encode your script another way... but by that
same logic you can 1 OP_QUALVERIFY to bool-ize any input in the true
path. The inconsistency in handling makes it more likely that script
authors will screw up with bad (for them) consequences, however.
[I just asked pieter out of band to clarify if he means "minimal
encoded size", or must be 0 or 1 minimally encoded... as the former
doesn't fix the malleability, but the later is more disruptive]
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:26:27
in reply to nevent1q…7hmx
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:26:27Event JSON
{
"id": "c84e547b647cb3006cd2ae679e6ac43c771a52dea419be12cf4160df987fd6c1",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151587,
"kind": 1,
"tags": [
[
"e",
"c83f6dedf4ca7c81a89476f7b8b9b295fef9059bd827880a0f714bdd8244a34b",
"",
"root"
],
[
"e",
"d52e91fb91e060009c4bcef2f3ba3464f3b8189d1cd8defe84340bb7dc0cf278",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2014-10-13\n📝 Original message:On Tue, Oct 14, 2014 at 2:34 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e Hi all,\n\u003e\n\u003e while working on a BIP62 implementation I discovered yet another type\n\u003e of malleability: the interpretation of booleans.\n\u003e\n\u003e Any byte array with non-zero bytes in it (ignoring the highest bit of\n\u003e the last byte, which is the sign bit when interpreting as a number) is\n\u003e interpreted as true, anything else as false. Other than numbers,\n\u003e they're not even restricted to 4 bytes. Worse, the code for dealing\n\u003e with booleans is not very consistent: OP_BOOLAND and OP_BOOLOR first\n\u003e interpret their arguments as numbers, and then compare them to 0 to\n\u003e turn them into boolean values.\n\u003e\n\u003e This means that scripts that use booleans as inputs will be inherently\n\u003e malleable. Given that that seems actually useful (passing in booleans\n\u003e to guide some OP_IF's during execution of several alternatives), I\n\u003e would like to change BIP62 to also state that interpreted booleans\n\u003e must be of minimal encoded size (in addition to numbers).\n\u003e\n\u003e Any opinions for or against?\n\n\nAn argument against is that you can currently do something like this:\n\n\nOP_DUP OP_IF OP_HASH160 PUSH OP_EQUALVERIFY OP_ELSE \u003cstuff\u003e\nOP_CHECKSIGVERIFY OP_ENDIF\n\nE.g. if your input is non-zero you're giving a hash, if it's zero\nyou're skipping that and running another branch.\n\nOf course you could just encode your script another way... but by that\nsame logic you can 1 OP_QUALVERIFY to bool-ize any input in the true\npath. The inconsistency in handling makes it more likely that script\nauthors will screw up with bad (for them) consequences, however.\n\n[I just asked pieter out of band to clarify if he means \"minimal\nencoded size\", or must be 0 or 1 minimally encoded... as the former\ndoesn't fix the malleability, but the later is more disruptive]",
"sig": "17654eea2ec3dea8d5d1f4adade3e14357b0adb4c8726f9089fccec2cdbd48cf2f9fbbad51803e8a22cea2ffb6f048ac3c6436c5cdccfb2ffef2149f4b277275"
}