{"type":"rich","version":"1.0","author_name":"npub1xvnnyhz8e4eklaakjc9xgm5w8pzkuckt923uacz2cftqdqx23g7q3c5rqg","author_url":"https://nostr.ae/npub1xvnnyhz8e4eklaakjc9xgm5w8pzkuckt923uacz2cftqdqx23g7q3c5rqg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-12\n📝 Original message:While that solution does work for many use cases, it does make it much\nharder to do anything needing chained transactions.  Granted, this is the\nshort term solution for current implementations, but having a transaction\nidentifier that does not change does open up other use cases.\n\nFor example, Alice wants to send coins to a multisignature address with\nBob, such that both parties are required to spend the coins.  Alice also\nrequires for Bob to send coins to this address as well before they will\nproceed.  Alice cannot guarantee that Bob will cooperate (and vice versa),\nso before she broadcasts the transaction to send to A+B, she sends Bob a\ntransaction that spends her incoming transaction back to herself, but has a\ntime lock of far into the future.  Bob signs this, returns it to Alice, and\nshe broadcasts her funding transaction.  At this point, Bob disappears,\nloses his key, or just decides to spite Alice and her coins are locked.\n Since she has a refund transaction, she can broadcast it in a month and\nget her coins back.  Except her funding transaction has been modified such\nthat the txhash is different, so her refund is now invalid.  She would need\nBob to issue a new refund as soon as her funding transaction hits the\nblockchain if it is modified, which defeats the point of the trustless\nrefund transaction.\n\nLonger term it would be more ideal have a canonical identifier for the\ntransaction before it even gets to the chain to support these use cases,\neven if wallets are able to properly identify the status of it's\ntransactions.  Obviously this is a difficult problem to solve and cannot be\nimplemented without breaking changes, but it would be a nice goal to be\nable to completely remove malleability.  There are other important use\ncases where having a unique identifier just for internal accounting is\ninsufficient.\n\n-Allen\n\n\nOn Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\n\u003e I think the solution is simply to encourage Bitcoin software developers to\n\u003e design their software to use this static ID, instead of the full\n\u003e transaction hash.    If MtGox had talked those IDs instead of the TX ID,\n\u003e their software would've correctly identified the mutated transactions and\n\u003e there would be  no problem.\n\u003e\n\u003e Armory is slightly different, since it doesn't deal with the same stuff as\n\u003e exchanges do.  But it didn't have any problems with malleability because it\n\u003e doesn't track anything by ID, it only pays attention to whether inputs and\n\u003e outputs are related to your wallets.  It's not necessarily hard to do it\n\u003e this way, people just have to be aware of it.\n\u003e\n\u003e -Alan\n\u003e\n\u003e Sent from my overpriced smartphone\n\u003e On Feb 12, 2014 10:15 AM, \"Rune Kjær Svendsen\" \u003crunesvend at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Instead of trying to remove the possibility of transaction\n\u003e\u003e malleability, would it make sense to define a new, \"canonical\n\u003e\u003e transaction hash/ID\" (cTxID), which would be a hash of the part of the\n\u003e\u003e transaction data which we know is not malleable, and have clients use\n\u003e\u003e this cTxID internally, thus making the traditional transaction hash\n\u003e\u003e irrelevant for a client to function correctly?\n\u003e\u003e\n\u003e\u003e We already have a non-malleable transaction hash: the hash that is\n\u003e\u003e signed, ie. the transaction with each scriptSig replaced by the\n\u003e\u003e scriptPubKey it redeems. This could be the cTxID.\n\u003e\u003e\n\u003e\u003e Or is this simply a too fundamental change to the way bitcoin-qt (and\n\u003e\u003e all other clients) work in order to be feasible?\n\u003e\u003e\n\u003e\u003e As far as I can see, it completely solves the issue of not having a\n\u003e\u003e canonical ID for a transaction, but it also increases the\n\u003e\u003e computational requirements for a node. For one, as far as I can see,\n\u003e\u003e it requires the node to index all transactions, because in order to\n\u003e\u003e calculate a cTxID, it would be necessary to fetch all transactions\n\u003e\u003e referred to by the transaction in question, in order to pull in the\n\u003e\u003e scriptPubKeys that are redeemed.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\u003e \u003e On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:\n\u003e\u003e \u003e\u003e Hello all,\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e it was something I planned to do since a long time, but with the\n\u003e\u003e \u003e\u003e recent related issues popping up, I finally got around to writing a\n\u003e\u003e \u003e\u003e BIP about how we can get rid of transaction malleability over time.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e The proposed document is here: https://gist.github.com/sipa/8907691\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e I expect most rules to not be controversial. Maybe rules 1 and 3, as\n\u003e\u003e \u003e\u003e they require modifications to wallet software (Bitcoin Core 0.9 and\n\u003e\u003e \u003e\u003e BitcoinJ already implement it, though) and potentially invalidate some\n\u003e\u003e \u003e\u003e script functionality. However, these new rules remain optional and\n\u003e\u003e \u003e\u003e controlled by an nVersion increase.\n\u003e\u003e \u003e\u003e\n\u003e\u003e \u003e\u003e Comments please!\n\u003e\u003e \u003e\n\u003e\u003e \u003e You should probably add making CHECKMULTISIG require the dummy value to\n\u003e\u003e \u003e be exactly equal to OP_FALSE; verifying that in the transaction itself\n\u003e\u003e is\n\u003e\u003e \u003e laborious. A more subtle example is we may want both CHECKSIG and\n\u003e\u003e \u003e CHECKMULTISIG to fail the transaction if the signature is invalid but\n\u003e\u003e \u003e not exactly equal to OP_FALSE; some transaction forms are significantly\n\u003e\u003e \u003e more compact if you can have failed signatures, but that's a source of\n\u003e\u003e \u003e malleability. (are there counter examples people can think of?)\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e But as I said on IRC, I'm a bit hesitant to bake in assumptions about\n\u003e\u003e \u003e malleability when we have no solid idea if ECC signatures are or are not\n\u003e\u003e \u003e malleable on a fundemental level; if \"whack-a-mole\" anti-malleability is\n\u003e\u003e \u003e all we've got it could be ugly if a break is found. Similarly, we may\n\u003e\u003e \u003e find we missed something, or some needed change makes the malleability\n\u003e\u003e \u003e rules difficult to work with for some new script type that is required.\n\u003e\u003e \u003e\n\u003e\u003e \u003e I'd rather see a new CHECKSIG mode for the case where malleability\n\u003e\u003e \u003e absolutely must be eliminated - certain multi-party protocols - and fix\n\u003e\u003e \u003e wallet software instead. (the malleability problems people see are\n\u003e\u003e \u003e closely related to inability to handle double-spends and reorgs) But I\n\u003e\u003e \u003e can easily see that being an impossible goal engineering wise...\n\u003e\u003e \u003e\n\u003e\u003e \u003e --\n\u003e\u003e \u003e 'peter'[:-1]@petertodd.org\n\u003e\u003e \u003e 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e \u003e Managing the Performance of Cloud-Based Applications\n\u003e\u003e \u003e Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.\n\u003e\u003e \u003e Read the Whitepaper.\n\u003e\u003e \u003e\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=121051231\u0026iu=/4140/ostg.clktrk\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e \u003e Bitcoin-development mailing list\n\u003e\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Android apps run on BlackBerry 10\n\u003e\u003e Introducing the new BlackBerry 10.2.1 Runtime for Android apps.\n\u003e\u003e Now with support for Jelly Bean, Bluetooth, Mapview and more.\n\u003e\u003e Get your Android app in front of a whole new audience.  Start now.\n\u003e\u003e\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=124407151\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/af6a7c54/attachment.html\u003e"}