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

Transaction malleability is once again affecting the entire Bitcoin network. Generally, this brings about a lot of confusion above all else, and results in seemingly duplicate transactions until the next block is mined. This can be seen as the following:

Your original transaction never confirming.
Another transaction, with the identical amount of coins going to and from the same addresses, appearing. This contains another transaction ID.
Generally, this different transaction ID will confirm, and in certain block explorers, you’ll see warnings about the initial transaction being a double spend or otherwise being invalid.

Ultimately though, only one transaction, with the proper amount of Bitcoins being sent, should confirm. If no transactions confirm, or perhaps more than one confirm, then this almost certainly isn’t directly connected to transaction malleability.

However, it was observed that there have been some transactions sent that have not been mutated, plus it are failing to confirm. This is because they rely on a previous input that also won’t confirm.

Essentially, Bitcoin transactions involve spending inputs (which are usually thought of as Bitcoins “inside” a Bitcoin address) after which you can getting some change back. For instance, if I’d one input of 10 BTC and wanted to send 1 BTC to someone, I would create a transaction as follows:

10 BTC -> 1 BTC (to the user) and nine BTC (back to myself)

This way, there’s a type of chain that will be created for all Bitcoins from the initial mining transaction.

When Bitcoin core does a transaction this way, it trusts that it is going to get the nine BTC change back, and it’ll because this transaction was generated by it itself, or perhaps at the very least, the whole transaction won’t confirm but nothing is lost. It can quickly send on this nine BTC in an additional transaction without waiting on this being confirmed because it knows where the coins want to and it knows the transaction information in the network.

However, this assumption is wrong.

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

Hence, Bitcoin core must not trust itself in this instance, and must 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 incorporated in any Bitcoin transaction. This may be configured by running bitcoind with the -spendzeroconfchange=0 option.

This is not enough though, and this can result in a situation where transactions cannot be sent because there aren’t enough inputs available with one confirmation to send out a new transaction. Thus, we also run a process that does the following:

Checks available, unspent but confirmed inputs by calling bitcoin cli listunspent one.
If there are below cheap cryptocurrency mining hardware (currently twelve) and 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 change one 10 BTC input into approximately ten one BTC inputs, which can be used for further transactions. We do this when we’re “running low” on inputs and there twelve of less remaining.

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

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

At this time, we’re researching the simplest way to resend these transactions. We will probably zap the transactions at an off peak time, nonetheless, we want to itemise most of the transactions we think should be zapped beforehand, which will bring some time.

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

There are a few nodes out there that have anti-mutation code in already. These’re competent to detect mutated transactions and just pass on the validated transaction. It is useful to connect to trusted nodes this way, and worth considering implementing this (which will come with its own risks of course).

All of these malleability issues won’t be an issue once the BIP 62 enhancement to Bitcoin is implemented, which will make malleability impossible. This unfortunately is some way off and there is no reference implementation currently, not to mention a plan for migration to a new block type.

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

Mark this transaction as rejected and remove it from the wallet, as we know it will never confirm (potentially unsafe, especially if there’s a reorg). Possibly inform the node owner.
Attempt in order to “repackage” the transaction, i.e. use identical from as well as 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 simple 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 *