Remember that you can use CPFP or RBF to get your transactions confirmed faster.

All three solutions below, attempt to solve the same problem, the issue of stuck transactions.Due to the behavior of Bitcoin Core with respect to double spends (they are silently dropped, and not relayed), it is impossible to spend outputs that you've used in an existing transaction. Typically this is a good thing, but there are a few cases where a user may have created a malformed transaction (for example, accidentally setting 0 fees) that isn't acceptable or mine-able for various reasons, and it's desirable for them to be able to reissue a fixed transaction.This is exacerbated by the undefined memory pool behavior of nodes with respect to expiring out old transactions, and not having a clear rule as to when it's safe to attempt another spend.1) Child-Pays-For-Parent (CPFP)The Child-Pays-For-Parent approach allows the fees of a transaction's child (the transaction that spends the outputs of the stuck transaction) to also pay for the parent transaction. This allows a merchant to spend the "broken" transaction they received like any other transaction, and the system should return to a consistent state.The benefit of Child-Pays-For-Parent is that it solves the problem in a way that doesn't fundamentally change the mechanics for how a transaction is selected and kept (most notably, the first-seen memory pool behavior). In my opinion, this makes this solution the most intuitive.However, the difficulty with Child-Pays-For-Parent is in the implementation. There are some required changes to the propagation of transactions that are required to make this work properly (since just broadcasting a valid child will cause other nodes to consider the transaction as orphaned, without the context of the parent).2) Replace-By-Fee (RBF)Replace-by-fee attempts to address the problem by changing the fundamental rule for accepting and keeping transactions, the "first-seen" rule.In this system, a transaction with higher fees can spend already spent inputs (that have not yet been confirmed in a block), and will replace that transaction in the memory pool.The benefit of this system is that it changes the fundamental transaction selection rule but does not require changes to the way fees are calculated.The downside is that this represents a significant shift in terms of expected memory pool behavior. In my opinion, this makes transactions less predictable; the first-seen rule is straightforward, predictable, and easy to understand and implement. Additionally, it breaks any functionality that relies on the predictability of unconfirmed transactions by making it trivial to issue double spends. (Double spending a first seen transaction requires a combination of moderate network and computing resources, some decent know-how, and some luck. Double spending in a replace-by-fee world requires none of the above.)3) First-Seen-Safe Replace-By-Fee (FSS RBF)This one attempts to make RBF compatible with first-seen memory pool implementations by requiring that the outputs from the original transaction be maintained by subsequent respends.The benefits are that in some situations, first-seen behavior can be relied upon. A transaction sending x BTC to a merchant cannot revoke that.In practice, however, this protection is pretty weak. It trivially breaks transactions that spend other unconfirmed transactions by allowing the first transaction in the chain to be replaced, invalidating future outputs. This means that the burden for double spending an unconfirmed transaction becomes only slightly higher than in standard replace-by-fee.It does, theoretically, allow one to accept an unconfirmed transaction that spends a confirmed output with similar protections as the typical first-seen behavior.It is impossible to talk about this without touching on the politics, though. The reason this is so contentious is that it involves a political change that breaks many systems that rely on first-seen memory pool behavior. The proponents of the change believe that since unconfirmed transactions are not subject to the same cryptographic protections as confirmed transactions, they should be pushed out of the ecosystem and tools that facilitate this should be adopted. The people who oppose this change believe that unconfirmed transactions represent an acceptable risk as with everything in Bitcoin (remember, Bitcoin requires a majority of honest miners, for example), and that breaking something many people rely on unnecessarily is a net negative.http://bit.ly/2kq6lED: More info on this sticky via /r/Bitcoin http://bit.ly/2kaFjmp