On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke@dashjr.org> wrote:

On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote:
> The proposal is implemented (see below), by computing the normalized
> transaction ID when adding them to the UTXO and storing them along with the
> coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
> OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
> how to best refactor the common functionality into reusable blocks. And the
> annotating incoming transactions with their normalized inputs is a bit
> cumbersome, maye somebody has some pointers here as well?

This doesn't completely close malleability (which should be documented in the
BIP), so I'm not sure it's worth the cost, especially if closing malleability
later on would need more. How about specifying flags upfront in the UTXO-
creating transaction specifying which parts the signature will cover? This
would allow implementation of fully malleability-proof wallets.

As far as I see it the only remaining venues for malleability are the use of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any use of non-sighash_all flags is already an explicit permission to modify the transactions, by adding and removing inputs and outputs, so I don't see how these can be made non-malleable. Am I missing something?

Additionally, you have a flag to control whether the opcode behaves as VERIFY
or not. Non-VERIFY is not possible as a softfork (without doing a second/new
P2SH) since it can be negated.

Yes, this is my mistake and has been pointed out in the PR, I will amend the PR to make the verify flag mandatory, which also guarantees that the top of the stack contains a non-null element, thus resulting in a successful evaluation on non-updated clients.

Luke