{"type":"rich","version":"1.0","author_name":"npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h","author_url":"https://nostr.ae/npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-12\n📝 Original message:I think the solution is simply to encourage Bitcoin software developers to\ndesign their software to use this static ID, instead of the full\ntransaction hash.    If MtGox had talked those IDs instead of the TX ID,\ntheir software would've correctly identified the mutated transactions and\nthere would be  no problem.\n\nArmory is slightly different, since it doesn't deal with the same stuff as\nexchanges do.  But it didn't have any problems with malleability because it\ndoesn't track anything by ID, it only pays attention to whether inputs and\noutputs are related to your wallets.  It's not necessarily hard to do it\nthis way, people just have to be aware of it.\n\n-Alan\n\nSent from my overpriced smartphone\nOn Feb 12, 2014 10:15 AM, \"Rune Kjær Svendsen\" \u003crunesvend at gmail.com\u003e wrote:\n\n\u003e Instead of trying to remove the possibility of transaction\n\u003e malleability, would it make sense to define a new, \"canonical\n\u003e transaction hash/ID\" (cTxID), which would be a hash of the part of the\n\u003e transaction data which we know is not malleable, and have clients use\n\u003e this cTxID internally, thus making the traditional transaction hash\n\u003e irrelevant for a client to function correctly?\n\u003e\n\u003e We already have a non-malleable transaction hash: the hash that is\n\u003e signed, ie. the transaction with each scriptSig replaced by the\n\u003e scriptPubKey it redeems. This could be the cTxID.\n\u003e\n\u003e Or is this simply a too fundamental change to the way bitcoin-qt (and\n\u003e all other clients) work in order to be feasible?\n\u003e\n\u003e As far as I can see, it completely solves the issue of not having a\n\u003e canonical ID for a transaction, but it also increases the\n\u003e computational requirements for a node. For one, as far as I can see,\n\u003e it requires the node to index all transactions, because in order to\n\u003e calculate a cTxID, it would be necessary to fetch all transactions\n\u003e referred to by the transaction in question, in order to pull in the\n\u003e scriptPubKeys that are redeemed.\n\u003e\n\u003e\n\u003e On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \u003e On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:\n\u003e \u003e\u003e Hello all,\n\u003e \u003e\u003e\n\u003e \u003e\u003e it was something I planned to do since a long time, but with the\n\u003e \u003e\u003e recent related issues popping up, I finally got around to writing a\n\u003e \u003e\u003e BIP about how we can get rid of transaction malleability over time.\n\u003e \u003e\u003e\n\u003e \u003e\u003e The proposed document is here: https://gist.github.com/sipa/8907691\n\u003e \u003e\u003e\n\u003e \u003e\u003e I expect most rules to not be controversial. Maybe rules 1 and 3, as\n\u003e \u003e\u003e they require modifications to wallet software (Bitcoin Core 0.9 and\n\u003e \u003e\u003e BitcoinJ already implement it, though) and potentially invalidate some\n\u003e \u003e\u003e script functionality. However, these new rules remain optional and\n\u003e \u003e\u003e controlled by an nVersion increase.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Comments please!\n\u003e \u003e\n\u003e \u003e You should probably add making CHECKMULTISIG require the dummy value to\n\u003e \u003e be exactly equal to OP_FALSE; verifying that in the transaction itself is\n\u003e \u003e laborious. A more subtle example is we may want both CHECKSIG and\n\u003e \u003e CHECKMULTISIG to fail the transaction if the signature is invalid but\n\u003e \u003e not exactly equal to OP_FALSE; some transaction forms are significantly\n\u003e \u003e more compact if you can have failed signatures, but that's a source of\n\u003e \u003e malleability. (are there counter examples people can think of?)\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e But as I said on IRC, I'm a bit hesitant to bake in assumptions about\n\u003e \u003e malleability when we have no solid idea if ECC signatures are or are not\n\u003e \u003e malleable on a fundemental level; if \"whack-a-mole\" anti-malleability is\n\u003e \u003e all we've got it could be ugly if a break is found. Similarly, we may\n\u003e \u003e find we missed something, or some needed change makes the malleability\n\u003e \u003e rules difficult to work with for some new script type that is required.\n\u003e \u003e\n\u003e \u003e I'd rather see a new CHECKSIG mode for the case where malleability\n\u003e \u003e absolutely must be eliminated - certain multi-party protocols - and fix\n\u003e \u003e wallet software instead. (the malleability problems people see are\n\u003e \u003e closely related to inability to handle double-spends and reorgs) But I\n\u003e \u003e can easily see that being an impossible goal engineering wise...\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e 'peter'[:-1]@petertodd.org\n\u003e \u003e 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e Managing the Performance of Cloud-Based Applications\n\u003e \u003e Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.\n\u003e \u003e Read the Whitepaper.\n\u003e \u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=121051231\u0026iu=/4140/ostg.clktrk\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Android apps run on BlackBerry 10\n\u003e Introducing the new BlackBerry 10.2.1 Runtime for Android apps.\n\u003e Now with support for Jelly Bean, Bluetooth, Mapview and more.\n\u003e Get your Android app in front of a whole new audience.  Start now.\n\u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=124407151\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/5c046193/attachment.html\u003e"}