Why replace-by-fee is not a solution to full blocks

[Steve Sokolowski]

There was a long and in-depth argument recently at https://www.reddit.com/r/btc/comments/3 ... ay/cxxfps8 between Mike Hearn and Gregory Maxwell about replace-by-fee. Replace-by-fee is a system that, among other things, allows a transaction to be assigned a higher priority if the bitcoin network is congested. While I don't feel strongly enough about replace-by-fee to recommend for or against its adoption, I do want to provide several reasons why Maxwell's argument about replace-by-fee being a viable solution to congestion is flawed.

As a brief summary, Maxwell proposes that a mathematical formula can be assigned to determine what fee should be assigned to the new transactions. If the first transaction doesn't confirm quickly enough, he proposes that a higher fee can be calculated with an equation, and then if that fee isn't high enough, the same equation can be used to compute the next fee, and so on. Maxwell explains the exact formula (increasing by multiples of 1.5) and the reasons behind it in the series of posts.

Since I haven't implemented Maxwell's formula, I can't comment on whether it achieves what it sets out to achieve or not. Let's review a few reasons why I have not implemented the formula.

First, resending transactions requires a running script, which needs to have unlocked access to the private key, which is dangerous. I've stated many times that our primary methods of security are that we don't keep money around to steal by paying people out frequently, and that the decryption keys aren't stored on the server even if someone does gain access to the daemons. We currently receive money from exchanges throughout the night and then run one script to unlock the wallets once for payouts. It is not secure to either keep the wallets unlocked permanently or to keep the encryption keys on the server to poll the networks and determine if it's time to send a new transaction. Whereas before any hacker would have to remain connected for days (and be detectable) so that he sees the brief instant the payouts are executed, now all he has to do is connect at any time, copy the keys, disconnect before anyone notices, and steal money later.

Second, raising transaction fees is impossible in some scenarios. We offer free payouts when balances exceed $2, but some of our users request daily payouts of small amounts, for which they are charged fees. If they stop mining immediately after the payout, and then we raised fees, they would have negative balances. This would cause us a loss of money, and simply couldn't be done.

Finally, and most importantly, replace-by-fee is not an option for any legitimate accounting system. When there are two transactions on the network, it is possible that either transaction could be mined. Every action taken by us, from trades to exchange transfers to share submissions to payouts, is tracked with 24 decimal places of precision. We have a lot of CPU power just for this reason because Decimal arithmetic is much more costly than using Doubles. The procedure for performing actions involving money is to begin a transaction, insert the rows in the database (if failed, rollback), let the triggers update balances, see if any constraints are violated (if so, rollback), take the actual action (if it fails, rollback) and then commit. If a balance of any coin or the amount owed to any miner falls below zero, an Exception occurs and the action does not proceed.

If we didn't perform such tracking, we could end up losing huge amounts of money due to newly introduced bugs, or due to a security vulnerability that some user might have discovered where he tries to issue payouts for more than his balance owed. The tracking is also necessary so that we know that something is wrong when an action fails due to balances being mismatched with the daemons. But replace-by-fee is incompatible with accounting systems, which major corporations rely upon, because it cannot be determined with 100% accuracy how much money you are actually spending. What if the cheaper transaction is mined instead for some reason? Allowing the system to be off by a few cents is a big deal in a series of servers that mines 30,000 blocks per day, because small errors add up quickly and could cause the pool to go bankrupt in hours.

Replace-by-fee may be a good feature to have for simpler use cases like purchasing items with bitcoin in a store. Whether those use cases still exist due to the expense of fees is questionable. But Maxwell's argument that replace-by-fee is a solution to full blocks is wrong. Replace-by-fee has security problems, is incompatible with models where the customer is charged fees, and most importantly can't be used with an accounting ledger. Precise accounting ledgers are a barebones requirement for any exchange, bank, or pool. While there are other solutions for the blocksize transaction wait problem, Maxwell's argument fails because replace-by-fee is not one of them.

[Some1notu]

I know I'm preaching to the choir here but any such "idea" should be replied to by saying: Why not just increase the block size so transactions don't get clogged up in the first place? Since the transaction clog is caused by more transactions than the blocksize can handle, increase the blocksize. There is no need to find some silly workaround that further complicates matters.

This reminds me of an old joke that certainly applies:

Hey Doc! It hurts when I do this.........Doc replies: Then don't do that

[Chris Sokolowski]

The main problem I have with replace-by-fee is that it doesn't solve the original problem of congestion. If replace-by-fee is adopted but block size is not increased, then Bitcoin just becomes impractical for small transactions (as opposed to being impractical for all transactions as it is when blocks become full). I certainly won't use Bitcoin to buy a $2 cup of coffee in the morning if it means that transaction fees increase the cost by 20%.

If the block size is not increased but replace-by-fee is implemented, then I see this as strong evidence that we are moving toward the "gold/silver" standard of Bitcoin/Litecoin, where Litecoin is used for small, everyday transactions while Bitcoin is reserved for moving large amounts of money.