Manipulating difficulty to spam the UTXO set is ineffective

The growth of the UTXO set poses a challenge to the design of any cryptocurrency protocol, as it bloats the state of the clients. An attacker might want to bloat this set by flooding the network with many cheap transactions in order to artificially increase the size of the state. In this post I am not addressing these issues directly, but merely trying to argue that a mining attacker could not abuse the difficulty adjustment protocol to increase the UTXO set.

This is in response to the following attack (proposed by @ori and Elichai): create a side chain where you artificially decrease the difficulty, and then create a huge graph with many transactions for cheap.

I argue that this attack does not actually allow a < 50% attacker to spam the UTXO set, if we add a simple consensus rule (which was conceived in an entirely different context, which serves my position that it is a natural and reasonable consensus rule, and not a ad-hoc hacky solution).

The consensus rule is: For some constant maxDiff (which should be about k), reject any blocks which has two immediate parents whose blue score difference is more than maxDiff. (my “philosophical” argument for this rule is that the PHANTOM DAG should be thought of as a generalization of Nakamoto chains. In this case, it makes sense to ask what replaces the maximal block in this generalization. The most easy answer is “the tips”, but I argue that “the maximal tip, and other tips with similar blue score” is better. The reason the top block in a Nakamoto chain is interesting is because it is supposed to contain the most current data. This could not be said about a week old block, even if it is technically a tip).

Now, when calculating the UTXO set of the virtual block, it will simply not include tips with low scores, and their content will not affect the nodes UTXO set.

Coming back to the attack above. In order for an attacker to decrease difficulty they must use time stamps which go into the future. While it is true that the attacker may create many blocks this way, they must also wait for the clock to catch up with the futuristic time stamps for them to be included, and by that time the network will have created more blocks. The difficulty adjustment is designed such that at any point in time (up to a small constant) the attacker can not create a lot of blocks which will be accepted. While it is true that the attacker can create many blocks this way, at any point in times, the amount of blocks they created which will be accepted by honest nodes is proportional to their hashrate. This (along with the consensus rule described above) implies that these blocks will not affect the nodes UTXO set.

Should be noted that this approach has not proven itself in the long run. tipDiff could be seen as a very early precursor to the more mature idea of a “kosherizing block” which is presented in the pruning algorithm.