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