Spam Backlog and Why Miners Don't Want to Set Limits Way Beyond Actual Use

Many of us were disappointed when the most recent backlog was not eaten away by one or two blocks and about the resulting UX impact. Yet, by our own message and marketing, we kinda promised 1sat/byte and next block confirmation for transactions, but that’s just not how bitcoin works. This promise still holds true in regular conditions.

But!

It needs to be nuanced and take into account the specific details and intricacies when it comes to mining on the Bitcoin Cash network.

Why no huge blocks?

As a miner, setting your block-size limit way beyond the actual use opens up an attack vector. Certainly when there is a big disparity between miners when it comes to block-size.

To understand this attack, you must understand that validating and propagating blocks takes time. The bigger the block the longer it takes to validate and thus propagate. The longer it takes to propagate a block the bigger the chance of it being orphaned.

Let’s say there are 2 miners or pools on the Bitcoin Cash network that have their infrastructure configured to mine 32MB blocks, while everyone else has a 1-2MB limit. This while the actual use of the network consists of 200KB blocks on average. It would be pretty trivial for an attacker (competing miner) to single out those miners who mine huge blocks. Then start to feed them, and only them, a huge load of new transactions. This would cause those 2 miners to be the only ones to mine huge blocks which take a long time to validate and propagate, while the rest of the network keeps on mining 200KB blocks which propagate way faster. This causes a big orphan risk for those 2 miners. The more success in causing orphans for others the more potential profit for the attacking party. If there is one thing miners want to avoid it would be orphaned blocks since that literally means lost revenue. It would be silly to expose yourself like that.

Bigger blocks will emerge organically when actual use of the network grows. Big peaks in load do not constitute organic growth. If the load would have been sustained for hours or days, you can be sure miners would start raising their block-size soft-limit. In such a scenario there is less risk of orphans, since everyone starts mining bigger blocks to get their hands on those juicy fees (do note, right now the fees are nowhere near juicy).

The backlog caused UX issues for normal transactions. That is not okay. How can this be mitigated?

Wallets. Wallets need to be smarter when it comes to transaction fees. Setting the transaction fee to something between 1-2 sats/byte would have mitigated the impact for regular users 100% without raising the cost for a transaction by any significant amount. You can’t in good faith argue that paying 1/10th of a cent instead of 1/16th of a cent is an issue and prices people out.

To conclude, in an ideal situation of a professionalized network, the block-size soft-limit would be as close to actual use as possible. Wallets need to be smarter to get your odd transaction through during moments of load peaks. Miners and heavy users will have personal preferences about which kind of transactions to include, which forms some sort of fee market, driven by use and competition. This would thwart any sort of malicious spam attack while still allowing huge transaction peaks to be handled by the network, without an UX impact to the cash use-case.

One commitment Bitcoin Cash does make is to keep the block-size hard-limit always above actual use or abolish it all together in order to prevent the fee market from spiraling out of control, like we regularly see on BTC.

I hope this clears things up a bit.

Many thanks to checksum0 for the in-depth explanation.

comments powered by Disqus