Bitcoin Depot ATM

0-conf series. Part 1: Support for zero-confirmation transactions at Bitcoin ATM. To be, or not to be.

Recently a news about 0-conf attack on bitcoin ATM operator circulated on the web. The attack was conducted by 4 unknown individuals in several cities in Canada back in September 2018. In total, they were reportedly able to withdraw / steal from operator $195K CAD (or $146K USD as of today’s rate).

Bitcoin ATM Attackers
Suspects in double spend attack on bitcoin ATM’s (Canada, September 2018)

Anyone with information about the identity of any of these suspects is asked to call the Calgary police service non-emergency line at 403-266-1234, regardless of what jurisdiction they live in.

In this post we try to look in details what this attack is about and why it could happen.
We try to have a deeper understanding of the problem and choice, which operators face.

Double spend attack description

This attack in general can be described as someone purchasing any goods or service by sending bitcoin (or other cryptocurrency) transaction and later on double-spending it (sending another transaction using the same UTXO (funds), but to a different destination address, usually own). At the moment around 40% of all crypto ATM’s support sell operations. That means users can send bitcoin or other cryptocurrency to ATM and get cash at the ATM. In case ATM supports withdrawal operations against zero-confirmation transaction, it introduces a risk for double spend: after getting cash from machine, attacker sends another transaction to the network with higher fees and forwarding funds to own bitcoin address. If miners replace the initial transaction with new one and mine the latter in the block (and this is generally accepted network behavior nowadays), attacker effectively gets cryptocurrency funds back and also receives cash from ATM.

This is what happened to one operator in Canada in September 2018. Four people (highly like working as a coordinated group) conducted 112 transactions at bitcoin ATM’s and got $195000 CAD in cash. The attack was conducted across 7 cities and lasted for 10 days.

Many people immediately jumped on the bandwagon to blame operator of ATM’s and their support for 0-confirmation transactions. But is it really that simple? Ironically, Peter Todd, who made double-spend on Bitcoin network much easier, was one of them:

Why full RBF, accepted as a network standard, increased the risk of double spend

Peter Todd and David Harding reintroduced replacement of transactions on the Bitcoin network via BIP 125. In initial version of bitcoin client written by Satoshi Nakamoto, there was transaction replacement in place. At this stage it was based on transaction nSequence, means it was possible to issue a new transaction and nodes will accept it if the sequence ID was higher and replace existing transaction in the mempool. This feature was removed from the client in version 0.3.12 (September 2010). Satoshi Nakamoto commented on this removal: “Disable replacement feature for now”. Such a functionality was absent in the core client for many years since then.

The rule that was generally accepted by the network (miners, non-mining nodes) for many years was First-Seen-Safe (FSS). This means nodes, when receive transactions, were checking if there was another transaction in mempool already that was spending the same UTXO, and in case such transaction was found the new one was rejected to be included in the mempool of this node and also not propagated further to the network. This effectively limited the possibility to double spend. It was still possible to double spend such transactions back then (we wrote a post on how to push stuck transactions when using bitcoin ATM back in 2016), but this was on magnitude harder level to do than today. Miners varied in policies and could accept replacement transaction even without RBF (Peter Todd double-spent own transaction to Coinbase to buy reddit gold and released Python tool for doing that. Although he used very low fee for the first transaction, which prevented it getting into mempool of miners. So even with FSS rule, this transaction was practically invisble for the network, but was accepted by Coinbase, but could be easily prevented, and this made it possible to send another transaction which was mined. There were other tools like double-spender tool). With majority miners being honest and following FSS the risk of attack was much lower, especially when network was not congested and miner fee was irrelevant in amount compared to total block reward. Otherwise, it is a general for-profit incentive to include transaction with higher fees. However, when the number of such double-spend transactions was negligible and the miner fees themselves as a part of total block reward were negligible, absolute majority of miners followed FSS rule.

BIP 125 introduced so called Replace-By-Fee (full RBF) transactions. In general this allowed to flag initial transaction as RBF and send another transaction to the network, which replaces the previous transaction if the miner fees were larger. It was promoted as opt-in feature and was very controversial at the time. See an example of discussions on reddit that was happening back in 2016. Nonetheless, such significant change was added to bitcoin core software in version 0.12.0 (November 2016).

