On Wed, Oct 21, 2015 at 6:18 AM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.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. > > 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.
Flagability cannot work recursively which is necessary for any improvement to be useful for multi-phase protocols. (which, I think, is the only real application of this class of improvement-- third party mutation can be prevented by enforced canonical encodings;) One still wants sighash flags--, but they're going to inherently result in malleability. I'm still sad that uniform segregated witeness is so hard to deploy, adding another id to every utxo set won't be a nice cost. :( But I have been trying for a long time to come up with anything better and not being successful. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
