Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGVjt-0002k1-MZ for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 15:40:41 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.47 as permitted sender) client-ip=209.85.213.47; envelope-from=gavinandresen@gmail.com; helo=mail-yh0-f47.google.com; Received: from mail-yh0-f47.google.com ([209.85.213.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGVjs-0005SG-La for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 15:40:41 +0000 Received: by mail-yh0-f47.google.com with SMTP id c41so814973yho.20 for ; Thu, 20 Feb 2014 07:40:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.236.120.147 with SMTP id p19mr4282147yhh.6.1392910834616; Thu, 20 Feb 2014 07:40:34 -0800 (PST) Received: by 10.170.133.213 with HTTP; Thu, 20 Feb 2014 07:40:34 -0800 (PST) Date: Thu, 20 Feb 2014 10:40:34 -0500 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: multipart/alternative; boundary=20cf3010e48d8050eb04f2d853bd X-Spam-Score: -0.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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1WGVjs-0005SG-La Subject: [Bitcoin-development] Transaction malleability in the core code: update 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: Thu, 20 Feb 2014 15:40:41 -0000 --20cf3010e48d8050eb04f2d853bd Content-Type: text/plain; charset=ISO-8859-1 A quick update on the state of transaction malleability work in Bitcoind/Bitcoin-Qt (aka Bitcoin Core). This is not about longer-term malleability issues, just the very short-term work being done (or already done) to the reference implementation. First, the problems: We've had a longstanding TODO to improve the way the core code deals with double-spends. From the core code's point of view, malleable transactions are just one particular form of double-spend. Improving double-spend handling never made it to the top of the TODO list, because the cases where it happened involved doing unsupported things (like copying your wallet.dat to another machine and then spending on both machines). And because there is a heavy-handed workaround if a wallet becomes confused because of a double-spend: restore all of the keys, rescan for transactions confirmed in the blockchain, and any outputs tied up in double-spends get released. Coins (really, unspent transaction outputs) were never permanently lost, but they could be tied up and unspendable when associated with a 0-confirmation transaction that would never confirm. So, work in progress or done: https://github.com/bitcoin/bitcoin/pull/3659 https://github.com/bitcoin/bitcoin/pull/3674 These implements a kinder, gentler sledgehammer (-zapwallettxes) to fix a confused wallet. If you have a wallet with 0-confirmation transactions that are tying up bitcoins these should fix it. https://github.com/bitcoin/bitcoin/pull/3651 https://github.com/bitcoin/bitcoin/pull/3657 https://github.com/bitcoin/bitcoin/pull/3676 These three merged pull requests implement a new command-line option: -nospendzeroconfchange . The best way to get a wallet confused is to spend zero-confirmation change outputs that you created yourself; if the transaction creating the change gets mutated, then the subsequent transaction is invalid and will never confirm. The core code spends unconfirmed change only as a last resort. If you are a service using bitcoind that generates a lot of transactions then best practice would be to run with -nospendzeroconfchange, and use "sendmany" to batch payments only after previous payments have confirmed. https://github.com/bitcoin/bitcoin/pull/3025 This tightens up the IsStandard() rule, so the easiest-to-implement method of mutating transactions is blocked. Many big mining pools are already running this patch. https://github.com/bitcoin/bitcoin/pull/3669 https://github.com/bitcoin/bitcoin/pull/3671 https://github.com/bitcoin/bitcoin/pull/3694 These three get at the root of the problem; they rework the core wallet code to implement "handle double spends better." See the pull requests for details. How can you help: Testing and code review is, as always, the bottleneck for getting out a release with these changes. We have a chronic problem with people running Bitcoin services on top of the core code waiting until there is an "official" release, and then assuming that somebody else has done the hard work of reviewing and testing the changes. YOU SHOULD NOT BE MAKING THAT ASSUMPTION! Your particular RPC call usage might trigger some edge-case bug that was missed, or perhaps the size of your wallet triggers a performance problem introduced by a fix. Or, in other words: do not treat the core development team as if we were a commercial company that sold you a software library. That is not how open source works; if you are making a profit using the software, you are expected to help develop, debug, test, and review it. -- -- Gavin Andresen --20cf3010e48d8050eb04f2d853bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A quick update on the state of transaction malleability wo= rk in Bitcoind/Bitcoin-Qt (aka Bitcoin Core). This is not about longer-term= malleability issues, just the very short-term work being done (or already = done) to the reference implementation.

First, the problems:

We've had = a longstanding TODO to improve the way the core code deals with double-spen= ds. From the core code's point of view, malleable transactions are just= one particular form of double-spend.

Improving double-spend handling never made it to the to= p of the TODO list, because the cases where it happened involved doing unsu= pported things (like copying your wallet.dat to another machine and then sp= ending on both machines).

And because there is a heavy-handed workaround if a wal= let becomes confused because of a double-spend: =A0restore all of the keys,= rescan for transactions confirmed in the blockchain, and any outputs tied = up in double-spends get released. Coins (really, unspent transaction output= s) were never permanently lost, but they could be tied up and unspendable w= hen associated with a 0-confirmation transaction that would never confirm.<= /div>

So, work in progress or done:




Thes= e three merged pull requests implement a new command-line option: -nospendz= eroconfchange . =A0The best way to get a wallet confused is to spend zero-c= onfirmation change outputs that you created yourself; if the transaction cr= eating the change gets mutated, then the subsequent transaction is invalid = and will never confirm.

The core code spends unconfirmed change only as a last = resort. If you are a service using bitcoind that generates a lot of transac= tions then best practice would be to run with -nospendzeroconfchange, and u= se "sendmany" to batch payments only after previous payments have= confirmed.


=
This tightens up the IsStandard() rule, so the easiest-to-implement me= thod of mutating transactions is blocked. Many big mining pools are already= running this patch.


Thes= e three get at the root of the problem; they rework the core wallet code to= implement "handle double spends better." =A0See the pull request= s for details.

How can you help:

Testing and = code review is, as always, the bottleneck for getting out a release with th= ese changes.

We have a chronic problem with people= running Bitcoin services on top of the core code waiting until there is an= "official" release, and then assuming that somebody else has don= e the hard work of reviewing and testing the changes.

YOU SHOULD NOT BE MAKING THAT ASSUMPTION! =A0Your parti= cular RPC call usage might trigger some edge-case bug that was missed, or p= erhaps the size of your wallet triggers a performance problem introduced by= a fix.

Or, in other words: do not treat the core development t= eam as if we were a commercial company that sold you a software library. Th= at is not how open source works; if you are making a profit using the softw= are, you are expected to help develop, debug, test, and review it.

--
--
Gavin Andresen

--20cf3010e48d8050eb04f2d853bd--