Transaction malleability is once more affecting the entire Bitcoin network. In general, this brings about a lot of confusion more than anything else, and results in seemingly duplicate transactions until the next block is mined. This might remain visible as the following:
Your original transaction never confirming.
Another transaction, with the identical amount of coins going to and from identical addresses, appearing. This includes a different transaction ID.
Typically, this different transaction ID is going to confirm, and in certain 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 correct amount of Bitcoins being sent, should confirm. If no transactions confirm, or even more than one confirm, then this likely isn’t directly connected to transaction malleability.
But, it was noticed that there have been some transactions sent that have not been mutated, and also are failing to confirm. This’s since they rely on a previous input that also will not confirm.
Essentially, Bitcoin transactions involve spending inputs (which could be thought of as Bitcoins “inside” a Bitcoin address) after which you can getting some change back. As an illustration, if I had one input of 10 BTC and wanted to send one BTC to someone, I will generate a transaction as follows:
Ten BTC -> one BTC (to the user) and 9 BTC (back to myself)
This way, there is a sort of chain that may be created for all Bitcoins from the original mining transaction.
Recommended–> : equipment
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 at the very least, the whole transaction will not confirm but nothing is lost. It can immediately send on this 9 BTC in an additional transaction without waiting on this being confirmed since it knows where coins will want to and it knows the transaction info in the network.
Nonetheless, this assumption is wrong.
If the transaction is mutated, Bitcoin core may end up trying to create a new transaction using the nine BTC change, but based on wrong input information. This is because the actual transaction ID and associated data has changed in the blockchain.
Hence, Bitcoin core shouldn’t trust itself in this particular instance, and should wait on a confirmation for change before sending on this change.
Bitcoin exchanges are able to configure their primary Bitcoin node to no longer allow change, with zero confirmations, to be incorporated in any Bitcoin transaction. This could be configured by running bitcoind with the -spendzeroconfchange=0 option.
This’s not enough though, which might lead to a situation where transactions cannot be sent because there are not enough inputs available with one or more confirmation to send a brand new transaction. Consequently, 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) and then do the following:
Work out what input is for around ten BTC.
Work out how you can split this into as a lot of one BTC transactions as you can, leaving enough room 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 convert one 10 BTC input into approximately ten one BTC inputs, which could be used for even more 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 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 easiest 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 ought to be zapped in advance, which will take a bit of time.
One approach that is simple to lower the chances of malleability being an issue is to have your Bitcoin node to hook up with as other nodes as you possibly can. That way, you’ll be “shouting” your new transaction out and getting it popular quickly, that will likely mean that any mutated transaction will get drowned out and rejected first.
There are a few nodes around that have anti-mutation code in already. These’re competent to detect mutated transactions and just pass on the validated transaction. It’s 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 sixty two enhancement to Bitcoin is implemented, which will make malleability impossible. This unfortunately is some way off and there’s no reference implementation at present, aside from a plan for migration to a new block type.
Although only brief thought has been given, it can be feasible 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 get rid of it from the wallet, as we know it won’t ever confirm (potentially risky, 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 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 simple to use site, designed for beginners but with all features the seasoned Bitcoin buyer needs.