The malleability of transactions is once again affecting the entire Bitcoin network. In general, this causes a lot of confusion more than anything else, resulting in seemingly duplicate transactions until the next block is mined. This can be seen as follows:
- Your original transaction is never confirmed.
- Another transaction with the same amount of coins going to and from the same addresses appears. This has a different transaction ID.
Often this other transaction ID will be confirmed, and in certain block explorers you will see warnings that the original transaction is duplicated or otherwise invalid.
Ultimately, however, only one transaction should confirm with the correct amount of bitcoins sent . If no or more than one transaction is confirmed, Bitcoin Kurs this is probably not directly related to transaction malleability.
However, it was found that some transactions were sent that were not mutated and also cannot be confirmed. This is because they are relying on a previous input, which is also unconfirmed.
Essentially, bitcoin transactions involve giving out inputs (which can be thought of as bitcoins “within” a bitcoin address) and then getting some change back. For example, if I had a single input of 10 BTC and wanted to send 1 BTC to someone, I would create a transaction like this:
10 BTC -> 1 BTC (to the user) and 9 BTC (back to myself )
In this way, there is a kind of chain that can be created for all bitcoins from the initial mining transaction.
When Bitcoin Core makes such a transaction, it trusts that it will get the 9 BTC exchanges back, and it will because it generated this transaction itself, or at least the whole transaction will not be confirmed, but nothing will be lost. He can immediately send that 9 BTC on in another transaction without waiting for it to be confirmed because he knows where the coins are going and he knows the transaction information on the network.
However, this assumption is wrong.
If the transaction is mutated, the Bitcoin core may try to create a new transaction with the 9 BTC change but based on wrong input information. This is because the actual transaction ID and associated data has changed on the blockchain .
Therefore, Bitcoin Core should never trust itself in this case and always wait for a confirmation of a change before sending that change.
Bitcoin exchanges can configure their primary Bitcoin node so that changes can no longer be included in a Bitcoin transaction without confirmation. This can be configured by running bitcoind with the -spendzeroconfchange =0 option.
However, this is not sufficient and may result in transactions not being able to be sent because there are not enough inputs with at least one confirmation to send a new transaction. Therefore, we also run a process that does the following:
- Checks available, unspent but confirmed inputs by invoking bitcoin-cli List not issued 1.
- If there are fewer than x inputs (currently twelve), do the following:
- Find out what input is for about 10 BTC.
- Think about how to break this up into as many 1-BTC transactions as possible and leave enough room on top for a fee.
- Call bitcoin-cli sendmany to send this ~10 BTC input to about 10 output addresses, all owned by the Bitcoin marketplace.
This way we can convert an input of 10 BTC into about ten inputs of 1 BTC that can be used for further transactions. We do this when we “run out” of inputs and have twelve of less left.
These steps ensure that we only send transactions with fully verified entries.
However, one problem remains – before we implemented this change, some transactions were sent that are based on mutated changes and are never confirmed.
We are currently investigating the best way to resend these transactions. We’ll likely be zapping transactions off-peak, although we want to list all transactions that we think should be zapped beforehand, which will take some time.
A simple technique to reduce the likelihood that malleability will be an issue is to connect your Bitcoin node to as many other nodes as possible. This way you will “scream” your new transaction and make it popular very quickly, which probably means that any mutated transaction will be drowned out and rejected first.
There are some nodes out there that already contain anti-mutation code. These are able to recognize mutated transactions and only pass on the validated transaction. Connecting to such trusted nodes is useful and worth considering implementing (which of course comes with its own risks).
All of these malleability issues will no longer be an issue once the BIP 62 extension is implemented for Bitcoin , which will make malleability impossible. Unfortunately, this is still a long way off and there is currently no reference implementation, let alone a plan for migrating to a new block type.
Though only briefly considered, it may be possible for future versions of Bitcoin software to recognize itself when malleability has occurred on change inputs, and then do one of the following:
- Mark this transaction as declined and remove it from the wallet as we know it will never be confirmed (potentially risky, especially with a reorganization ). If necessary, inform the node owner.
- Try repackaging the transaction, ie using the same From and To address parameters but with the correct input details from the change transaction as accepted in the block.
