{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-10\n📝 Original message:On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:\n\u003e Hello all,\n\u003e \n\u003e it was something I planned to do since a long time, but with the\n\u003e recent related issues popping up, I finally got around to writing a\n\u003e BIP about how we can get rid of transaction malleability over time.\n\u003e \n\u003e The proposed document is here: https://gist.github.com/sipa/8907691\n\u003e \n\u003e I expect most rules to not be controversial. Maybe rules 1 and 3, as\n\u003e they require modifications to wallet software (Bitcoin Core 0.9 and\n\u003e BitcoinJ already implement it, though) and potentially invalidate some\n\u003e script functionality. However, these new rules remain optional and\n\u003e controlled by an nVersion increase.\n\u003e \n\u003e Comments please!\n\nYou should probably add making CHECKMULTISIG require the dummy value to\nbe exactly equal to OP_FALSE; verifying that in the transaction itself is\nlaborious. A more subtle example is we may want both CHECKSIG and\nCHECKMULTISIG to fail the transaction if the signature is invalid but\nnot exactly equal to OP_FALSE; some transaction forms are significantly\nmore compact if you can have failed signatures, but that's a source of\nmalleability. (are there counter examples people can think of?)\n\n\nBut as I said on IRC, I'm a bit hesitant to bake in assumptions about\nmalleability when we have no solid idea if ECC signatures are or are not\nmalleable on a fundemental level; if \"whack-a-mole\" anti-malleability is\nall we've got it could be ugly if a break is found. Similarly, we may\nfind we missed something, or some needed change makes the malleability\nrules difficult to work with for some new script type that is required.\n\nI'd rather see a new CHECKSIG mode for the case where malleability\nabsolutely must be eliminated - certain multi-party protocols - and fix\nwallet software instead. (the malleability problems people see are\nclosely related to inability to handle double-spends and reorgs) But I\ncan easily see that being an impossible goal engineering wise...\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 685 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140209/a2c80f9b/attachment.sig\u003e"}