We usually think of a denial-of-service attack as something directed at a server. An attacker sends traffic toward a target until it can no longer cope. But a malicious server can reverse that direction. Instead of being the target, it can use the millions of clients connected to it to carry out the attack.

Imagine an application installed on millions of devices. A malicious server could instruct all of those devices to contact the same external system at once, effectively turning the application’s own user base into a distributed denial-of-service attack.

flowchart LR
    S[Malicious server]
    S --> A[Client A]
    S --> B[Client B]
    S --> C[Client C]
    A --> T[Same external system]
    B --> T
    C --> T

The same idea can be used for something other than flooding a remote server. It can also turn the client base into a distributed brute-force machine.

This is especially relevant to peer-to-peer systems that use a central server as a relay. The server is deliberately not trusted with the users’ data—a man in the middle by design—and end-to-end encryption prevents it from reading what passes through it. Some secrets may exist only on individual client devices and never reach the server at all. But that does not prevent a malicious server from sending inputs to those devices.

Suppose the server wants to guess a secret held somewhere in the client network. It does not know which device holds that secret, so it cannot target a particular client directly. Instead, it sends the same candidate value to millions of clients and lets each one test it against its own local data. Most reject it, but if one happens to hold a matching secret, the guess succeeds.

This is a form of horizontal spray attack: rather than repeatedly attacking one target, the same candidate is tried across a large population of targets.

sequenceDiagram
    participant Server as Malicious server
    participant A as Client A
    participant B as Client B
    participant C as Client C
    Server->>A: Same candidate value
    Server->>B: Same candidate value
    Server->>C: Same candidate value
    Note over A,C: Each tests against its local secret
    B-->>Server: Match

From the client’s point of view, nothing necessarily looks suspicious: the request came from the normal server, through the normal connection, and follows the normal protocol. The client cannot simply stop trusting its server, but giving that server unlimited authority to make millions of devices perform sensitive or expensive operations creates an obvious risk if it is malicious. Capital Hold addresses that problem: before asking a client to perform certain operations, the server must temporarily commit capital that it cannot immediately recover.

Capital Hold

Before asking a client to perform a protected operation, the server must place money into escrow. The client can verify the collateral independently, so the server’s instruction alone is not enough. The escrow has to exist outside the server’s control: a malicious server cannot simply be trusted to keep its own record of the funds.

A cryptocurrency smart contract provides one way to do this. The server deposits cryptocurrency into the contract, and the client checks that the required collateral is there. The server cannot release the money by itself. The client confirms that the operation completed successfully, allowing the funds to be released back to the server. If the client does not confirm—because the operation failed, appears abusive, or for any other reason—the money remains locked for a much longer period, perhaps days or weeks. After that timeout, the contract automatically returns it to the server.

The implementation could use two signatures, a 2-of-2 escrow, or another cryptographic mechanism. The essential rule is that the server cannot unilaterally release its own collateral.

Making abuse exponentially expensive

The collateral required for each operation does not have to remain fixed. It can grow as more of the server’s money is already locked. For example, an exponential formula could require only a modest hold when little money is locked, while raising the requirement as failed or unconfirmed operations accumulate. This creates a feedback loop: an attack locks capital, the growing locked balance raises the collateral required for further requests, and continuing the attack locks still more capital.

flowchart TD
    A[Server locks collateral] --> B[Client verifies the contract]
    B --> C{Enough on hold?}
    C -->|No| D[Client refuses]
    C -->|Yes| E[Client runs the operation]
    E --> F{Client confirms success?}
    F -->|Yes| G[Both authorize release]
    G --> H[Funds released]
    F -->|No| I[Funds stay locked]
    I --> J[Next required hold grows]
    J --> A

The clients do not need to coordinate with one another. Each can independently read the same smart contract and apply the same rules, allowing millions of devices to impose a common limit on their server without communicating directly.

Capital Hold is a liquidity constraint rather than a penalty. At sufficient scale, a malicious server would need substantial capital—or potentially have to borrow it—simply to keep the attack running.