It was initially an opt-in behavior, but since version 0.16.0 (February 2018) RBF transactions were made default behavior (switched from opt-in to opt-out) and made transaction replacement a de facto standard on the network. Such change was connected to the 1Mb limit of the block, and there was needed a tool for ordinary users to replace stuck transactions. The most controversial attribute of RBF is that it allowed to send funds to absolutely different address (full RBF), which practically means users can double spend with standard software. Alternatively, the implementation could be disallowing changing output addresses (it was known as RBF-FSS), which potentially would reduce privacy and increase transaction size, but would prevent double spends. The limit was also that wallet needed to have another unused input, which was not always the case. There were other alternative options to push transactions like Child-Pays-For-Parent (CPFP), which in practice means if transaction is stuck, users need to issue a new transaction spending output from stuck transaction with high enough fee to push both transactions to the block. Drawback here is that two transactions are needed (less efficient use of block space) and also fees need to be increased more to cover both transaction instead of one.

In practice, the result of RBF is that it is now a standard on miners side that when they see a transaction with higher fee, they replace old transaction in mempool and mine on top of the new one, which exactly allowed attackers to double spend in the above mentioned bitcoin ATM case. This was not forbidden before RBF, but network was working on another premise, and double spend transactions were not propagated among absolute majority of nodes, and further not mined.

Let’s assume that network still runs on FSS as a standard rule today (it was de facto standard between 2010 and 2016, before RBF was introduced). To double spend at bitcoin ATM’s attackers would need a malicious miner in place to mine double spend transactions and connect to such miner directly in order to send transaction, while network would reject it. Let’s assume they have access to such a miner with 10% network’s hash rate. That means in 1/10 cases they would be able to double spend. Given that 10% is an average bitcoin ATM commission charged by operators, attacker won’t earn anything on this, but just get cryptocurrency sold at market rate in 9/10 cases for cash, which eliminates any motivation to conduct such an attack. Given that the activity is recorded by camera, and attacker will highly likely be caught and go to jail for this, this further reduces even tries of this. With full RBF accepted as a default rule it allowed to get double spent transactions in 100% cases, which is the key factor for successful attack in question.

Why bitcoin ATM operators enable 0-conf withdrawals

It is important to understand, why operators set to allow zero-confirmation transactions. This is done not for lack of understanding of risk. And this is not a single case with operator in this case. Operators know the business quite well. Here is what co-founder of HoneyBadger (Canadian operator that was hit in this case) writes:

Instant withdrawals add a lot of value to end users, and improve the UX. Especially this makes sense when the main network becomes not reliable with respect to confirmations. BTC network functions on low fees for quite a while now (bear market period 2018-2019), however, there are periods when mempool increases unexpectedly and in case you send a transaction just before this happens, even with large enough miner fee at the moment it was sent out, it can still get over-bidden and then user is required to wait sometimes for several blocks before his transaction gets mined (in practice this might be 1-3 hours). Even if you include a ridiculously large miner fee, the blocks are still mined with probability targeting average time of 10 minutes between the blocks, but it can be 20-30-40 or more minutes quite often until the next block is found by chance. In this case, customer will still need to wait first confirmation, irrespective of how large the miner fee was set.

Here are several scenarios to consider for operator in favor of allowing instant cash outs:

  • Less risk for the customer of getting robbed. In case of instant payout, customer finishes transaction immediately and leaves the ATM with cash. In case, operator sets that user needs to wait for confirmations this potentially requires the customer either to wait nearby or come back later, which potentially increases the risk for such user to getting in trouble.
  • Convenience when travelling long distance. Although bitcoin ATM’s are much more popular than in the past and their number increases daily, machines are still unevenly distributed in some areas. This requires some users to travel 50 miles or more to get to closest bitcoin ATM. In case the user is not required to wait for confirmation, the withdrawal is immediate and user can travel back. Waiting for confirmations is in general waste of time for customers. Returning to ATM later is also not an option in this use case, as it requires a lot of traveling.
  • Less custodial risk for customers. Any funds sent to operator’s address are held and controlled by operator until customer receives cash. This is a risk for end-user, as once bitcoin is sent to operator, there is custodial risk involved. With cash withdrawals against 0-confirmation the risk is limited for a very short time (several seconds) and makes the user more likely to use such a machine. Also customer can split transaction into several small ones, and risk at any time only a portion of the total exchanged bitcoin funds. Main advantage here is that with 0-confirmation withdrawal several transactions can be executed one by one in a sequence within short time-frame and customer can leave the place with cash.

