Properties of Money and Full RBF
Do not expect a detailed explanation of pros and cons of full RBF in this blog post. I will focus on analyzing if Bitcoin developers are acting ethically by proposing a new Bitcoin node option to activate Full RBF.
I will use the same ethical framework I used during Segwit2x.
Summary of ethical framework for Bitcoin developers
While I highly advise you to read my article from 2017, I will try to summarize it now.
Bitcoin’s purpose is to be money. It has been fixed by satoshi, and if you think it should be anything else, there isn’t much we can discuss about, and you can close this window. I believe we have full consensus on this.
Money has some fundamental properties, which you are already familiar with: Divisibility, Portability, Defensibility, Durability. This list is somewhat arbitrary, you can probably find other properties, the important thing is that if one of those properties is corrupted beyond saving, you wouldn’t be able to call Bitcoin money anymore.
During the Segwit2x war, I made the point that raising the block size (even through the witness discount as is currently done in the consensus) was fundamentally unethical. The reason is that it was trading one property of money for another.
Bigger blocks make Bitcoin more divisible because you can make payments with smaller denominations, however, you impact defensibility. (by making it harder to run a node)
It isn’t possible to assert that divisibility is better than defensibility or vis versa without subjectivity, and as such, this change was unethical.
But reverting the block size now is also unethical, for the same reason: it trades those two properties.
Should the same ethical framework be used for node policy?
The block size is a consensus change (everybody needs to run the rule), but full RBF is a policy decided by each node operator, would the same ethical framework apply? Yes.
Imagine that Bitcoin developers decided to add an optional node policy -ofac-compliant which would allow the node operator to not relay any transaction which isn’t whitelisted by some authority. It’s clear the existence of this option would impact the portability of Bitcoin. (Making it harder/more costly to transfer Bitcoins)
Just imagine 100% of node operators using this option, and the authority deciding to ban all transactions. You wouldn’t then call Bitcoin money anymore.
Bitcoin developers can’t reject the ethical responsibility and put it on the shoulder of the node operator by saying “we just give more choice to the node operators”. The mere existence of this new policy is impacting some fundamental property of money.
Sure, the person running the node and filtering the transaction is also responsible, but Bitcoin developers also have ethical responsibility to not facilitate it.
It is also true that the node operators should have complete control over the policy rules they want to enforce, and there are two ways for bitcoin developers to allow this without running in moral hazard:
- Having the code open source
- Plugin infrastructure
Those both solutions allow developers to transfer the ethical burden to plugin developers or developers forking the code.
Is the full RBF node policy option unethical?
Now we can recognize that node policies can affect the properties of money of Bitcoin, we need to analyze the specific case of allowing node operators to activate full RBF.
Some people in the Bitcoin community feel very strongly against this.
For context you can see this video of John Carvalho from the widely successful Bitrefill service. (https://www.youtube.com/watch?v=uBRhFxfIZkE&t=5056s)
As I promised you, I will not go into the pros and cons of RBF. John asserts that this option is hurting his business, and for the sake of the argument I will not attempt to deny this.
My point is that “hurting business” doesn’t mean that Bitcoin developers did anything wrong. Even if the change was hurting businesses without any pros, it is beyond the point. All changes impact some people positively or negatively, and it is impossible to get any kind of objective measure about it.
The only thing we can objectively ask is: Does the change affect negatively some property of money?
Now I will attempt to put John’s arguments in this framework the best I can.
John claims that the full RBF option means his business can’t anymore accept any 0-conf transaction to deliver the goods immediately because any sender can easily cancel the transaction after receiving the goods. (Whether this is true, false or partially true is beyond the point, for the sake of argument let’s consider it true)
Would this impact the defensibility of Bitcoin? One could make the case that, because it is now easier to cancel a transaction before it is confirmed, then it is harder to defend your Bitcoin.
This argument doesn’t hold: Everybody will agree that unconfirmed Bitcoin aren’t your bitcoins to begin with, so there isn’t anything to defend. Only way to own Bitcoin is to get it mined into a block. The reason is that there is no consensus on what the list of unconfirmed transactions is.
When Bitcoin developers says: unconfirmed transactions aren’t safe, they aren’t saying that you shouldn’t accept them, they mean the unconfirmed Bitcoin aren’t yours, and thus a customer “cancelling” an unconfirmed transaction isn’t necessarily theft.
Another case can be made: Does full RBF impact the portability of Bitcoin? John would maintain that it makes it harder for people to spend their Bitcoin and it makes it harder for the merchant to accept Bitcoin.
This argument on the surface has some merits but fails to convince me.
If we come back to the block size debate of 2017, it is obvious to assert that if fee were infinitely high, or the block size was 0 bytes or infinitely high, Bitcoin would stop being money.
If we come back with or OFACT compliant option for node operators. What if 100% of node operators would enforce OFAC compliant transactions? Potentially not money anymore, since OFAC could in theory ban all transactions!
Now, what about 100% of node operators run with Full RBF, or 100% of node operators doesn’t run Full RBF? Bitcoin would still be money in both cases.
If we were to accept John’s argument, almost anything could be considered as impacting portability and thus be unethical: For example with the Taproot soft fork, we got a new address type.
Suddenly, some people sending Bitcoin with old wallets wouldn’t be able to send to some other people with Taproot wallets. Should those people assert that introducing a new address type is unethical because it makes sending bitcoin harder for them?
Same test can be used: If 100% of people supported taproot addresses, or if 0% of people supported taproot addresses, in both case Bitcoin would still be a perfectly fine money! Thus, introducing a new address type is ethical.
Conclusion
I presented you with a way to evaluate if introducing a full RBF option to Bitcoin core was ethical behavior by the developers.
I asserted again, as in the block size war of 2017, that the discussion shouldn’t be about pros and cons, but focused on whether the properties of money are negatively impacted.
Do not read this article as a pro full RBF post. I think it is fine to oppose or support it because of some pros/cons, it is not because something can be done ethically that it should necessarily be done, but I am not interested into going there. My only objective was to ask myself if Bitcoin developers were acting ethically, and I believe they are about the full RBF option.
As to whether I personally support full RBF option: I don’t care about it enough to oppose it.
