Johnson Lau [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-17 📝 Original message:> On August 16, 2016 at ...
📅 Original date posted:2016-08-17
📝 Original message:> On August 16, 2016 at 8:27 PM Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Okay.
>
> I'm not really opposed to this BIP, but I am worried that fighting script malleability is a battle that can never be won; even leaving one avenue of malleability open is probably just as bad as having many avenues of malleability, so it just doesn't seem worthwhile to me.
Not really. I think the goal is to protect as many common scripts as possible.
For example:
1) BIP146 (Low S values signatures) will eliminate all malleability for P2WPKH
2) BIP146 + null dummy value for CHECKMULTISIG ("NULLDUMMY") will eliminate all malleability for simple multi-sig in P2WSH. This is particularly interesting since without NULLDUMMY, attackers are able to replace the dummy value with anything.
3) BIP146 + NULLDUMMY + minimal IF argument ("MINIMALIF") will eliminate malleability for any Lightening Network scripts that I'm aware of.
With 3), 99.99% of segwit transactions in foreseeable future should be fully protected.
The plan is to implement MINIMALIF as a relay policy first, and enforce the softfork after further risks assessment. This BIP serves as a warning to users for not using incompatible script.
Peter Todd:
> Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode that fails unless the top item on the stack is a minimally encoded true or false value, to allow script writers to opt into this behavior; it's not always ideal.
I believe all Lightening Network scripts (the only real users of IF/NOTIF in foreseeable future) are already compatible with MINIMALIF. It may not be a good idea for them to spend 1 more byte to get protected.
If people want to have the original OP_IF behaviour, a simple way would be using "0NOTEQUAL IF". However, this works only if the argument is a valid number (also beware of MINIMALDATA rule in BIP62).
To completely replicate the original behaviour, one may use:
"DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script} ELSE DROP {else script} ENDIF"
This is because we don't have a simple OP_CASTTOBOOL, and IFDUP is 1 of the 4 codes that perform CastToBool on top stack item (the others are VERIFY, IF, and NOTIF; and VERIFY can't be used here since it terminates the script with a False).
Published at
2023-06-07 17:52:58Event JSON
{
"id": "53f4b1277b2f3bfa578be2f5db519680a8e630aceba0e9069dd0eb2260d2b501",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686160378,
"kind": 1,
"tags": [
[
"e",
"9284d48ee3ec0986e743af41281b218e681b340835d80de299ea9e9d68940884",
"",
"root"
],
[
"e",
"e31e43a0700a00fc69a9246dc5d2dca31c385ba33a4d0cccdede23a8aed6e2e1",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2016-08-17\n📝 Original message:\u003e On August 16, 2016 at 8:27 PM Russell O'Connor via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e Okay.\n\u003e \n\u003e I'm not really opposed to this BIP, but I am worried that fighting script malleability is a battle that can never be won; even leaving one avenue of malleability open is probably just as bad as having many avenues of malleability, so it just doesn't seem worthwhile to me.\n\nNot really. I think the goal is to protect as many common scripts as possible.\n\nFor example:\n1) BIP146 (Low S values signatures) will eliminate all malleability for P2WPKH\n2) BIP146 + null dummy value for CHECKMULTISIG (\"NULLDUMMY\") will eliminate all malleability for simple multi-sig in P2WSH. This is particularly interesting since without NULLDUMMY, attackers are able to replace the dummy value with anything.\n3) BIP146 + NULLDUMMY + minimal IF argument (\"MINIMALIF\") will eliminate malleability for any Lightening Network scripts that I'm aware of.\n\nWith 3), 99.99% of segwit transactions in foreseeable future should be fully protected.\n\nThe plan is to implement MINIMALIF as a relay policy first, and enforce the softfork after further risks assessment. This BIP serves as a warning to users for not using incompatible script.\n\nPeter Todd:\n\u003e Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode that fails unless the top item on the stack is a minimally encoded true or false value, to allow script writers to opt into this behavior; it's not always ideal.\n\nI believe all Lightening Network scripts (the only real users of IF/NOTIF in foreseeable future) are already compatible with MINIMALIF. It may not be a good idea for them to spend 1 more byte to get protected.\n\nIf people want to have the original OP_IF behaviour, a simple way would be using \"0NOTEQUAL IF\". However, this works only if the argument is a valid number (also beware of MINIMALDATA rule in BIP62).\n\nTo completely replicate the original behaviour, one may use:\n\"DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script} ELSE DROP {else script} ENDIF\"\n\nThis is because we don't have a simple OP_CASTTOBOOL, and IFDUP is 1 of the 4 codes that perform CastToBool on top stack item (the others are VERIFY, IF, and NOTIF; and VERIFY can't be used here since it terminates the script with a False).",
"sig": "cd950be7acf9e2e3a9ec9a607b5b280002b2e8f41bd3868fec936f2a962e30a0a44ccfd1c79587456b4b1807f8d89f18b85d02a8d1ca74351f195c2e90039200"
}