Why Nostr? What is Njump?
2023-06-07 17:52:58
in reply to

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).
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9