Sunday, May 9

Transaction malleability is again affecting the entire Bitcoin network. By and large, this brings about 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 exactly the same amount of coins going to and from identical addresses, appearing. This features another transaction ID.
Often, this different transaction ID will confirm, and in certain 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 even much more than one confirm, then this possibly isn’t directly linked to transaction malleability.

Nonetheless, it was observed that there have been some transactions sent that haven’t been mutated, plus it are failing to confirm. This’s because they rely on a previous input which won’t confirm.

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

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

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

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

Nevertheless, this assumption is wrong.

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

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

Recommended–> : mining
Bitcoin exchanges can configure their primary Bitcoin node to not anymore allow change, with zero confirmations, to be included in any Bitcoin transaction. This could be configured by running bitcoind with the -spendzeroconfchange=0 option.

This’s not enough though, and this can result in a situation where transactions can’t be sent because there are not enough inputs available with a minimum of one confirmation to send out a new transaction. As a result, we also run a process which does the following:

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

Work out what input is for around 10 BTC.
Work out how to split this into as a lot of 1 BTC transactions as possible, leaving enough room for a fee on top.
Call bitcoin cli sendmany to send that ~10 BTC input to around 10 output addresses, all owned and operated by the Bitcoin marketplace.
This way, we are able to change one 10 BTC input into approximately 10 one BTC inputs, that could be 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 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 proper way to resend these transactions. We will probably zap the transactions at an off-peak time, though we want to itemise most of the transactions we think ought to be zapped in advance, which will have some time.

One technique which is simple to lower the chances of malleability being an issue is to have your Bitcoin node to hook up to as various other nodes as you possibly can. That way, you will be “shouting” your new transaction out and getting it popular very quickly, that 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’s 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 will not 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 at present, let alone a plan for migration to a new block type.

Although only brief thought has been given, it could be possible for future versions of Bitcoin software to identify 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 won’t ever confirm (potentially unsafe, particularly if there’s a reorg). Possibly inform the node owner.
Attempt in order to “repackage” the transaction, i.e. use the same from and also to address parameters, but with the right input details from the change transaction as accepted in the block.
Bittylicious is the UK’s premier place to buy and sell Bitcoins. It is 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 *