{"type":"rich","version":"1.0","author_name":"npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","author_url":"https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-21\n📝 Original message:On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote:\n\u003e The proposal is implemented (see below), by computing the normalized\n\u003e transaction ID when adding them to the UTXO and storing them along with the\n\u003e coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and\n\u003e OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into\n\u003e how to best refactor the common functionality into reusable blocks. And the\n\u003e annotating incoming transactions with their normalized inputs is a bit\n\u003e cumbersome, maye somebody has some pointers here as well?\n\nThis doesn't completely close malleability (which should be documented in the \nBIP), so I'm not sure it's worth the cost, especially if closing malleability \nlater on would need more. How about specifying flags upfront in the UTXO-\ncreating transaction specifying which parts the signature will cover? This \nwould allow implementation of fully malleability-proof wallets.\n\nAdditionally, you have a flag to control whether the opcode behaves as VERIFY \nor not. Non-VERIFY is not possible as a softfork (without doing a second/new \nP2SH) since it can be negated.\n\nLuke"}