rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 Original date posted:2015-10-21 📝 Original message:On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/3a229156/attachment.html>