Transaction malleability is once again affecting the entire Bitcoin network. Generally, 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.
Ultimately 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 isn’t 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 rely on a previous input that also won’t 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 won’t 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 because the actual transaction ID and related data has changed in the blockchain.
Hence, Bitcoin core should never 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 is not enough though, and this can result in a situation where transactions cannot 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:
Checks available, unspent but confirmed inputs by calling bitcoin-cli listunspent 1.
If there are less than x inputs (currently twelve) then do the following:
Work out what input is for around 10 BTC.
Work out how to split this into as many 1 BTC transactions as possible, leaving enough space for a fee on top.
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 rely 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 itemise 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 likely mean that any mutated transaction will get drowned out and rejected 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:
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.
Attempt to “repackage” the transaction, i.e. use the same from and to address parameters, but with the correct 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 the most easy to use site, designed for beginners but with all features the seasoned Bitcoin buyer needs.
