concept ACK

Prefer to just have an OP_CASTTOBOOL added. This breaks conditionals on OP_DEPTH and OP_SIZE for example.

OP_CASTTOBOOL can't solve the problem. CastToBool in OP_IF is exactly the source of malleability. We needs to turn a OP_NOP into OP_ISBOOLVERIFY.

In any case, that requires a softfork which can't be done any time soon. What we need now is a quick policy patch. An alternative is to make SIZE IF and DEPTH IF excluded from this policy

we did segwit so that we don't have to care about malleability in inputs, but now we care about malleability inside witness inputs? o_O

I would prefer to not touch that as DEPTH IF and SIZE IF are still useful. I'm not fan making special case either.

Relevant discussion https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html

ok read the conversation, I like the proposition of @jl2012 of making it a relay rule for now and deciding whether to make it a SF later. Concept ACK.

No objection to a policy rule, just wanted to point that out here so it didn't get lost. :)

(OP_ISBOOLVERIFY could be policy-enforced just as well though...?)

concept ACK as relay rule only

@luke-jr , a "policy opcode" means we could never use that NOP for other purpose again, even if we abandon the softfork plan.

@jl2012 Not really. It simply means we'd need to wait a few releases from when it's policy-redefined to a straight-disallowed NOP, before it is safe to reuse. Along those lines, I wonder if it would make sense to redefine other unallocated opcodes as NOPs inside segwit now (although I doubt it will be useful in the long run).

@luke-jr you can't redefine policy opcode because people are likely to have utxos with that.

and it won't make sense to create more NOPs. The use of NOPs is really limited as they can't manipulate the stack at all. For example, my most wanted code, OP_CAT, could not be done with and NOP

Concept ACK. OK with either policy rule or consensus rule, finalized LN bitcoin scripts will be compatible.

To echo jl2012 's comment about having UTXOs, policy rules to an eventual SF is complicated because doing something as simple as OP_DUP OP_IF OP_SHA256 <PUSHDATA> OP_EQUAL
can invalidate scripts (you're computing on the same data in two places, one of which would be constrained in the SF when activated and the other constrained in the script itself). It is theoretically plausible to construct this kind of script for an actual useful purpose (e.g. if OP_FALSE as input, the other branch would compute on the next item on the stack, albeit it may be possible to construct those scripts more optimally without this problem in the first place, the possibility that it can happen with some kind of script is a concern).

utACK c72c5b1

Code-review ACK c72c5b1