This past weekend, starting 13 January 2018 and lasting a couple days, there was a large surge of transactions on the Bitcoin Cash network [1]. It is unclear whether this surge of transactions was a Spam attack, a “stress test”, or some other unknown use of the network.
The transactions seemed “non-organic”, and were not associated with any known legitimate use-case, which could suggest nefarious intent. The transactions strained the resources of some nodes, which brought some services down (including Yours.org). On the other hand, the transaction storm did not seem overly hostile since it did not blow up the UTXO set [2]. It is interesting to see that the transaction storm initially increased the size of the UTXO set, but as the transactions were mined the UTXO returned to the pre-storm size. It is also significant that most regular users were minimally affected by the event, with many probably unaware it was occurring.
Whether or not this transaction “dust storm” constituted an attack, it does raise some interesting issues. It is a good opportunity to consider the resilience of the Bitcoin Cash network to future attacks, some of which could be more challenging to handle. Now is a good time to ensure the network is resilient.

Economic and Technical Approaches to Spam Defense

There are two main ways of thinking about defending from attacks: technical and economic. Technical approaches are when certain technical characteristic of the attack are identified, and then are blocked. Bitcoin’s traditional “transaction priority” would be an example of a technical measure, looking at coins age and value to identify transactions that are unlikely to represent an attack, and thus safe to allow with no fee. The block-size limit is another example of a technical measure implemented initially to prevent huge-block attacks.
The problem with technical defenses is that it can be difficult to avoid also restricting legitimate activities. To prevent transaction “spam attacks”, or “dust storms” we could imagine disallowing transactions that create too many UTXOs. Or we could disallow long chains of unconfirmed transactions. The problem with these, is that there are also legitimate use-cases that may want to create transactions with these characteristics. Transaction “batching”, for example, can create transactions with many outputs. And if adoption grows rapidly, new owners of coins will need UTXOs created for them, so it is not obvious where to draw the line between attack and legitimate use.
This leaves economic defense. The idea of economic defense is not to make the attack impossible, but simply to raise its cost to many multiples the cost of the legitimate use. This gives an asymmetric advantage to legitimate users by making the attack far more costly to the attacker than the defenders. A problem of economic defenses is that they often have external costs which are difficult to capture
In the next few sections, I will consider a few different possible approaches to transaction Spam defense, and discuss how they use economic and technical approaches.

“Eat the Spam” Strategy

An approach favored by many big-blockers is what I call the “eat the Spam” strategy. Basically the idea is that if blocks are significantly larger than typical organic demand, then it will take very large volumes of Spam to fill the blocks. With even modest transaction fees, this means that the spammer will incur significant costs before filling blocks enough to displace regular transactions. Since the Spam attack costs a lot, and cost users little (if anything), this tilts the balance of power away from the attack, rendering it futile.
The problem with this approach, however, is that transaction fees for users aren’t the only cost that is incurred. The Spam can add to other costs, as it creates more data for network nodes to process, which increases their costs. It can also lead to increases to the UTXO set, which imposes future and ongoing costs, not necessarily borne by those enforcing the transaction selection policies.

“Reject the Spam” Strategy

A seemingly obvious and easy to solution is to just reject the Spam. Don’t relay it, accept it to the mempool, or mine it into blocks. Using this method, you could have a block size limit big enough to accept all legitimate transactions, but it wouldn’t need to be much larger than that.
However, this is not as easy as it sounds. Once we start thinking about how to implement this policy, we start running into problems.
A major problem, is that it is not always obvious what transactions are “legitimate”. This puts developers in a position to decide what is legitimate or not. In the past we have seen debates about what transactions should be allowed, for example whether putting arbitrary data in OP_RETURN should be allowed, or whether Satoshidice transactions are a legitimate use of block space. Some legitimate use-case may resemble Spam, for example services such as Yours.org may find it useful to generate long strings of unconfirmed transactions, which can resemble the patterns of generating Spam.

Hybrid Approaches

Historically, Bitcoin has employed hybrid strategies to limit Spam. Technical metrics such as “coin age” and amount were used to define some transactions as “high-priority”, and a portion of the block was set aside for these transactions. In the era before blocks were full, these high-priority transactions would confirm with zero-fee.
At the same time, the rest of the block had ample space to fit fee-paying transactions. This allowed legitimate users of non-high-priority transactions to get their transaction into blocks, with sufficient buffer to discourage Spam. A problem with this approach, however, is deciding how large to allow blocks to be, and we can see that the system breaks down when blocks become full, as happened on the legacy Bitcoin network.

Progressive Fee Policy

If one wanted to take this concept further, rather than two “bins”, we could extend the concept to many bins. The way this would work is that miners would apply increasingly strict rules for accepting transactions into blocks as the blocks they build get larger. For example, the first 1MB of block space could allow very low-fee, or free transactions, the next 1MB (so up to 2MB blocks) would apply stricter rules on UTXO growth and require some fees, the next 1MB would apply even stricter rules and require higher fee, an so on to very large block size. This would results in a “progressive fee” policy that increases the fee required as blocks get larger.
The advantage of this approach is that it would allow for a very large ultimate block size limit, while still limiting the ability of spammers to clog the network. It would also balance the costs that too large blocks impose on the network infrastructure, with the costs that too small blocks impose on transactors through fees. As demand for transaction inclusion rises, fees would gradually rise, without hitting a wall. As the network grows, and increased transaction fees are observed, the size of the bins could be increased.

