rich1.0npub1ssutaataqhl7xxp4lw6jutuhfuq5x48cf0xsxpgsxdkxkf9rl9wqnk53fghttps://nostr.ae/npub1ssutaataqhl7xxp4lw6jutuhfuq5x48cf0xsxpgsxdkxkf9rl9wqnk53fgnjumphttps://nostr.ae📅 Original date posted:2014-02-12 📝 Original message:Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, "canonical transaction hash/ID" (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete at petertodd.org> wrote: > 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 > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >