Just days after the Bitcoin network processed a record 309MB transaction block, the record was broken by another—369MB, also by TAAL. The two events were unplanned, but not entirely a coincidence, so here’s some more detail on what happened and what it means.
At issue is whether anyone broadcasting transactions to the network in large volumes (and without negotiating any prior deal to do so with a processor) can ensure those transactions get confirmed. So far, professional processing operations like TAAL have urged any large-volume users to formalize the arrangement in advance.
While it’s not a formal rule of the Bitcoin network to make such a deal, Bitcoin’s economic incentives are creating a standard professional etiquette that nudges them in that direction. Or in other words, transactions will likely get processed but there’s no guarantees as to when. If large-volume transactors wish to serve their customers adequately, they’re better off making a processing deal.
Blocks and economic incentives
The new record block was processed on May 16 at block height #635141. It contained 1,324,314 mostly small transactions and earned the processor a total fee of 0.94044726 BSV (on top of the 6.25 BSV block subsidy).
Notably, the fee rewards for both blocks wasn’t high. These events help demonstrate the relationships between the default rules of the Bitcoin SV Node software, custom settings available to transaction processors, and the various incentives that find the balance.
Incentives are not formalized, but generally follow basic economic principles: transactors want their transactions processed and their customers expect this; processors need to make money from their investments or they won’t continue; professional reputations and risk-minimization matter to all participants. Bitcoin was always designed to function this way.
‘Stress test’ transactions
The large buildup in Bitcoin’s mempool of unconfirmed transactions is believed to be the result of an unofficial network “stress test”, from a chat bot using Bitcoin service RateSV’s “MetaSV” API. On May 16th, RateSV posted notice of the incoming transaction load on social media:
Here are 100000 txns ，come on and take it🤣
COME ON TAAL！ pic.twitter.com/KJDJvsvM33
— Rate-SV (@RateSV1) May 14, 2020
TAAL again suggested the transactions’ sender and others with similar plans contact them and join the “mining API” (MAPI) plan, which it’s currently testing.
The Bitcoin SV Node team detailed the incident in a blog post, without referring to RateSV by name. A total of over 2 million transactions were broadcast to the Bitcoin BSV network in a short time—most with a fee rate of just over 0.25 sats/byte (satoshis per byte).
0.25 sats/byte is BSV’s default minimum “relay fee”, meaning it’s enough to broadcast the transactions to the network. However the default minimum “transaction acceptance fee” for processors (which TAAL observes) is 0.5 sats/byte. Processors may set this fee lower—something they’d typically do for pre-negotiated volumes.
The purpose of these deals is so processors can ensure they have the capacity to handle volumes and guarantee service levels to the transactors. Without knowing about large volumes in advance, they might suddenly be hit with large mempool backlogs. If the transactions have unusually low fees, like the stress test ones did, future processors might assign them low priority and they’d sit in the queue for a long time.
The Bitcoin SV Node team wrote that Bitcoin SV has several built-in mechanisms to handle such events. The software “performed well within operating limits,” they said, and the network didn’t slow even though the mempool hit its current-default 1GB limit a few times.
The load from this event was a fraction of what Bitcoin SV is subjected to daily on the BSV Scaling Test Network so this is unsurprising to us.
There is no risk that continual mempool build-up would cause a bottleneck “because the Bitcoin SV Node software handles this scenario gracefully,” they added. However they stressed two important points: firstly, once the software hits its memory limit for transactions, it will begin “evicting” the lowest-fee transactions, meaning they won’t ever be processed. Secondly, this means that even if processors one day engaged in a race to the bottom by offering lower and lower fees (say, below the default 0.5 sats/byte) the lower-fee transactions may still never get seen. High-volume transactors would thus be putting their users at risk of double-spend attacks as a result.
The mempool typically keeps transactions in memory for a maximum two weeks (though it can be shorter). Though no funds would be lost (notwithstanding an actual double-spend attack), a sender whose transaction got left in the mempool due to too-low fees might have to wait a while before their funds were returned to them.
“If you are a transaction sender, it is in your interests to discover what fee is required to get your transaction processed using services like Merchant API. Otherwise, users risk having their transactions stuck in a mempool for days or weeks, and unable to access those funds during that time without using a CPFP payment to nudge it over the line.”
Processors generally set their mempool limits to 8GB, and this limit can be raised in real time if the need arises.
RateSV had its own take on the matter, suggesting transaction processors had an obligation to handle any kind of transaction block, to maintain the integrity of the network:
As the ecosystem professionalizes further, I’d expect miners to take a harder stance along the lines of “if you’re maintaining a mempool, you need to make sure you can handle it because we can and it isn’t our job to look after you”.😎 https://t.co/dk24J8ezAH
— Rate-SV (@RateSV1) May 15, 2020
In its post, Bitcoin SV Node responded indirectly that the message was more like “if you’re maintaining a mempool, you need to make sure you can handle it because we can and it isn’t our job to look after you.”
The incentivization dance
This is where the interplay between various incentives, timing and participants are relevant. TAAL said processing the first record block was a good demonstration of Bitcoin’s scaling capacity. We can assume the same went for the second block. At these early stages, TAAL (and other processors) have incentives to keep the network running smoothly, and processing large blocks with ease demonstrates a company’s own handling capacity. Therefore, while it’s not directly profitable to confirm a low-fee large block, it’s an investment in the longer-term stability of the network.
The stress test also had more chance to be noticed in these early days of Bitcoin, coming as it did right after the Bitcoin Core (BTC) block subsidy halving, which saw more processors switch to BSV (again, guided by profit motive). The differences in BTC/BSV’s default relay and acceptance fees, and how it affected larger/lower-fee blocks also prompted the surrounding discussion.
As Bitcoin usage and adoption increase, with hundreds (or millions) of high-volume transactors, that incentive to confirm blocks merely to show ability is reduced, as enough users already trust the network. Processors would then pay more attention to the profit motive and would be more likely to ignore low-fee transactions.
The Bitcoin SV Node team said these factors would all play a part in “adjusting user behavior” and that large-volume users would discover new ways of interacting with the network. Stress tests and mistakes are fine for now, and it’s good to see Bitcoin works as intended. In the future, however, most will be too preoccupied with the serious business of serving customers and making money.
New to blockchain? Check out CoinGeek’s Blockchain for Beginners section, the ultimate resource guide to learn more about blockchain technology.
