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

Transaction malleability is once again affecting the entire Bitcoin network. Generally, this produces a lot of confusion more than anything else, and results in seemingly duplicate transactions until another block is mined. This may 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.
Generally, this different transaction ID is going to confirm, and in specific block explorers, you will see warnings about the first transaction being a double spend or even otherwise being invalid.

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

But, it was noticed that there have been some transactions sent that haven’t been mutated, and in addition are failing to confirm. This is because they rely on a previous input that also will not confirm.

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

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

This way, there is a form of chain that could be developed for all Bitcoins from the first mining transaction.

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

Nonetheless, this assumption is wrong.

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

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

Bitcoin exchanges are able to configure their primary Bitcoin node to not anymore 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 also will contribute to a situation where transactions can’t be sent because there aren’t enough inputs available with a minumum of one confirmation to send out a whole new transaction. Hence, we also run a process which does the following:

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

Work out what input is for around 10 BTC.
shiba inu coin out the way to split this into as a lot of 1 BTC transactions as you 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 are able to turn one ten BTC input into approximately ten 1 BTC inputs, which are usually used for more transactions. We do this when we’re “running low” on inputs and there 12 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 present, we are researching the best way to resend these transactions. We will probably zap the transactions at an off peak time, even thought we want to itemise all the transactions we think should be zapped beforehand, which will bring a little time.

One method which is simple to reduce the chances of malleability being an issue may be to have your Bitcoin node to hook up with as several other nodes as you possibly can. That way, you will be “shouting” your new transaction out and getting it popular quickly, that 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’re competent to detect mutated transactions and simply pass on the validated transaction. It’s useful to connect to trusted nodes this way, and worth considering implementing this (which will come with its very 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’s absolutely no reference implementation at present, not to mention a plan for migration to a new block type.

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

Mark this transaction as rejected and get rid of it from the wallet, as we know it will never confirm (potentially unsafe, particularly 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 easy to use site, designed for beginners but with all features the seasoned Bitcoin buyer needs.

Related Posts

Leave a Reply

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