Lately many bitcoin ATM users complained that they feed cash into machine, but don’t receive bitcoins to scanned address, or they sent bitcoins to a machine, but can’t withdraw cash. This post is supposed to check what are the possible reasons of this and how to prevent it or solve it when it happens.
Prehistory – Bitcoin network congestion and block size limit
Since Bitcoin launch in 2009 the network has been growing steadily with respect to number of transactions. There was a 1 MB limit set on block size by Satoshi Nakamoto to prevent spam/DDOS attacks on the network in the early days and this limit was left there untouched as there was a lot of space before this limit could be reached. Meanwhile, there were many hot discussions about what to do when we reach it. Unfortunately, measures were not taken on time, and today we still have this artificial limit set in the Bitcoin Core client, which is the most widely used by nodes and miners. So we reached the point when we are literally hitting the ceiling of the network capacity.
There are several solutions to this issue. For example, Core development team sees scaling in the form of Segwit (accounting trick of counting only part of transaction size towards block size limit) and later by introduction of Lightning Network payment channels, which will move most transactions off-chain. These solutions will most likely take a while to be implemented and adopted by the network and can’t help with immediate needs. On the other hand, there are alternative Bitcoin client implementations like Classic and Bitcoin Unlimited. Their development teams propose immediate increase of the network capacity by increasing the block size limit or simply removing this limit giving a freedom to take decision about size of the blocks to network participants. This will allow to have immediate effect of solving the problem for a short term, while other solutions are on the way. These changes can’t be applied until a majority of miners (75%) accept them and start using in daily mining process.
Transactions get stuck in mempool
The key take away from the previous section is that there is not enough space for all transactions on the blockchain today as the block size is artificially limited. In order to get your transaction confirmed – fees need to be higher than most of the transactions in the mempool. It is kind of auction sale when users need to outbid each other so that miner picks their transaction and put it in a next block.
It is also important to understand that issue happens only periodically when the network has a high load. Over more silent times when there are fewer transactions – payments still can go through normally. Kind of. In order to check if there are any issues on the network – it is enough to look at mempool size (how many transactions are pending in unconfirmed state). When it is 2-5MB it is a normal state. When it grows to 20-50 MB or more – the network is congested and higher fees are required. Transactions may not get confirmed for a long time when fees are not sufficient.
As we are on the very edge of capacity there is a potential “boiling point” that we can reach when mempool won’t be able to return to normal size even during “silent” periods. In this case the only optimal scenario that will happen is that users will have awful experience as transactions will get stuck for a long time in unconfirmed state. Additionally much higher fees will be required and it will revert some users to use bitcoin and they either hold their bitcoins and make payments more rarely than they do under normal conditions, or choose alternative cryptocurrencies. Both scenarios will slow down bitcoin adoption growth. This state can last until we have a solution for block size issue ready either via Segwit or via hard-fork implemented through Classic or Bitcoin Unlimited.
I sent bitcoins to an ATM but can’t withdraw cash
Now when a general picture is more or less clear let’s check how this influences users of bitcoin ATMs. When you sell bitcoins via a bitcoin ATM it is highly likely that bitcoin ATM operator has set a predefined number of confirmations required before user can withdraw cash from machine. In order to get included in the block – choose high priority fees during peak network load periods, or normal fees during normal times. That will guarantee that your transaction will be added in the next couple blocks, which is on average less than 20 minutes. Solutions like BitAccess remote bitcoin sell initiation allow you to send bitcoins without visiting machine, but then just come and get cash when it is ready and available.
There are many different wallets on the market, while not many calculate required fees properly. We recommend the following ones:
What to do if your transaction got stuck? Basically, you can’t do a lot, so it is more about sit and wait for average user until it gets confirmed. That is why it is very important to take measures ahead of time, namely: choose proper fees before the payment is done. If you really messed with fees, e.g. manually set them at a very low level, there is no chance your transaction will ever be included, so action needs to be taken. Also if you are an advanced user, there is a way to try to double spend your transaction with a different one, which will send the same amount to bitcoin ATM address, but a smaller output to your change address, which will result in higher miner fees. Here is a process which demonstrates how to double spend a transaction using coinb.in. The process becomes more complicated if your initial transaction was constructed using several inputs from different addresses as in this case you need to sign transaction with several private keys.
Another option which will become possible in the near future (probably 0.13 version) as the rewritten code is merged into Core client – to issue a new child transaction, which will use one of outputs of pending transaction. For example, using change address of your wallet or approach operator. The technique is called “child pays for parent” (CPFP). In short, this technique will allow to create a transaction using unconfirmed input from pending one and add larger than normal fees, so that fees size split across both transactions (pending and new one) is enough to reach normal level and get included in the block. Some miners used this policy, but Core version 0.12 no longer supports previously written CPFP code, adding rewritten functionality to Core client will improve efficiency of this technique in the future. Again creating a special transaction will probably require to go through a manual construction process as there is usually no way to define which UTXO to use for HD wallet. However, in this case using only one address with one private key should be enough.
How to be sure that fees are enough
As we mentioned previously it is important to set proper miner fees for your transaction. This is a nightmare from UX perspective as payers should not be doing this in a normal setup. Some wallets adjust their dynamic fees algorithms and make it simpler for end users, however, this usually results in much higher fees paid than needed. People pay 60 satoshis per byte as a median value, while required amount was about 17 satoshis per byte.
So how a fair fee level can be calculated? First of all it is important to understand that nominal fee size be it in BTC or fiat doesn’t matter. What matters is the fees in satoshis per bytes of transaction. So the bigger transaction is (e.g. several inputs from different addresses, or multisig transaction) the higher fee will be required in nominal value. Also it is important to understand that the required fee size depends on network load. In silent periods 5 sat/byte might be enough to get into any of next 6 blocks. In high load 20 sat/byte fees might be not enough to get confirmation for hours.
To get an idea of what is the current level of fees required the following resources can be useful:
This chart is run by Bitmain/Antpool, one of the largest miner pools and is quite accurate on prediction. As seen from the chart the majority of pending transactions in mempool are the ones with fees below 20 sat/byte, in this case a fee of 21 sat/byte should be enough to be included in one of the next few blocks as it will outbid absolute majority of transactions. On the right side the size of pending transactions is seen, and quick calculation shows that there are about 5 MB of pending transactions with fees higher than 20 sat/byte, which equals about 5 blocks in case they mined full. During the waiting time more transactions will be added, so it can take more than 5 blocks in this case, however, it will be confirmed during 6-8 blocks realistically, but in case of luck even earlier (different miners have different inclusion policies).
This is another similar chart provided by 21.co company.
This chart gives a prediction about delay in number of blocks. They predict that fee of 20-30 sat/bytes will result in waiting of 1-13 blocks, which according to practice is a bit higher than reality. On opposite fees of 1-10 sat/byte are estimated to help include transaction in 4-47 block, actually it might take much more than 47 blocks. E.g. if you add fee of 3 sat/byte it will probably just stuck forever.
Important to see here is that both services give similar estimations for inclusion in the next block of 60-70 sat/byte. So this is the size of transaction fees that is required to get included as fast as possible, e.g. when you send bitcoins to ATM and staying there waiting for 1 confirmation. It definitely makes sense to pay extra 9 cents (30 sat/byte for average 400 byte transaction at current market price of $750) than risk staying there and waiting that someone can rob you. However, when you want to send funds from one of your addresses to another one and want to pay as low as possible and get confirmation in reasonable time, you might want to set fees at 10-20 sat/bytes.
Many wallets software just give the option to define low/medium/high fees, which makes it impossible to define particular size you want, others give you possibility to define fees level manually. In both cases when transaction is done – it can easily be checked how big fees were, e.g. checking on blockchain.info:
In this case it is 0.0001 BTC fees for 521 bytes, which results in 0.0001*10^8/521 = 19.19 sat/byte, which seems to be a reasonable fee to be included into block during an hour or so.
This chart is pretty similar to previous two ones. Black line on the left shows cumulative distribution of transactions with different fees in mempool currently. It shows absolute majority has 10 sat/byte or less. Red line is estimation in which consequent block from now the transaction with particular fee size will be included. Again it is consistent with what we saw before, 60 sat/byte – high chances for next block, 20 sat/byte ~ 8 blocks required.
There are three estimates provided for different priority of transactions. It is BTC/KB, so in order to convert values to sat/byte one needs to multiply by 10^8 and divide by 1024. For rounding purposes 1024~1000, so it is just about multiplication by 10^5, which quickly converts to 76, 29, 24 sat/byte fees.
Another useful chart, which shows several options depending how quick you want confirmations: 1-2 blocks ~ 60 sat/byte, 5-6 blocks ~ 35 sat/byte. The good thing about this chart is that it collects data from different sources like 21.co, Copay, Blockcypher, Blocktrail, blockchain.info and gives an average of all estimations.
I purchased bitcoins from an ATM, but have not received it
This is another side of the story. First of all here it is important to distinguish two scenarios:
- There are no bitcoins sent to your address at all
- Transaction is seen on the network, but stays in unconfirmed state
The former probably indicates there was some issue on the operator’s side. For example, recently the BitGo wallet service suspension led to many Lamassu machines becoming non-working. Well, technically they were working by accepting cash, but never sent bitcoins to customers. So, contact operator and these types of problems should be solved usually without any problems. Bitcoin ATM industry is still relatively young, and there are some bumps on the road, but operators take proper measures and always help customers by sending coins manually after verifications.
In case a transaction is seen but not confirmed, this could be due to the fact that operator used not sufficient miner fees. Normally, most of operators define fees from upper range, which should be enough to confirm pretty fast. But still if there is such a problem – contact operator of bitcoin machine and they should handle it for you.