BitFury's Smallest-First Mining Is Bad For Bitcoin

Smallest First vs. Most Needy First

The shift in BitFury's behavior comes down to a switch from "largest fees per byte first" strategy to "smallest first".

This switch makes sense only if what you care about are superficial metrics, and then, only if you have a tiny time horizon and are not concerned with the big picture.

Scheduling Theory and Bitcoin

The core of the second argument is based on a simple result from scheduling theory, which says that shortest-job-first is the optimal strategy if what you care about is to minimize completion time, that is, time from submission of a transaction to its appearance in a block.

The reasoning for this is simple: assume there are transactions A, B and C. Suppose A is 1MB large while B and C are 500KB each. Mining A first, then B and C together yields a collective wait time of 1 (for A) + 2 (for B) + 2 (for C) = 5 block-times for 3 users, or 5/3 blocks per transaction submitter. Mining B and C first, followed by A, yields a collective wait time of 1 (for B) + 1 (for C) + 2 (for A) = 4 block-times for 3 users, or 4/3. The latter is clearly shorter than the former. If we apply this logic iteratively, we'll find that it makes the most sense for the miners to prioritize small transactions first, and mine transactions in sorted order, from smallest to largest.

So Alex's logic seems, superficially, to make sense: if we are given a fixed set of transactions in a batch at the beginning of time, if the users submitting them are honest and not trying to game the system, and our goal is solely to minimize user wait time in a world where every transaction has a user waiting for it to clear and all users are equally important, then picking the small transactions first is a good strategy. That's why you see people at well-run airports, banks, and customs lines pull the people who need little time to service out of the line, and serve first. Anyone with a valid passport and simple itinerary knows the pain of getting stuck behind that guy who is missing paperwork, was born on the Marshall Islands just as it was changing hands, whose parents are Liberland natives -- he is going to take a while, and more people would feel better if he stood aside and let the line clear up. This is also why, at the Apple Store, they ask you if your transaction is short and easy, and expedite you if it is: they don't want you to get stuck behind the problem person who has a complicated transaction involving 2 returns, 3 gift cards under slightly different names, and the involvement of an Apple Genius. Shortest-Job-First is a provably optimal strategy, for serving a static batch of inflexible, unchanging requests.

But the logic fails because the premise is not correct. Smallest-first is a terrible, short-sighted strategy when applied to Bitcoin.

Bitcoin transactions are flexible. A large transaction can easily be turned into multiple small transactions, that, together, take up more space than the original transaction. Mining small transactions first provides an incentive to wallets to break up their transactions into such smaller pieces. But many small transactions that accomplish the same task as a single big transaction actually consume more space than the single big transaction. So, in aggregate, they reduce the system's economic throughput. They are a wasteful way to use our precious block space.

Bitcoin transactions are also not equally important. The main metric we have for telling apart the important transactions from worthless spam is the fee they carry: important transactions carry more in fees. Processing the transactions that are unimportant first will reduce the wait time for transactions whose users do not mind waiting, while making the people with time-limited transactions suffer longer. It's a strategy purely for optics, aiming to lower numbers of waiting transactions, not maximize the actual good that the system is doing or serve the people who have signaled their need for service.

Finally, Bitcoin users want predictability. Those people in favor of a fee market especially require predictability: if the market is being cleared in a haphazard, random order, then the wallets will have no feedback on whether their fees are high, low, or just right. Chaos isn't a good strategy when you want to develop a feedback loop.

Fundamental Problem

Overall, smallest first is a fundamentally bad idea because it breaks the connection with the fee paid and the resources consumed. Recall that the block space is the limited resource here, and the fees paid are our way of gating that access, of measuring who needs it most. Hence, the default metric to sort transactions by is satoshis per byte -- this ensures that the transactions that do the most economic good get prioritized first.

Switching to small-transactions-first enables BitFury to post this tweet and collect kudos from the community for entirely the wrong reasons.

