{"type":"rich","version":"1.0","author_name":"npub1ssutaataqhl7xxp4lw6jutuhfuq5x48cf0xsxpgsxdkxkf9rl9wqnk53fg","author_url":"https://nostr.ae/npub1ssutaataqhl7xxp4lw6jutuhfuq5x48cf0xsxpgsxdkxkf9rl9wqnk53fg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-12\n📝 Original message:Instead of trying to remove the possibility of transaction\nmalleability, would it make sense to define a new, \"canonical\ntransaction hash/ID\" (cTxID), which would be a hash of the part of the\ntransaction data which we know is not malleable, and have clients use\nthis cTxID internally, thus making the traditional transaction hash\nirrelevant for a client to function correctly?\n\nWe already have a non-malleable transaction hash: the hash that is\nsigned, ie. the transaction with each scriptSig replaced by the\nscriptPubKey it redeems. This could be the cTxID.\n\nOr is this simply a too fundamental change to the way bitcoin-qt (and\nall other clients) work in order to be feasible?\n\nAs far as I can see, it completely solves the issue of not having a\ncanonical ID for a transaction, but it also increases the\ncomputational requirements for a node. For one, as far as I can see,\nit requires the node to index all transactions, because in order to\ncalculate a cTxID, it would be necessary to fetch all transactions\nreferred to by the transaction in question, in order to pull in the\nscriptPubKeys that are redeemed.\n\n\nOn Mon, Feb 10, 2014 at 4:00 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:\n\u003e\u003e Hello all,\n\u003e\u003e\n\u003e\u003e it was something I planned to do since a long time, but with the\n\u003e\u003e recent related issues popping up, I finally got around to writing a\n\u003e\u003e BIP about how we can get rid of transaction malleability over time.\n\u003e\u003e\n\u003e\u003e The proposed document is here: https://gist.github.com/sipa/8907691\n\u003e\u003e\n\u003e\u003e I expect most rules to not be controversial. Maybe rules 1 and 3, as\n\u003e\u003e they require modifications to wallet software (Bitcoin Core 0.9 and\n\u003e\u003e BitcoinJ already implement it, though) and potentially invalidate some\n\u003e\u003e script functionality. However, these new rules remain optional and\n\u003e\u003e controlled by an nVersion increase.\n\u003e\u003e\n\u003e\u003e Comments please!\n\u003e\n\u003e You should probably add making CHECKMULTISIG require the dummy value to\n\u003e be exactly equal to OP_FALSE; verifying that in the transaction itself is\n\u003e laborious. A more subtle example is we may want both CHECKSIG and\n\u003e CHECKMULTISIG to fail the transaction if the signature is invalid but\n\u003e not exactly equal to OP_FALSE; some transaction forms are significantly\n\u003e more compact if you can have failed signatures, but that's a source of\n\u003e malleability. (are there counter examples people can think of?)\n\u003e\n\u003e\n\u003e But as I said on IRC, I'm a bit hesitant to bake in assumptions about\n\u003e malleability when we have no solid idea if ECC signatures are or are not\n\u003e malleable on a fundemental level; if \"whack-a-mole\" anti-malleability is\n\u003e all we've got it could be ugly if a break is found. Similarly, we may\n\u003e find we missed something, or some needed change makes the malleability\n\u003e rules difficult to work with for some new script type that is required.\n\u003e\n\u003e I'd rather see a new CHECKSIG mode for the case where malleability\n\u003e absolutely must be eliminated - certain multi-party protocols - and fix\n\u003e wallet software instead. (the malleability problems people see are\n\u003e closely related to inability to handle double-spends and reorgs) But I\n\u003e can easily see that being an impossible goal engineering wise...\n\u003e\n\u003e --\n\u003e 'peter'[:-1]@petertodd.org\n\u003e 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Managing the Performance of Cloud-Based Applications\n\u003e Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.\n\u003e Read the Whitepaper.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=121051231\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e"}