Transaction Selection Policy and Spam Defense
This past weekend, starting 13 January 2018 and lasting a couple days, there was a large surge of transactions on the Bitcoin Cash network . 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 . 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.
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. 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.
15 of 15 reviewers say it's worth paying for
0 of 15 reviewers say it's not worth paying for