In general, it is obvious that accepting 0-conf is not that a crazy idea, for businesses targeting best user experience it was a generally accepted concept among operators. There are other factors to prevent fraud like cameras at place and camera on the ATM itself, which records the user while using the ATM. As we’ve seen there are pretty clear pictures of the attackers in this case (probably except the last one, who used sun glasses and probably fake beard and wig). But the rest 3 are easily visually identified. It is rather strange that police could not move forward on this case for long time.

Risk policy optimization

Another interesting circumstance about this case is that thieves were able to double spend 112 transactions over the course of 10 days. First of all $195K over 112 transactions is $1740 CAD ($1300 USD) per transaction on average, which is large amount for allowing zero-confirmation. Usually operators set smaller limits for instant cash-outs, like $500. Another aspect is 10 days period. From the perspective of risks involved, there should be close monitoring of such an activity. 10 days of ongoing attack without notice seems too long. We suspected that several operators could be hit over 10 days period and this could explain, why it went under radar for so long time. However, based on information received from industry participants, the attack was hitting one operator. We reached out to operator, but received no comments on this case.

Although the case of losing $150K as an operator sounds terrifying, this might not be that terrifying when looking from the perspective of business in general. The operator in question runs 70 ATMs across Canada (this is another reason that could allow attackers to go unnoticed longer as they used different machines in different cities). Assuming average revenue of $30K CAD ($23K USD) per machine per month, this results in turnover of $2.1 Mil CAD per month. The company charges 8-15% tiered fees on buy side and 17% on sell side. Taking average as 15% commission, this gives gross profit per month $315K CAD, and is larger than lost amount during attack. Definitely, the lost amount is significant, but it is not an amount that would lead to a bankruptcy according to the scale of business.

Most of the attackers have left clear camera records, which hopefully will lead to finding suspects and getting funds recovered.

There could potentially be better risk mitigation processes set in this case, which could prevent the whole thing from happening. Let’s assume that operator was to set $500 limit per 0-conf transaction and also set total risk at $3000 for all machines (amount of total pending 0-conf transactions at any moment). Additionally operator could have the check for the fee size, and allow 0-conf cash withdrawals only on transactions with high enough miner fees to be included in the next block. Such mitigation measures would effectively prevent any large scale double spend attack, however, fulfill needs of most legitimate customers, improving UX at the same time. Treating double spend is nothing else as finding a risk-balanced approach. Similar to the case when online merchants handle risks, accepting credit cards as a payment method, where fraud rates vary in 3-4% range. If for 1 attacker transaction there are 20 genuine users on average, this results in similar level 5% risk rate, which can be further mitigated by measures above + cameras coverage + KYC procedures (e.g. allowing 0-conf transaction only to customers, who fulfilled verifications).

Conclusion

This case demonstrates what kind of hard decisions are there for bitcoin ATM operators to take: finding a balance between good UX and limiting own risk exposure. This is another reason for the size of fees operators charge and users usually complain about. During research on this topic we reached to a number of market players (preferred to stay undisclosed) and some reported using 0-confirmation settings for particular type of transactions and having no double-spend issues for years.

We also contacted main manufacturers and providers of bitcoin ATM’s to find out what kind of features and settings are supported by each of them in regards to zero-confirmation transactions handling. These details will be covered in the next post from 0-confirmation series.

In the last post we will check what are the potential solutions developed for cryptocurrencies, which can prevent double spend attacks on the network layer level.

Leave a Reply

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