The Permissionless Catch-22

Potential Attack Target

Suppose some genre of content is under attack by powerful adversaries. Lets take political satire as a thought experiment in which powerful politicians are attacking sites and Web archives hosting it by sending bogus DMCA takedowns, suing for defamation, buying up their hosting platforms, getting their flying monkeys to flood them with spam, and so on. Below the fold I discuss the problem facing the defense.

White Hats

You and a few friends get together to fight back. You think about setting up the not-for-profit LOOPS (Library Of Offensive Political Satire) to collect and preserve it, but quickly realize it would be immediately sued into bankruptcy.

Inspired by BitTorrent, the alternative you see is to write and distribute the software for a permissionless, peer-to-peer network. It would use erasure coding to ensure that each node held only a fraction of any individual satire, but each satire was held in aggregate by many nodes. That promises no central point subject to legal attack, and no node holding an identifiable part of a satire.

The graph of the security of such a system against the number of nodes will be an S-curve. With a small number of nodes it isn't secure. As the number increases, security increases slowly until a point where each of the average satire's chunks are held on at least two nodes. Then it rises rapidly until the law of diminishing returns kicks in and the curve flattens out.

Thus you need many nodes under independent control. You need to motivate many people or institutions to run a node. The lower the capital (capex) and operational (opex) costs of doing so, the more likely you are to get to the steep part of the curve in time to foil the looming attacks.

Catch-22

The security of a permissionless peer-to-peer system depends upon the cost of mounting an attack being greater than the reward for a successful attack. But making it cheaper and easier to run a node has the inescapable unintended consequence of making it cheaper and easier to mount an attack. Catch-22!

Black Hats

The white hats have to pay the capex then pay the recurring opex indefinitely. In most cases the black hats can mount a one-time attack. Because it is cheap and easy to spin up a node, the black hats can avoid paying the capex and pay the opex only one time by renting a large group of nodes from AWS.

But the black hats don't even have to do this. The white hats have built a permissionless system that, like almost all such systems, is not actually decentralized. The black hats can mount a software supply chain attack and, instead of creating new nodes, compromise the white hats' existing nodes.

This works because, as we see in almost all P2P systems, no-one is willing to pay the cost or devote the unpaid effort to doing clean-room re-implementations of the software. Especially since making nodes secure but cheap and easy to run is a difficult engineering problem. Even if there are multiple independent implementations, there are two further problems. First, it is likely that they all share common dependencies on libraries that could be targets for the attack. Second, network effects mean that one of the implementations will capture the bulk of the market.

Conclusion

The need to make running a node cheap and easy isn't just a Catch-22, it is a Catch-22 that favors the black hats.