On Blockchain Spam

The blockchain spam debate is rearing up again with similar arguments and divisions. To come to some clarity on the subject it is first important to understand that participants are not even talking about the same thing that both call “spam”. The word spam is being used in two contexts, and for lack of a better description let’s call these contexts “humanist” and “machinist”.

In the humanist approach, a person looks at a transaction within the wider ecosystem and concludes that it is spam because it was created in attempt to stress or break the network, because it encourages incorrect blockchain use, or because its ultimate value does not justify the blockchain space consumed forever. This philosophy has strong historical precedent, enshrined in the US Supreme Court Justice Stewart’s famous “I know it when I see it” comment about pornography.

The drawbacks of the humanist approach are well known. Humans have different opinions, and opinions differ widely on details such as whether betting applications like Satoshi Dice is spam, what kinds of data are and aren’t spam, and how much data should be allowed. To employ “reducto ad absurdum”, from my perspective ALL transactions that don’t involve me are spam (after all, I don’t care about them), and this a major reason behind blockchain research into universal dynamic accumulators. Perhaps most importantly, the specter of an application’s transactions being classified as spam in the future is a serious deterrent to application developers, especially with so many blockchain choices. However, the advantages are also clear — a large blockchain exerts a small but proportional and pervasive negative adoption pressure since node and network requirements increase and node sync is slower.

In the machinist approach, spam can only be defined by an algorithmically determinable property. If you cannot write a program that outputs whether a transaction has property A, you are not allowed to use A in the definition of spam. This philosophy emerged for several reasons:

1. Algorithms are the only known precise way to talk about processes, and we ultimately need to encode our decision into bitcoind software.
2. A universally applied algorithm is arguably “fair”, or at a minimum not surprising, so potential blockchain apps will not be discouraged.
3. Spam can be hidden, resulting in an iterative cycle between the creators and detectors resulting in increasingly complex algorithms that ultimately will never fully solve the problem.

The problem with the machinist approach should be obvious: some transactions that we humans “know” to be spam will be allowed.

Spam As Defined by Transaction Fees

The simplest “machinist” definition of spam is if it does not meet the network transaction fee. This definition is beautifully complete because paying a fee both proves that the transaction has some value to the originator and funds the network.

However, this conflicts with the large block philosophy of committing all transactions, and the desire for low fees, and ignores sort term value “inversions” like “its valuable to me to crash your network”.

Quasi-Consensus Network Fee Policy Rules

Modifying this simple rule with a policy of artificially delaying transaction commitment based on fee (even though blocks aren’t full, a fee of X gets committed no sooner than Y minutes), or based on bitcoin-days-destroyed are ideas that I think should be explored. But when experimenting with fee policy it is critically important to disallow double spending by maintaining first-seen-safe rules even for transactions that as a miner you will not commit to the blockchain (or will delay committing).

Note that by doing so, fee policy is moved out of the set of “quasi-consensus” network rules. “Quasi-consensus” network rules are the set of rules that won’t cause a hard fork if broken, but will cause other negative effects such as undermining the reliability of 0-conf transactions.

Moving fee policy out of quasi-consensus in the manner described above would allow every miner to experiment with their own fee policy without affecting 0-conf reliability. As an end user, your transaction’s likelihood to get committed would be proportional to the % of hash power that sees your transaction as not spam at any particular time. So if you want fast confirmation, make your transaction appeal to all miners. This seems like an excellent solution as it follows distributed, permissionless blockchain philosophy.

However, these ideas require that miners act altruistically in the short term since they must not commit some fee paying transactions, holding them in expensive RAM. Yet, its is arguable that a similar process happens whenever any product is priced above its “short-term” cost to produce. Companies are smart enough to price goods based on the total cost of operation, and to scale back factory operations when demand for a product is not meeting TCO.

The blockchain has been compared to the “tragedy of the commons”, but this analogy is incorrect. It is better seen as a walled garden with miners both growing food and controlling access. If a miner lets pigs (spam) into the garden they damage all the plants (raise the price of blockchain maintenance) including those of the admitting miner. Therefore, unlike in the tragedy of the commons, each miner has an incentive to keep the pigs out.