How Stealth Defeats Precomputed Spam Attacks
February 27, 2024
Stealth’s anti-spam design makes it robust against attacks like one that debilitated the Nano cryptocurrency this week. About one million transactions were simultaneously submitted to the Nano network, causing confusion among validator nodes. Such an attack is not possible against Stealth because it has a dependable network clock, timestamp validation, and transaction expiration. To similarly attack the Stealth network, an attacker would need access to over 80,000 CPU cores, each with exclusive access to its own RAM. To inconvenience Stealth users for more than about 1 minute, the attacker would have to continuously run all 80,000+ cores at full capacity. Once the attacker ran out of monetary resources, Stealth users could enjoy restored performance within two minutes.
— — — — — — —
A recent attack on the Nano cryptocurrency ($XNO) network caused confirmation times to jump to about 5 minutes on average, with some transactions taking hours. Although beating Bitcoin’s current average confirmation by a factor of over 1000, 5 minutes represents an extreme degradation of the Nano network, which usually confirms transactions in a fraction of a second.
Preliminary and unofficial analysis by Patrick Luberus shows that an attacker dumped about 1 million precomputed transactions on the Nano network. While this number of transactions could normally be processed efficiently if the transactions were distributed in time, the deluge and lack of ordering led to desynchronization among the Voting Representatives that approve transactions on the Nano network. This confusion significantly reduced the rate of transaction confirmation.
Desynchronization arose because the Nano protocol currently has no robust way to prioritize transactions for voting in this situation. For example, Representative A might broadcast a vote for transaction 1 while Representative B might broadcast a vote for transaction 500,000, and so on. The small number of Voting Representatives compared to the large number of transactions assures voting desynchronization because it is highly unlikely that the representatives will collectively vote on the same transactions at the same time.
This type of attack relies on the ability to precompute transactions. Pre-computation is made possible by several aspects of Nano’s design, the most important of which are related to time. First, the Nano network has no dependable timekeeping mechanism (clock). Second, Nano’s validation protocol ignores timestamps because timestamps are easily forged when no validation mechanism for the timestamps exists. Thus, an attacker can spend weeks using distributed computing resources (like a botnet) to precompute transactions. And even if nodes dropped old transactions (voluntarily, or as part of the protocol), the timestamps could simply be post-dated and the transactions dumped on the network at the right moment.
Stealth, on the other hand, has a robust network clock. Each block in the Stealth blockchain represents a tick of this clock, and each has a timestamp. Blocks are scheduled to be five seconds apart, meaning each tick of the Stealth network clock is five seconds. While this seems similar to other scheduled block production schemes, it is in fact opposite. Other schemes emit blocks according to a time-averaged network clock. With Stealth, the blocks themselves make the clock ticks. This type of clock in distributed systems is similar to a Lamport clock, but has an advantage over Lamport clocks in that Stealth network events are regularly spaced, as well as timestamped under the constraints of focal point game theory.
Feeless transactions in Stealth carry a timestamp that takes the form of a pointer to a prior block. This pointer is both a block number and, implicitly, its un-forgeable block hash. The block hash is unforgeable because the block must exist before its hash can exist. Validation of the feework (the proof-of-work submitted in lieu of a monetary fee) also requires validation of the timestamp by virtue of validating the block hash. In short, these layers of validation give an earliest time a transaction could have existed. Because this time is dependable, transactions can be expired from the network as part of consensus. In other words, all nodes in the Stealth network will agree on which transactions are invalidated because they have expired.
All valid Stealth transactions have an expiration of two minutes from the earliest moment it could have existed. Given block intervals of five seconds, and average target transaction times of 2.5 seconds, two minutes is more than enough time to discard expired transactions. Additionally, expiration is of minimal inconvenience to users. First, expirations are very rare and are only expected when the network is undergoing (an exceedingly expensive) attack. Second, the fact that expirations are part of consensus means users can simply re-create an expired transaction after two minutes. This certainty removes guesswork that plague other networks like Bitcoin and Ethereum. In these networks, users can stay in limbo for days waiting on a transaction to either confirm or be cleared from the waitlist (termed the “mempool”).
Previously, I estimated that a successful and prolonged spam attack on Stealth would require millions of dollars of hardware, and hundreds of thousands of dollars per day of electricity costs. These high costs come from the fact that un-verified Stealth transactions expire after only two minutes. Expiration renders pre-computation impossible, and necessitates continuous heavy investment in computing resources. Therefore, spam attacks powerful enough to inconvenience Stealth users are prohibitively expensive.
Fast. Secure. Reliable.
Get the Stealthsend Desktop App
