A Practical Guide To Accidental Low Fee Transactions

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.

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:

This is about 5 cents, or 0.00004 btc:

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.

1. 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?

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.

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.

1. 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 reappears 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.

2. 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.
https://cdn-images-1.medium.com/max/800/0*SzjA-MS7fbhHMNYg.

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

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.