Towards a True Market Solution

Reading through these various approaches to transaction selection policy may give you an uneasy feeling, and it should. None of the approaches are a truly elegant and satisfying solution to the problem. The problem is that the policies involve tradeoffs, and it is impossible to accurately know the appropriate tradeoffs without a true market price. It is a calculation problem, which cannot be solved with central planning.
For example, we know that a large UTXO has costs, many of which will be borne in the future. But, if Bitcoin Cash is to grow to mass global adoption, the UTXO must grow. So how much should UTXO creation be discouraged? Where is the appropriate balance?
This problem is apparent with the “Segwit discount”, which weighs the “witness” portion of Segwit transactions at ¼ the weight of the rest of the transaction, to discourage UTXO creation. Why ¼? The choice is completely arbitrary, based on little more than gut intuition.
The only way out of this puzzle is through true markets. Various ideas of how this could work have been proposed over the years, some good examples being Justus Ranvier’s long-lost Liberty.me articles [3, 4].
Let’s imagine how this could work for the UTXO set. Currently all miners must maintain a record of the UTXO to check that transactions are not double-spent. But who really benefits from the record unspent outputs? It is the “owner” of the coin, who wants to be able to eventually spend the coin, who really needs a record of the unspent output to be retained. So why not put the responsibility of storing the unspent outputs on the coin holder. This is precisely what Gavin Andresen’s recent UTXO Bit Vector proposal allows[5]. With such a scheme, we wouldn’t need to be concerned about the global size of the entire UTXO set, since each coin holder would be responsible for storing the necessary data, and providing a compact proof that the Unspent Output exists when spending their coins.
The only way to rationally allocate scarce resources is through the price mechanism of a truly free market. It may take some time to develop all of the mechanisms needed to enable markets for all the scarce resources in the Bitcoin Cash network, and some resources only start becoming scarce after the network grows larger. Bitcoin Cash is already the most free-market form of money in the world, I look forward to seeing even more market mechanisms as they are developed over time.

References

 

$9.35
$261.60

Reviews
15 of 15 reviewers say it's worth paying for

0 of 15 reviewers say it's not worth paying for
Comments
  spent 20.0¢
There is no such thing as "spam transactions". If the transaction is paid for, it is legitimate.

0.0¢
   8mo ago
2.0¢
  spent 20.0¢
Really helpful analysis, thanks.
0.0¢
   8mo ago
  earned 30.0¢
Fantastic article, Mengerian. Thanks for writing and posting here. Tipped $10.00. Also really cool to see that someone else tipped you $250!
50.0¢
   8mo ago
50.0¢ 2.0¢
  earned $1.05
I agree, there must be hybrid approaches. When a spam attack is obviously hostile, the miners should reject the transactions. Also the miners should "tax" transactions which harm the health of the system, like such which create a large UTXO set. Cloud miners which did daily payout of micro-earnings did not help anything at all (except themselves, so they should pay the tax).
Most important, however: The concept of progressive fees for the block-mb filled, is great. In combination with age of coins it can help to build a true market; if you make special things, like chaining unconfirmed transactions, you pay an extra fee or wait some blocks, and so on.
I also think it is great to have some kind of free fee market, that lets miners for example earn money by confirming confidential transactions, op_return token etc., while standard transactions are free or mostly free.

$1.25
   8mo ago
50.0¢ 75.0¢ 2.0¢
  spent 20.0¢
Thanks for the great post and all the analysis.
0.0¢
   8mo ago
2.0¢
  spent 10.0¢
We should look to abandon the use of words like "spam," spam is by definition "unsolicited".
There is no authority in Bitcoin capable of defining an unsolicited/spam transaction for the whole network. Only individual nodes miners or those receiving transactions can make a personal value judgment.
From a developers perspective, all is needed are tools to allow individual actors to project their definitions and the associated cost to what they define as an unsolicited transaction and let market forces pick the economically viable transactions.
The above solution does not fall within the responsibilities of development teams but on the shoulders of those who have to pay the cost of processing transactions or be disadvantaged by unsolicited transactions.
That said I believe free transactions will always be viable and should be made available to keep bitcoin transactions fungible (ie if you cant afford to spend multiple outputs on an address then not all bitcoins are equal in value.)
10.0¢
   8mo ago
50.0¢ 50.0¢ 10.0¢
  spent 20.0¢
You wanna know what would be hilarious?
If, instead of fees, miners required some Proof of Work for each transaction to reduce spam.
0.0¢
   8mo ago
2.0¢
  earned 15.0¢
Thanks to whoever gave me the large tip! That is very generous!
And thanks for the comments, glad people enjoyed the article!
25.0¢
   8mo ago
25.0¢