From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WDbUa-0005sC-C2 for bitcoin-development@lists.sourceforge.net; Wed, 12 Feb 2014 15:12:52 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.180 as permitted sender) client-ip=74.125.82.180; envelope-from=runesvend@gmail.com; helo=mail-we0-f180.google.com; Received: from mail-we0-f180.google.com ([74.125.82.180]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WDbUZ-0008Ae-8z for bitcoin-development@lists.sourceforge.net; Wed, 12 Feb 2014 15:12:52 +0000 Received: by mail-we0-f180.google.com with SMTP id u57so6157106wes.11 for ; Wed, 12 Feb 2014 07:12:45 -0800 (PST) X-Received: by 10.194.78.16 with SMTP id x16mr1155463wjw.86.1392217965153; Wed, 12 Feb 2014 07:12:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.24.170 with HTTP; Wed, 12 Feb 2014 07:12:25 -0800 (PST) In-Reply-To: <20140210030048.GB31925@savin> References: <20140210030048.GB31925@savin> From: =?ISO-8859-1?Q?Rune_Kj=E6r_Svendsen?= Date: Wed, 12 Feb 2014 16:12:25 +0100 Message-ID: To: Peter Todd Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (runesvend[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WDbUZ-0008Ae-8z Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 15:12:52 -0000 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 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >