Bitcoin Transaction Malleability, Zero Change Inputs and How It Affects Bitcoin Exchanges

cryptocurrency mining hardware is once more affecting entire Bitcoin network. Generally, this brings about a great deal of confusion above all else, and results in seemingly duplicate transactions until the next block is mined. This might be observed as the following:

Your original transaction never confirming.
Another transaction, with the same amount of coins going to and from similar addresses, appearing. This includes another transaction ID.
Usually, this different transaction ID will confirm, and in specific block explorers, you will see warnings about the initial transaction being a double spend or even otherwise being invalid.

Ultimately though, only one transaction, with the proper amount of Bitcoins being sent, should confirm. If no transactions confirm, or much more than one confirm, then this most likely isn’t directly associated to transaction malleability.

But, it was noticed that there were some transactions sent that have not been mutated, plus it are failing to confirm. This is as they rely on a previous input which will not confirm.

Essentially, Bitcoin transactions involve spending inputs (which can be thought of as Bitcoins “inside” a Bitcoin address) then getting some change back. For example, in case I’d one input of ten BTC and wanted to send one BTC to someone, I would develop a transaction as follows:

10 BTC -> one BTC (to the user) and 9 BTC (back to myself)

This way, there’s a sort of chain which will be produced for all Bitcoins from the initial mining transaction.

When Bitcoin core does a transaction like this, it trusts that it will get the 9 BTC change back, and it’ll as this transaction was generated by it itself, or at the very least, the entire transaction will not confirm but nothing is lost. It can quickly send on this 9 BTC in an additional transaction without waiting on this being confirmed as it knows where coins want to and it knows the transaction info in the network.

But, this assumption is wrong.

If the transaction is mutated, Bitcoin core could end up trying to make a whole new transaction using the 9 BTC change, but based on wrong input info. This’s because the actual transaction ID and relevant data has changed in the blockchain.

Hence, Bitcoin core should not trust itself in this instance, and should always wait on a confirmation for change before sending on this change.

Bitcoin exchanges can configure their primary Bitcoin node to no longer allow change, with zero confirmations, to be included in any Bitcoin transaction. This may be configured by running bitcoind with the spendzeroconfchange=0 option.

This’s not enough though, and this also might bring about a situation where transactions can’t be sent because there are certainly not enough inputs available with at least one confirmation to send out a whole new transaction. Thus, we also run a process which in turn does the following:

Checks available, unspent but confirmed inputs by calling bitcoin cli listunspent one.
If there are less than x inputs (currently twelve) then do the following:

Work out what input is for around ten BTC.
Work out how to split this into as many one BTC transactions as you possibly can, leaving enough space for a fee on top.
Call bitcoin-cli sendmany to send that ~10 BTC input to around ten output addresses, all run by the Bitcoin marketplace.
This way, we can turn one 10 BTC input into approximately ten 1 BTC inputs, that can be used for even more transactions. We do this when we are “running low” on inputs and there 12 of less remaining.

These steps ensure that we will only ever send transactions with fully confirmed inputs.

One issue remains though – before we implemented this change, some transactions got sent that rely on mutated change and will never be confirmed.

At this time, we’re researching the easiest way to resend these transactions. We’ll probably zap the transactions at an off peak time, although we want to itemise every one of the transactions we think should be zapped in advance, which will take a little time.

One simple technique to minimize the chances of malleability being an issue may be to have your Bitcoin node to hook up to as several other nodes as is possible. That way, you’ll be “shouting” your new transaction out and getting it popular very quickly, which will probably mean that any mutated transaction will get drowned out and rejected first.

There are some nodes available that have anti mutation code in already. These are competent to detect mutated transactions and simply pass on the validated transaction. It is useful to connect to trusted nodes this way, and worth taking into consideration implementing this (which will come with its very own risks of course).

All of these malleability issues won’t be a problem once the BIP sixty two enhancement to Bitcoin is implemented, which will make malleability impossible. This unfortunately is some way off and there is absolutely no reference implementation currently, aside from a plan for migration to a new block type.

Although only brief thought has been given, it can be feasible for future versions of Bitcoin software to discover themselves when malleability has occurred on change inputs, and after that do one of the following:

Mark this transaction as rejected and remove it from the wallet, as we know it won’t ever confirm (potentially unsafe, particularly if there is a reorg). Possibly inform the node owner.
Attempt to be able to “repackage” the transaction, i.e. use identical from and to address parameters, but with the appropriate input details from the change transaction as accepted in the block.
Bittylicious is the UK’s premier place to buy and sell Bitcoins. It’s probably the most all too easy to use site, designed for beginners but with all features the seasoned Bitcoin buyer needs.

Leave a Reply

Your email address will not be published. Required fields are marked *