{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-21\n📝 Original message:On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev\n\u003e wrote:\n\u003e \u003e The proposal is implemented (see below), by computing the normalized\n\u003e \u003e transaction ID when adding them to the UTXO and storing them along with\n\u003e the\n\u003e \u003e coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and\n\u003e \u003e OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into\n\u003e \u003e how to best refactor the common functionality into reusable blocks. And\n\u003e the\n\u003e \u003e annotating incoming transactions with their normalized inputs is a bit\n\u003e \u003e cumbersome, maye somebody has some pointers here as well?\n\n\n\u003e This doesn't completely close malleability (which should be documented in\n\u003e the\n\u003e BIP), so I'm not sure it's worth the cost, especially if closing\n\u003e malleability\n\u003e later on would need more. How about specifying flags upfront in the UTXO-\n\u003e creating transaction specifying which parts the signature will cover? This\n\u003e would allow implementation of fully malleability-proof wallets.\n\u003e\n\nAs far as I see it the only remaining venues for malleability are the use\nof sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any use\nof non-sighash_all flags is already an explicit permission to modify the\ntransactions, by adding and removing inputs and outputs, so I don't see how\nthese can be made non-malleable. Am I missing something?\n\n\n\u003e\n\u003e Additionally, you have a flag to control whether the opcode behaves as\n\u003e VERIFY\n\u003e or not. Non-VERIFY is not possible as a softfork (without doing a\n\u003e second/new\n\u003e P2SH) since it can be negated.\n\u003e\n\nYes, this is my mistake and has been pointed out in the PR, I will amend\nthe PR to make the verify flag mandatory, which also guarantees that the\ntop of the stack contains a non-null element, thus resulting in a\nsuccessful evaluation on non-updated clients.\n\n\n\u003e\n\u003e Luke\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/3a229156/attachment.html\u003e"}