Bittylicious Blog

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.

Change outputs

However, Bittylicious 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.

Mitigation steps on Bittylicious

We have configured our primary Bitcoin node to no longer allow change, with zero confirmations, to be included in any Bitcoin transaction. This was 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:

1. Checks available, unspent but confirmed inputs by calling bitcoin-cli listunspent 1.
2. If there are less than x inputs (currently twelve) then do the following:
   1. Work out what input is for around 10 BTC.
   2. Work out how to split this into as many 1 BTC transactions as possible, leaving enough space for a fee on top.
   3. Call bitcoin-cli sendmany to send that ~10 BTC input to around 10 output addresses, all owned by Bittylicious.

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.

Fixing old transactions

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.

Other techniques to decrease the impact

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).

The future, from a Bitcoin perspective

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.

It may be the case that the above is impossible, as these really are just rambling thoughts.

Credits

Written by Marc Warne of Bittylicious.

Assistance and good chat from iwilcox, midnightmagic and Victorsueca of the #bitcoin IRC channel.

It has been exactly two years since Bittylicious was first announced to the public on BitcoinTalk.

Back then, Bittylicious was a simple service with all sales being done by just one person. You could only buy Bitcoins for UK bank transfers, the limits were quite low, and most things were manual.

Bitcoins only cost around £70 each back then, and the regulatory environment was totally unknown. There was a lot of fear about needing to be regulated by the FCA (FSA back then), worries about VAT being charged and fears about banks shutting down accounts. Alas, the last worry is still one to this day.

It became apparent that if Bittylicious were to survive, it would need to evolve into a marketplace so that multiple bank accounts could be used and, in theory, cheaper prices could be achieved if there were competition. This was clearly the correct decision to make.

Two years on and Bittylicious is multi-seller, multi-payment method, multi-country, multi-currency, multi-altcoin and multi-direction. The fraud environment has changed significantly, as has the general recommendations for AML and KYC, so Bittylicious constantly needs to evolve. Bittylicious is developed to this day, and even two years on, this is just the beginning.

To the moon!

Bittylicious users often enjoy pretty good rates, exceptionally quick purchases and brilliant customer service, but we would just like to toot our own trumpets a little by saying just how darned well nice the brokers on the platform are.

The main admin (Marc) helped out one of the brokers who was having issues with their bank account being frozen. Marc wrote a letter to the bank stating that his transactions were legitimate. In part because of this, the broker’s bank account was made available again. As a wonderful gesture of thanks, this broker sent Marc some lovely jamón brought all the way back from Spain. Yum!

Sometimes issues happen, often caused by external services such as banks. The first line of support is the brokers, who pass issues up the chain if needed. These are the guys and girls that keep the Bittylicious platform running so well, and they’re a really decent bunch of people. Bravo!

HM Treasure recently published a report summarising the inputs received for their call for information on digital currencies.

The report seems to present an accurate summary of the main benefits and disadvantages for against digital currencies that we have heard of, with a primary focus on its use as a currency rather than Bitcoin 2.0 topics such as smart contracts. This is wise, given the maturity of using cryptocurrencies as a “money”.

The government’s next steps are as follows:

• The government intends to apply anti-money laundering regulation to digital currency exchanges in the UK, to support innovation and prevent criminal use. The government will formally consult on the proposed regulatory approach early in the next Parliament.
• As part of this consultation on the proposed regulatory approach, the government will look at how to ensure that law enforcement bodies have effective skills, tools and legislation to identify and prosecute criminal activity relating to digital currencies, including the ability to seize and confiscate digital currency funds where transactions are for criminal purposes.
• The government will work with BSI (British Standards Institution) and the digital currency industry to develop voluntary standards for consumer protection.
• The government is launching a new research initiative which will bring together the Research Councils, Alan Turing Institute and Digital Catapult with industry in order to address the research opportunities and challenges for digital currency technology, and will increase research funding in this area by £10 million to support this.

I think few would disagree with the increased funding research into digital currencies, or the improvement in skills, tools and legislation to identify and prosecute criminal activity relating to illegal use of digital currencies.

I believe that the proposed steps regarding regulation are generally sensible. Some AML regulation for digital currency exchanges, including Bittylicious, makes sense to me. I feel it may be wise to limit this to on and off ramps at this stage rather than crypto-to-crypto exchanges. A light touch approach, such as HMRC’s general AML policies, make sense for fiat-to-crypto exchanges, and many legitimate businesses such as ourselves are already implementing such procedures, even if not required. Bittylicious doesn’t require KYC documents for small(ish) purchases and sales, but we do for larger purchases. This is actually mostly for anti-fraud reasons, but this goes hand-in-hand with general KYC best practices.

In addition, I particularly like the initial approach to produce a set of voluntary standards for consumer protection rather than harsh regulation which will drive out innovative, small companies. A standard seal, or something along those lines, may be a good confidence indicator for consumers.

What we would like to see is more of an emphasis on convincing or even forcing banks to cooperate with cryptocurrency businesses and offer bank accounts of some sort. This is lightly mentioned in the report, with (in our opinion) a fairly poor excuse, and it would have been great to see this pushed along more strongly.

All in all, the response seems sensible and it is refreshing to hear a government that is not going overboard like certain states in the USA or even Germany trying to fit digital currencies into a legal box that doesn’t quite suit.

Some Bittylicious regulars, including staff and sellers, will be meeting up at The Pembury Tavern on the evening of Friday 12th December starting at around 6.30pm. This pub is in Hackney, London. Everyone is welcome to join us for an informal evening of Bitcoin chat, and you can pay for your beers and food using Bitcoin as well.

Look out for a big ‘B’ symbol on one of the tables. Hopefully we can light it up and it’ll be pretty obvious where we are, so come and say hello.