<div dir="ltr">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.<div>
<br></div><div>First, the problems:</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>So, work in progress or done:</div><div><br></div><div><div><a href="https://github.com/bitcoin/bitcoin/pull/3659">https://github.com/bitcoin/bitcoin/pull/3659</a></div><div><a href="https://github.com/bitcoin/bitcoin/pull/3674">https://github.com/bitcoin/bitcoin/pull/3674</a></div>
<div><br></div><div>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.<br><div>
</div></div></div><div><br></div><div><br></div><div><a href="https://github.com/bitcoin/bitcoin/pull/3651">https://github.com/bitcoin/bitcoin/pull/3651</a><br></div><div><a href="https://github.com/bitcoin/bitcoin/pull/3657">https://github.com/bitcoin/bitcoin/pull/3657</a><br>
</div><div><a href="https://github.com/bitcoin/bitcoin/pull/3676">https://github.com/bitcoin/bitcoin/pull/3676</a><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><a href="https://github.com/bitcoin/bitcoin/pull/3025">https://github.com/bitcoin/bitcoin/pull/3025</a><br></div><div><br></div><div>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.</div>
<div><br></div><div><a href="https://github.com/bitcoin/bitcoin/pull/3669">https://github.com/bitcoin/bitcoin/pull/3669</a><br></div><div><a href="https://github.com/bitcoin/bitcoin/pull/3671">https://github.com/bitcoin/bitcoin/pull/3671</a><br>
</div><div><a href="https://github.com/bitcoin/bitcoin/pull/3694">https://github.com/bitcoin/bitcoin/pull/3694</a><br></div><div><br></div><div>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.</div>
<div><br></div><div>How can you help:</div><div><br></div><div>Testing and code review is, as always, the bottleneck for getting out a release with these changes.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><div>-- <br>--<br>Gavin Andresen<br>
</div></div><div><br></div></div>