Another good article by Renaud related to spam and BIP-110.
Some commentary on the spam subject since he raised the topic. As I see it, it is certainly a fact that, to date, spam has essentially always gotten through. Very little has been stopped it or slowed it, and, for the most part, the premium paid for the spam has been quite low (if any). These facts have driven many, maybe even most, to conclude that the fight against spam is futile. There are some bad actors that want spam, but those are fringe folks (although loud), I believe most people, especially those that are more technical, hate it, but they are tired of the topic and feel it has taken too much energy already, so they want to focus on other things. I get that. Their hope is that eventually it will diminish because monetary transactions will be at a premium and this will eventually squish it. They might be right.
However, as I see it, the historical case of spam not being slowed does little to prove that it cannot be done. Why? The reason is that block template creation has been highly centralized during the past decade. When 70% - 90% of all blocks are produced by just a handful of entities, their actions or policies dictate the result. If they all allow spam, it will get through without friction. If a material chunk of them don't allow it, then it will face friction, and if the spam has a time critical component, it will face considerable friction and get very expensive.
As we sit here today, all the big template creators do largely let spam through. The obvious retort to this is "But Bob, the pools are going to create the blocks with the highest block reward whether they have spam or not. This makes the pool the most money and makes the participants the most money." My response is, not necessarily. A pool maximizes revenue primarily by maximizing its number of participants/hash rate and winning more blocks, variance in the block reward makes little difference to the pool. In other words, if Pool A has 10% of global hash rate and produces an average block reward of X, and Pool B has 20% of global hash rate and produces an average block reward of 0.99X, Pool B makes considerably more revenue and profit than Pool A. Pool B has little incremental overhead compared to Pool A. This means Pool B could pay its participants at an equal or greater rate (likely in the form of lower fees) even though its blocks have slightly lower revenue. In other words, there is a reasonable path where Pool B and its participants do better producing blocks with lower block rewards.
As we have seen at Ocean, there is significant and growing demand from people and entities who wish to create their own templates. Almost all Ocean blocks are created by its participants (via DATUM) not by Ocean. These blocks typically have much lower spam content than the average network block and indicate that there is at least a portion of network participants that value low-spam blocks. While Ocean represents 2-3% of all blocks, it is still not large enough to present material friction to spam transactions. That said, Ocean is growing rapidly and this could change in the relative near term. Additionally, there are still efforts to bring Stratum V2 (SV2) to a wider audience and maybe more pools and solo miners using DATUM.
It is my belief that over the next few years, all large pools will offer their participants an option to use either DATUM or SV2 to create their own templates, and I believe the uptake from participants will be high. Ocean already has about 2000 independent template creators, and by the end of the decade the whole network will add an order of magnitude more. It is my belief that it is only when we reach this point that the first valid data set around spam will be available. How many miners want to create blocks with it? How many want to create blocks limiting it? Are there enough blocks with limits to create material friction? Does this friction lift overall fees? We will find out then. Until we have answers to these questions with broader template creation across the ecosystem, the jury is still out on all spam related topics.
The key before then is to make sure we keep (and expand) the tools in place to allow template creators the ability to make their desired blocks. My advice, and my request, to Bitcoin Core, Knots,
@ProductionReady
and anyone else working on a Bitcoin client is to make sure that template creation has the greatest flexibility possible as it relates to transaction selection. This gives us the best chance to limit spam, and at a minimum, we ultimately will get a valid data set upon which to base our decisions.
Note: I purposely have avoided talking about BIP-110, V30, etc. here. Those topics have too much emotion around them and neither are relevant to the long term issue anyway.