First, the system should not be processing low importance transactions over more important ones. Maximizing economic good requires going after the most economically useful transactions first, and our only proxy for "economically most useful" is to sort by largest-fees-per-byte-first.

Second, one miner sweeping up the smallest, lower-fee transactions doesn't really do any good for the system. Someone still has to mine the larger transactions. Those outstanding large transactions still need to be cleared. A temporary, short term increase in the transaction rate for one miner doesn't achieve anything in the longer term. It's like a teenager cleaning up her desk and sorting her socks, really quickly -- it's a nice but ultimately pointless gesture, her tasks aren't done until the entire room is cleaned up, and the sum total of tasks still takes the same amount of time. She left the hard work to others.

Third, this policy provides an incentive to wallets to break up their transactions, to issue many smaller transactions in lieu of a single large one. That would lead to more wasted space overall, and a net decrease in throughput. A miner that did this in a predictable fashion would be damaging to the network.

Fourth, prioritizing small transactions can mislead or confuse the fee estimators built into wallets. I don't have the time to examine the various fee estimators today, but I believe the default fee estimator has built into it the assumption that miners will maximize their profits and perform largest-fees-per-byte-first, and uses the fee distribution in the mempool to pick its own fees. In this case, seeing high fee transactions sit around and not get mined will cause the users to actually bid even higher fees, actually leading to an added expense for users until the wallets adapt. Now, this is not the only way to estimate the fees (in fact, it is notoriously difficult to estimate the fees) . There may be fee estimators out there that instead base their decisions on the fees found in mined blocks. In that case, they will issue transactions with low fees, which will lead to stuck transactions and a bad user experience.

Finally, once the wallets adapt to smallest-first mining, their best strategy will be to attach the lowest possible fee to every transaction. The mempool then becomes a Hail Mary zone, where people toss their transactions cut up into small little chunks, and hope that the miners will sweep through their precious transfers just by sheer happenstance. The fee market will collapse, and we can no longer have a rational market, because the miners will not be behaving rationally, putting up the space in the blocks up for auction. Imagine a web search service, where you pay solely a fixed fee to place your ads, and the ads are included based on chance. This is not a winning strategy for anyone. Just ask Yahoo.

I'm Doing Work In An Irrational Order to Reduce My Workload

Alex Petrov of BitFury has also expressed concern that, when transactions sit around in the mempool and expire, they get resubmitted, causing the miners to have to re-validate them. This is tantamount to saying that, because you are overloaded by your boss asking you to do the same N things over and over again, you'll do them in an irrational order. Once again, Alex may be pointing to something that might need fixing, but the fix is almost certainly not smallest-first. Adding more resources, parallelizing validation, maintaining a 1 bit validation cache even when transactions are evicted, etc are all effective techniques for avoiding repeated work.

Are There Better Ways To Reduce The Mempool?

One simple way to reduce the mempool backlog is to make the blocks larger, either through a blocksize increase or through the more complex Segwit patch. That will reduce fees, to boot, in return for increasing the space, bandwidth and CPU consumption of Bitcoin. Given how cheap and plentiful storage and CPU are, and how much bandwidth increased just last year alone, adopting some kind of a blocksize increase is the thing to do.

Thanks, but no thanks

Overall, smallest-first is, at best, a strange strategy. It most certainly does not accomplish what we all need: more useful economic activity recorded quickly on the blockchain.

Luckily, it's also a losing strategy: at the moment, a miner mining smallest-first will earn around 5% lower in BTC terms than what it would have been had they gone for mining largest-fees-per-byte-first. Let's hope that this dampens their behavior and counteracts the damage they inflict on Bitcoin through increased delays on important transactions, perverse incentives, worse utilization of the blockchain space and potentially increased fees.

Aviv Zohar said it best when he quipped "[smallest-first] will raise the revenue of other miners and eventually push irrational ones out of the market."