📅 Original date posted:2016-08-17
📝 Original message:On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:
> 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 much uglier than expected. IMO if that's the best workaround for the
current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if they
need to avoid malleability issues.
I suspect most cases OP_IF would be used, you really want to accept any non-
zero value. For example, the HTLC script I posted on the list about not long
ago (OP_IF operates on the result from OP_SIZE). Counter-examples would be BIP
124, the examples in BIP 65 and BIP 112, but I note all of these could be just
as easily done without the explicit boolean being fed to the OP_IF (you'd need
an OP_DUP to keep the value, so it wouldn't reduce the byte-size).
Of course, as long as we're talking about a softfork activating together with
segwit, and only having effect in segwit scripts... there's no reason we can't
add whatever opcodes we need so long as it gets done before 0.13.1. I suggest
OP_CASTTOBOOL and OP_DUPASBOOL would be two good candidates if we make OP_IF
stricter. There's also the possibility of adding an OP_RETAINIF which behaves
as the current OP_IF, except not popping the conditional value off the stack.
But perhaps this is getting too complicated for testing in time for segwit...
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:52:58
in reply to nevent1q…u83h
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:52:58Event JSON
{
"id": "5dc5b35e9cb7096a0a19ca0c2581d65ef132e4b369d83140a8ca74efe06e7705",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160378,
"kind": 1,
"tags": [
[
"e",
"9284d48ee3ec0986e743af41281b218e681b340835d80de299ea9e9d68940884",
"",
"root"
],
[
"e",
"53f4b1277b2f3bfa578be2f5db519680a8e630aceba0e9069dd0eb2260d2b501",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2016-08-17\n📝 Original message:On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:\n\u003e To completely replicate the original behaviour, one may use:\n\u003e \"DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script}\n\u003e ELSE DROP {else script} ENDIF\"\n\nThis is much uglier than expected. IMO if that's the best workaround for the \ncurrent behaviour, people should just use \"OP_1 OP_EQUAL OP_IF\" when/if they \nneed to avoid malleability issues.\n\nI suspect most cases OP_IF would be used, you really want to accept any non-\nzero value. For example, the HTLC script I posted on the list about not long \nago (OP_IF operates on the result from OP_SIZE). Counter-examples would be BIP \n124, the examples in BIP 65 and BIP 112, but I note all of these could be just \nas easily done without the explicit boolean being fed to the OP_IF (you'd need \nan OP_DUP to keep the value, so it wouldn't reduce the byte-size).\n\nOf course, as long as we're talking about a softfork activating together with \nsegwit, and only having effect in segwit scripts... there's no reason we can't \nadd whatever opcodes we need so long as it gets done before 0.13.1. I suggest \nOP_CASTTOBOOL and OP_DUPASBOOL would be two good candidates if we make OP_IF \nstricter. There's also the possibility of adding an OP_RETAINIF which behaves \nas the current OP_IF, except not popping the conditional value off the stack. \nBut perhaps this is getting too complicated for testing in time for segwit...\n\nLuke",
"sig": "9f6b5328dbc30c470b33201f114a3992d42bcfe2d269b3d367e80a89db7f3f8519bbcdba4e189450445331e08ffa55e2667790b4e93a18b336761f5a7538f1a1"
}