Transaction malleability is once again affecting the entire Bitcoin network. Typically, this causes a lot of confusion more than anything 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 same amount of coins going to and from the same addresses, appearing. This has a different transaction ID.

Often, this different transaction ID will confirm, and in certain block explorers, you will see warnings about the original transaction being a double spend or otherwise being invalid.

Ultrastately though, just one transaction, with the correct amount of Bitcoins being sent, should confirm. If no transactions confirm, or more than one confirm, then this probably is not directly linked to transaction malleability.

However, it was noticed that there were some transactions sent that have not been mutated, and also are failing to confirm. This is because they are quite on a previous input that also will not confirm.

Essentially, Bitcoin transactions involve spending inputs (which can be thought of as Bitcoins "inside" a Bitcoin address) and then getting some change back. For instance, if I had a single 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 9 BTC (back to myself)

This way, there is a sort of chain that can be created 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 will because it generated this transaction itself, or at the very least, the whole transaction will not confirm but nothing is lost. It can immediately send on this 9 BTC in a further transaction without waiting on this being confirmed because it knows where the coins are going to and it knows the transaction information in the network.

However, this assumption is wrong.

If the transaction is mutated, Bitcoin core may end up trying to create a new transaction using the 9 BTC change, but based on wrong input information. This is due to the actual transaction ID and related data has changed in the blockchain.

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

Bitcoin exports 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 is not sufficient though, and this can result in a situation where transactions can not be sent because there are not enough inputs available with at least one confirmation to send a new transaction. Thus, we also run a process which does the following:

  1. Checks available, unspent but confirmed inputs by calling bitcoin-cli listunspent 1.
  2. If there are less than x inputs (currently twelve) then do the following:
    1. Work out what input is for around 10 BTC.
    2. Work out how to split this into as many 1 BTC transactions as possible, leaving enough space for a fee on top.
    3. Call bitcoin-cli sendmany to send that ~ 10 BTC input to around 10 output addresses, all owned by the Bitcoin marketplace.

This way, we can convert one 10 BTC input into approximately ten 1 BTC inputs, which can be used for further transactions. We do this when we are "running low" on inputs and there twelve 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 kindly on mutated change and will never be confirmed.

At present, we are researching the best way to resend these transactions. We will probably zap the transactions at an off-peak time, although we want to itemize all the transactions we think should be zapped beforehand, which will take some time.

One simple technique to decrease the chances of malleability being an issue is to have your Bitcoin node to connect to as many other nodes as possible. That way, you will be "shouting" your new transaction out and getting it popular very quickly, which will reasonably mean that any mutated transaction will get drowned out and returned first.

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

All of these malleability issues will not be a problem 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 at present, let alone a plan for migration to a new block type.

Although only brief thought has been given, it may be possible for future versions of Bitcoin software to detect themselves when malleability has occurred on change inputs, and then do one of the following:

  1. Mark this transaction as rejected and remove it from the wallet, as we know it will never confirm (potentially risky, especially if there is a reorg). Possibly inform the node owner.
  2. Attempt to "repackage" the transaction, ie use the same from and to address parameters, but with the correct input details from the change transaction as accepted in the block.

Leave a Reply

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

20 − 13 =