Blocks are filling up, this is expected and 100% natural and will happen to any popular decentralized cryptocurrency with Bitcoin’s design.
Now what? Do we panic at an event we knew would happen? Do we spread FUD? Do we scream “HARD FORK TO CENTRALIZATION!”? Or shout “FEE EVENT AAARGHLEBARGLE!”?
No. We calmly make a button that says Fix the problem.
This is what it does:
- You send a transaction and your transaction gets “stuck”.
- You wonder, “Huh. It’s stuck.”
- You press a button called Fix The Problem—and it magically gets unstuck!
In the future, your wallet is so smart that it always sends transactions with intelligent fees so they almost never get stuck,1 but for now you have this button.
How Does This Magic Button Work?
It sends an RBF or CPFP transaction to fix the problem and voila! The problem is fixed without any drama and you can go about your business.
What are RBF and CPFP transactions?
You send a transaction and it doesn’t have enough fees to get into a block so it gets stuck—what do you do?
Obviously, you send another transaction with a higher fee! Those are called Replace-By-Fee and Child-Pays-For-Parent transactions—two slightly different mechanisms for doing pretty much the same thing.
CPFP, functionally speaking, is a type of RBF transaction whose output (the address(es) you are sending funds to) is unchanged. Its works slightly differently in that two transactions get committed into a block instead of one (like in RBF).
An RBF transaction replaces a previous uncommitted transaction and lets you change both its fee and its output. RBF is less expensive than CPFP because you only pay for the fee of one transaction, and it’s more convenient because you can undo “stuck” or mistaken transactions.
EDIT March 6, 2016: Actually, it’s a bit more sticky than that. CPFP only allows users to fix their transaction if it was sent with a wallet that uses change addresses. If no change address was used, then only the recipient can fix the “stuck” transaction. Otherwise it will be in limbo until it gets kicked out of the node mempools (potentially many days), or eventually gets accepted into a block.
Isn’t RBF “bad” or something?
No! Whoever told you that needs to learn Bitcoin!
RBF is great! RBF is essential to Bitcoin!
Without RBF, Bitcoin’s user experience would be severly compromised, and without both RBF and CPFP people would lose Bitcoins.
In a world with fees, all transactions should be RBF-enabled by default!
However, because a seemingly large number of folk on reddit (who may or may not all be one person with sock puppets) who didn’t understand Bitcoin decided to complain, the Core Devs caved and made RBF “opt-in”, which is bad. RBF should be opt-out.
Thankfully, that’s not a big deal because CPFP uses a mechanism that will work whether or not you chose to opt-in to RBF. RBF is superior to CPFP since it’s cheaper and allows cancellation, but oh well, you made this bed thanks to your complaints, so now sleep in it!
Is your business aching for unnecessary danger? Owning Bitcoins got you bored? Well OK, but then it’s on you to opt-out of safety—not on others to opt-in to it!
Merchants that want to play with fire can take advantage of CPFP’s ability to allow them to pay for the costs of fixing a stuck transaction. To quote Core Contributor2 Matt Corallo:
Merchant should say “hey, I’ll let you send me a 0conf, with at least X fee, and if that’s not enough I’ll pay another X+Y to cpfp-it”. And the user should take that, but otherwise the default should be rbf
Before someone links me to Erik Voorhee’s post, let me quote from it here:
This post isn’t intended to debate the merits of RBF itself. Personally, while I’m not sure I see the benefit (is it a net-beneficial feature?), I’m open to the possibility that it may be. I don’t know.
Erik is an influential figure in Bitcoin land (because he’s done fantastic work with Shapeshift.io) who unfortunately doesn’t (or didn’t) understand the full implications of Bitcoin’s design and his desire to rely on 0-conf transactions represents an incorrect and dangerous use of the system.
His post is not a rational argument for or against RBF. It can be summarized as a request to make Bitcoin convenient for instant transactions.
OK! So the core devs, the lightning devs, the sidechain devs, and many others are working on making that easy,3 and there are already other ways to do it.4 But leave RBF out of it!
RBF should have been a mandatory feature, but instead a bunch of foolish Bitcoiners complained, then shot themselves in the foot, and are now complaining about the consequences.
“Waaaa! My transaction is stuck! Make the block size bigger!!”
And like their “brilliant advice” on RBF, if they manage to convince people that a hard fork to increase a number—that we know must be low—gets traction, then they’ll be whining and complaining about “Waaaa! My transaction is getting censored! Waaa! When did Bitcoin turn into PayPal?!?” etc. etc. etc.
Whose Job Is The Magic Button?
Core has finished the protocol and node-related work for RBF. The plumbing for CPFP (the “retry”-only button that works on non-RBF transactions), is unfinished. To quote Matt:
relay/mempool eviction is there, but tx selection for block-building (ie in the mining code) is not. there is a patch for it that is (apparently) far along, but i havent looked at it. miners would need to apply that patch or wait for it to be merged/released
Whatever. RBF—the superior option—is ready now.
So who are we waiting on to fix the “low-fee transactions getting stuck” problem?
Wallet developers — And this includes Core. Core’s wallet should be setting an example for the others!
Bitcoin media — It’s your responsibility to both be informed and to inform. We need you to introduce accuracy and clarity into Bitcoin’s dialogue, and don’t expect the developers to do it. Sure, they should document their work and answer questions, but their primary focus is the code itself.
Bitcoin users — There’s a difference between asking for a fix to a problem and talking out of your ass. Learn the “why’s” and “how’s” of Bitcoin, or at least stop pretending you know better than the Core developers (“contributors”, whathaveyou). Stop shouting nonsense like: “OMG THE FEE EVENT IS HERE! WE MUST HARD FORK NAO AND INCREASE THE BLOCK SIZES!!!@/J3LK$#K!!?@:!@” — You will lose your favorite toy if you keep that up.5
But mostly, we’re waiting for a decent wallet to come along that takes advantage of existing features to prevent user’s transactions from getting “stuck”.
May the best wallet(s) win!
Core developers are overloaded. This job is rest of the Bitcoin eco-system to stop the drama, stop the BS. Wallet devs, journalists, do RBF.
— Greg Slepak (@taoeffect) March 5, 2016
Update March 6, 2016: Part of the problem appears to be Bitcoin itself, as it has failed to communicate well on this matter, and refuses to improve.
- See here and here.
- Am told “Core Developer” is out of fashion now for some reason.
- While keeping Bitcoin decentralized. That’s the part many seem to keep missing.
- Even a MySQL database can work just fine for a variety of situations as a stop gap (for example, see every centralized cryptocurrency exchange). Payment channels as in Streamium. Etc.
- A hard fork is extremely dangerous. You don’t hard fork an established blockchain willy-nilly. It is very easy to screw it up and centralize (destroy) the entire system, and there are many anti-Bitcoin folks who would love to see that happen.
Greg, I think you’re very wrong in your entire argument. I think Todd is wrong when he says block sizes must be low. There are many proposals that have already been implemented and tested that would allow us to get more throughput safely. Larger blocks at this point are safe and justified. Satoshi’s original whitepaper supported scaling though larger blocks. RBF and CPFP should never have been needed and were not part of the original vision. Your claim that Voorhees “doesn’t (or didn’t) understand the full implications of Bitcoin’s design” is presumptuous and disrespectful. Mr. Voorhees is high intelligent and very knowledgeable, as he has proven many times over.
Todd was not saying that in the link I gave, so this shows you did not really read it (although, yes, Todd does hold that position, as he is right to do).
Name some then instead of just saying that.
On its own that statement is incorrect. Combined with details and caveats it could be correct depending on those details and caveats. It’s a silly statement to make by itself, however, and I will not approve any additional unsubstantiated comments along such lines as they are harmful to Bitcoin.
I’ve got too much to do to re-read it for the 6th time, but I’m fairly certain it did not. Whatever you think it said, you’re reading too much into it.
Whether or not they were part of the “original vision” is irrelevant, they are very much required.
OK, I’m sorry you feel that way, but I certainly meant no disrespect to Erik. I am just stating reality with respect to the technical limitations of the system as-is.
I’m sure he is, that doesn’t mean he is right to use 0-conf as a justification to destroy Bitcoin’s user experience by forcing people to have their money be stuck, potentially resulting in financial loss.
Additional comments on reddit.