The Case for Replace-By-Fee (And the Case Against)
The heated debate in the Bitcoin community throughout the past months not only concerns the block size dispute. Another technical change at the center of conflict is replace-by-fee, a version of which was included in the latest release of Bitcoin Core – while the next version of Bitcoin Classic will have no replace-by-fee at all.
An often-heard criticism against replace-by-fee is that it creates new problems while it doesn’t really solve any existing ones. But that criticism is questionable.
Below is the case for replace-by-fee. (And the case against.)
Replace-by-Fee Explained
What is replace-by-fee?
Replace-by-fee is a mempool policy. Mempools are collections of unconfirmed transactions stored by full nodes, and are used by miners to select transactions to include in blocks.
For the past years, most nodes on the Bitcoin network applied a “first-seen” mempool policy. If a node received two conflicting transactions (spending the same inputs) the latest was always rejected.
Replace-by-fee, as the name suggests, instead allows transactions in the mempool to be replaced by newer transactions, if they include a higher fee.
There are some variants of replace-by-fee as well, including the one adopted by Bitcoin Core. But we’ll get to that in a bit.
The Case Against Replace-by-Fee
What’s the problem with replace-by-fee?
Basically, replace-by-fee enables users to easily double-spend unconfirmed transactions. Someone could – for instance – make a purchase with bitcoins, but quickly afterward send these same bitcoins back to himself.
Perhaps most important, replace-by-fee could disadvantage Bitcoin payment processors that effectively built (a part of) their business on instant payments. Merchants selling digital goods, and merchants selling physical goods from brick-and-mortar stores, could be negatively affected as well; it’s impractical to have customers wait several minutes for a confirmation. And if services stop accepting (unconfirmed) Bitcoin transactions because of this, their customers would arguably be disadvantaged, too.
An additional detriment of replace-by-fee might be the added complexity it introduces. Wallet software may require additions that confuse regular users, and – like any other software extension – there’s always a small risk that badly implemented code could introduce new bugs or other weaknesses.
Unconfirmed Transactions
Now, given these obvious detriments, why is this feature even considered at all?
Perhaps the most common argument in defense of replace-by-fee is a simple one: Unconfirmed transactions were never secure, and it was always unwise to rely on them.
While it’s probably true that replace-by-fee would make it easier and cheaper for most people to double-spend a transaction right now, it is already very easy and cheap for those who know what they’re doing.
Tricks to double-spend can be as trivial as sending a first transaction with a low enough fee to be rejected by most miners, followed by a conflicting transaction with sufficient fee. There is even a publicly available script that automates this, which has proved quite successful.
Meanwhile, more advanced solutions – including payment channels, sidechains, multisig solutions and the Lightning Network or similar solutions – actually can offer instantly secure Bitcoin transactions, regardless of replace-by-fee. Though, of course, not all of these are rolled out yet.
‘Un-stuck’ Transactions
What is perhaps more important is: Replace-by-fee solves real problems.
Very relevant in light of recent events, replace-by-fee can be used to get transactions “un-stuck.”
As traffic on the Bitcoin network continues to increase – either legitimately or through “spam” attacks – not all transactions are included in blocks, or it can take a long time. While this is not new and has occurred before, a sudden surge in transaction volume last week highlighted the problem.
And what’s more, if miners apply a first-seen policy, it means that transactions paying low fees can get stuck in miners’ mempools. This leaves the transaction (and the bitcoins involved) in limbo. It typically takes up to several days before miners drop these transactions from their mempools, and users can try again. This sort of unreliability was cause for many complaints last week, and even significant negative media coverage.
That’s where replace-by-fee comes in. With replace-by-fee, the “stuck” transaction can be replaced immediately by a conflicting transaction including more fees, getting the bitcoins un-stuck whenever the user wants them. Replace-by-fee could solve one of the main problems of Bitcoin blocks filling up right now.
And while another trick – Child Pays For Parent – could solve similar problems by “linking” newer transactions to unconfirmed transactions, replace-by-fee does it more efficiently and therefore cheaper. Child Pays For Parent is also not included in Bitcoin Core yet, nor in Bitcoin Classic. And while hard to know for sure, most miners are almost certainly not applying it either.
Fee Market
Overlapping with the previous argument, replace-by-fee could be useful to establish a competitive fee market.
As the block reward diminishes over time to eventually reach zero, miners will need to earn an income through fees in some form. If they don’t, they have no incentive to secure the network. (Or the Bitcoin protocol will require some kind of radical redesign.)
This could be realized through an auction-style fee market, where users bid for the scarce space in blocks. But that presents a new problem: if it’s not really clear to users how much fee to include, they could easily pay too much. (Or too little, as shown above.)
This problem could be solved with replace-by-fee, combined with wallet software that keeps track of network activity to calculate optimal fees. This combination would allow users to spend the minimum possible fee per transaction, and automatically re-send the transactions with an increased fee when needed. This could smooth the transaction process, and improve the user experience.
That said, not everyone supports the establishment of these types of fee markets, or not yet. As such, not everyone agrees improving such markets should be considered a benefit yet. But discussing the desirability of these fee markets is beyond the scope of this article.
Added Efficiency
Next, replace-by-fee can increase efficiency on Bitcoin network.
Replace-by-fee effectively allows users to combine several transactions into one. For instance, if a user sends a payment to one merchant, and wants to pay another merchant shortly after, he can replace the original transaction to create a single transaction that pays both. The single transaction would require less block space, and the sender can pay a lower total fee.
A similar trick could be useful if the sender wants to increase the size of the original transaction, for instance because he decides to buy an extra product from the same merchant shortly after his first purchase.
Additionally, replace-by-fee could allow for the implementation of even more advanced optimization schemes and certainsmart contract solutions.
And of course, all of this could be fully automated by wallet software.
‘First-Seen-Safe Replace-by-Fee’
Then, the case against replace-by-fee doesn’t always hold up to the same extent in the first place.
A variation where the argument against replace-by-fee hardly holds up at all, is first-seen-safe replace-by-fee.
First-seen-safe replace-by-fee allows transactions to be replaced only if they send at least the same amount of bitcoins to the same outputs. As such, the person on the receiving end of the transaction is guaranteed his bitcoins or more – unless rejected for unrelated reasons.
However, the argument for added efficiency does not always hold up for first-seen-safe replace-by-fee, since existing transactions cannot be extended.
And even with first-seen-safe replace-by-fee, there are some risks where unconfirmed opt-in replace-by-fee transactions rely on other unconfirmed opt-in replace-by-fee transactions. But any attacker willing to put in this much effort to double-spend a transaction probably has easier options available. (Additionally, wallet software could potentially warn users when such transactions are incoming.)
‘Opt-in Replace-by-Fee’
Bitcoin Core 0.12.0 included a variation of replace-by-fee called opt-in replace-by-fee.
Opt-in replace-by-fee allows transactions to be replaced only if they are flagged as such by the sender. And since this flag should be visible to the receiving end of the transaction as well, the receiver can choose whether he wants to accept the transaction while still unconfirmed.
If the receiver does not want to accept the unconfirmed transaction, he can request a new transaction to overwrite the old one, but without replace-by-fee enabled. Or he can wait for a confirmation.
Bitcoin software will need to adapt to actually warn the user of an opt-in replace-by-fee transaction for this argument to hold up, of course. Not all wallets do this yet. (These wallets typically don’t warn users about any double-spends at all.)
Though, for companies that rely on unconfirmed transactions, the change should be trivial. BitPay CEO Stephen Pair, for one, endorsed opt-in replace-by-fee.
And it should be noted that the risks where unconfirmed transactions rely on other unconfirmed transactions apply to the opt-in variation as well – as does the potential solution.
‘Full’ Replace-by-Fee
Yet some would prefer adoption of “full” replace-by-fee: replace-by-fee without restrictions, as described at the beginning of this article.
Full replace-by-fee offers one particular benefit over the other variants: it could prevent what Bitcoin Core developer Peter Todd has described as a type of ‘Sybil attack‘ on the Bitcoin network.
As mentioned, unconfirmed transactions are currently unsafe – with or without replace-by-fee. To mitigate the risks involved, companies can connect to the Bitcoin network through nodes all across the world; a method employed already. This allows them to monitor for conflicting transactions anywhere on the network.
But this type of monitoring could introduce two problems. First, the infrastructure required to pull this off provides companies with data suggesting where transactions originated. And this data could also help de-anonymize Bitcoin users.
Second, this type of monitoring presents a load on Bitcoin’s infrastructure. Requesting transaction data requires bandwidth and connection slots from nodes; two scarce network resources. And because this type of analysis occupies a fixed share of these resources, only so many companies could do so before all nodes are maxed out. In a worst-case scenario, Todd warns, this could disrupt or even collapse the network.
Full replace-by-fee renders this type of monitoring almost completely moot. If transactions are trivially replaced, there is no point in monitoring the network for double-spends in the first place.
Replace-by-Fee Is No Consensus Rule
Lastly, it should be emphasized that replace-by-fee is not a consensus rule; none of the variants reallyrequire consensus on the Bitcoin network.
Wallet software allows users to double-spend transactions – or not. Nodes on the network pick which transactions to forward, but a tiny minority can enable any type of replace-by-fee policy available.
It’s miners that ultimately decide which transactions they include in blocks. They determine whether any replace-by-fee policies are in use.
Thanks for initial proofreading and added suggestions go out to Peter Todd and Elliot Olds.
The post The Case for Replace-By-Fee (And the Case Against) appeared first on Bitcoin Magazine.
