paint-brush
A Practical Guide To Accidental Low Fee Transactionsby@nopara73
26,222 reads
26,222 reads

A Practical Guide To Accidental Low Fee Transactions

by nopara73March 9th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

First of all: your wallet probably sucks, consider changing it.&nbsp;<br>Second: Don’t worry your coins are safe. <strong>Within three days your transaction either confirms or your coins “reappear” in your wallet.</strong> This is the short answer and it is probably correct about 99% of the times, but let’s dive deeper for in-depth understanding, then examine your options if you don’t want to just wait.<br><strong>Update: </strong>As <a href="https://www.reddit.com/r/Bitcoin/comments/69jywp/a_practical_guide_to_accidental_low_fee/dhjfthf/?utm_content=permalink&amp;utm_medium=front&amp;utm_source=reddit&amp;utm_name=Bitcoin" target="_blank">/u/ismith23 noted</a>, from Bitcoin 0.14 “transaction reappearance” happens after 2 weeks.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - A Practical Guide To Accidental Low Fee Transactions
nopara73 HackerNoon profile picture



First of all: your wallet probably sucks, consider changing it. Second: Don’t worry your coins are safe. Within three days your transaction either confirms or your coins “reappear” in your wallet. This is the short answer and it is probably correct about 99% of the times, but let’s dive deeper for in-depth understanding, then examine your options if you don’t want to just wait.Update: As /u/ismith23 noted, from Bitcoin 0.14 “transaction reappearance” happens after 2 weeks.

A more correct answer might look like this: when you send a transaction with too low fees, it stays in the mempool of most full nodes (1) until it either expires, (2) until a miner picks it up and confirms in a block or (3) until some magic makes (1) or (2) happen.

Sweet, isn’t it? Let’s decompose this sentence in the rest of this article.


1. When you send a transactions with too low fees…Ok, but how low?

According to https://bitcoinfees.21.co/ at the time of writing, too low fees means everything under 20 satoshis per transaction size in bytes won’t confirm.

https://www.smartbit.com.au/tx/9532887bee013933a6457f7967e3e0da91228ebcc4ca07016c19ce469b6136fc

If you look at your transaction in any block explorer you will see the size of it. For example the size of the transaction above is: 191 bytes. This would mean you need 3820 satoshi fees at least, so you can be sure it’ll confirm:

https://www.google.com

This is about 5 cents, or 0.00004 btc:

http://www.btcsatoshi.com/

You can also see in screenshot of the above blockexplorer the added fee was: 0.000451 btc and it actually displays the satoshi per byte, too: 236.13 sat/B, so you can safely conclude it’s going to confirm.


2. When you send a transactions with too low fees, it stays in the mempool of most full nodes…What is the mempool? Why most full nodes?

https://blockchain.info/charts/mempool-size?timespan=all

Full nodes keep unconfirmed transactions in their mempool. Some full nodes, with low resources don’t maintain mempool at all, or only keep transactions above some fees, but it really depends on the node implementation, for example:

[Source] Bitcoin Core has a default max mempool of 300 MB, after which point it will start kicking transactions and increasing the minimum fee to get accepted.

In case you want to change that behaviour … you can use the -maxmempoolsetting.

Why is this relevant? There is a chance you added such a low fees that your transaction doesn’t even get properly propagated through the entire network. Which would come handy if you would want to execute a double spend attack.


3. When you send a transactions with too low fees, it stays in the mempool of most full nodes (1) until it either expires…Surprise, even the word “expires” needs an explanation.

Since Bitcoin Core 0.12 there is an expiration time of 72 hours. This is what I meant by, when I said “your coins reappear in your wallet after 3 days“.



But this is not the whole story. This expiration time can vary between node implementation, or even completely missing. In fact, even in Core you can set the -mempoolexpiry setting.But, and it’s still not all: anyone can rebroadcast that transaction, and so bypass this expiration.I wonder if an attack would work when you setup a node and keep rebroadcasting all low-fee transactions until the end of times.

In the bigger context, it is unlikely your transaction won’t expire after 72 hours, so you don’t have to deal with it, but it’s something nice to keep in mind.

4. When you send a transactions with too low fees, it stays in the mempool of most full nodes (1) until it either expires, (2) until a miner picks it up and confirms in a block or **(3) until some magic makes (1) or (2) happen.**Magic? I know what you’re thinking. Another overcomplicated technical term. Let’s see what that means:

Opt-in Replace-by-Fee

[Source] Opt-in Replace-by-Fee (RBF) allows transactions to be flagged as replaceable until they are confirmed in a block.

However you or your wallet have to first flag the transaction to be replacable. If you are reading these lines, chances are you already missed this opportunity.

Opt-in RBF within Electrum wallet

In the reference client, set the -walletrbf option to true.

Child Pays For Parent

Before you try to understand it, try to visualize this term first, well, because it’s fun.


[Source]Child pays for parent is a way of adding fees to a transaction by making an another transaction that depends on the first.



Why wasn’t CPFP used for RBF?Child Pays For Parent (CPFP) doesn’t solve the same problem. RBF allows the spender to increase fees; CPFP is useful because it allows the recipient to increase fees. RBF has the advantage over CPFP that it doesn’t necessarily require using any extra block space, so it’s more efficient by about 30% to 90%.

This might sound a little confusing, but it’s pretty simple. Just spend the transaction your spender accidentally added too low fees to with a higher fee transaction and you’re done. Wait what? You can spend a transaction that is not confirmed? Yes, of course, however most wallets do not let you do that.

In fact, the recepient have to be able to use her/his wallet in an advanced way, if it does not make CPFP easy by default. Check out this Complete Idiot’s Guide for CPFP discussion to explore your possibilites in your specific case.

In fact as Reddit user Amichateur pointed out, if the transaction you sent have change going back to you (which almost always the case) you can spend that change back to yourself, with that executing a CPFP transaciton. So you don’t necessarily have to be on the receiver side for CPFP, most of the times the sender can do it, too.

Miner magic

What if you have a deal with a mining pool? The pool promises you to pick up your transaction, no matter how low the fee is in exchange for something.

At the time of writing ViaBTC pool offers this service in exchange for dumping some of their political views into your head. It’s easy to use, just copypaste your Transaction ID and they are going to pick it up. Note, they currently accept “a maximum of 100 TXs submitted can be accelerated every hour.”

Double spend

All the above techniques can be classified as white magic, this technique however is black magic and I am not going to detail it now, because Bitcoin developers are constantly working on how to make this black magic harder to execute, while completely eliminating it might possibly never happens, neverthless the rules of the double spending game are constantly changing.

Conclusion

When you send a transaction with too low fees, it stays in the mempool of most full nodes (1) until it either expires, (2) until a miner picks it up and confirms in a block or (3) until some magic makes (1) or (2) happen.