I'm going to assume that during the days where Ripple was irrationally hated by some sub-population, a la the ripplescam.com site which used to be the first result on Google for "ripple coin" until Ripple set the decentralization plan in motion, that it was mercilessly DoS and DDoS attacked.

How were/are the servers protected?

  • 1
    Companies generally discuss their internal security-related network operations. I don't think that RippleLabs is different. And now for the obligatory disclaimer: I am speaking in my personal capacity, not my capacity as a RippleLabs employee. Apr 10, 2014 at 22:45
  • Of course it is - see github.com/ripple - but what does that have to do with protecting against (D)DoS attacks? Apr 11, 2014 at 7:24
  • 1
    No, that's not what I said. The servers take steps to protect themselves, to the extent possible, when they detect that they are under load (e.g. by returning "too busy" errors for expensive operations or penalizing users who impose heavy load) but that's only a partial mitigation against a DoS attack, whose defining characteristic is an overwhelming number of connection requests, each requiring the server to do a lot of work. Apr 11, 2014 at 19:58
  • 1
    Again, that's not what I said. Ultimately, when the server is being attacked by being forced to consume resources and do a lot of work, it's response is to protect itself by penalizing users placing a lot of load and limiting the amount of voluntary work it will do, focusing instead of the work that is mandatory (e.g. processing transactions and reaching consensus). Sometimes this will mean that legitimate users will be denied service - that's what a (D)DoS is all about! If you know of a magical way to distinguish good users from bad then I'm all ears. Apr 11, 2014 at 20:14
  • it's not out, but it's not really practical either; in the era of botnets, blacklisting a single IP or 20 isn't likely to help significantly. Apr 11, 2014 at 21:33

2 Answers 2


OK, since the comments section is starting to get unwieldy, I'll type a longer and slightly more elaborate answer, that incorporates some parts from the answer by @VinnieFalco.

According to Wikipedia, a DoS attack is defined as: "an attempt to make a machine or network resource unavailable to its intended users" and it commonly involves "saturating the target machine with external communications requests, so much so that it cannot respond to legitimate traffic, or responds so slowly as to be rendered essentially unavailable"

We all agree that a system that is connected to the Internet and is offering a service at some port cannot just magically prevent bad people from connecting to it, nor can it choose to accept only "good" traffic while avoiding receiving "bad" traffic.

There many "types" of DoS attacks, but they all boil down to one thing: they seek to consume resources:

As you know, resources come in many forms; sometimes attacks will consume bandwidth, other times they will consume RAM, disk space, IOPS, file descriptors, license slots/seats, or just about any finite resource that your service requires.

Fundamentally, you have two options: either increase available resources above the level of the attack, or ride it out.

Sometimes you can do a little better: you can attenuate an attack that seeks to consume bandwidth by using a content-delivery network. You can go from rotating hard drives to flash-based storage, and even to RAM based storage if the attack causes I/O performance to drop. You can limit the use of commands that require resource under attack.

Sometimes you can do better still: you can detect that the attack traffic comes only from a subset of hosts and filtering those data streams off at an upstream provider. If I/O is a bottleneck, you can attempt to rearchitect code to reduce the amount of I/O necessary. If commands are computationally expensive, you can attempt to optimize them or even reimplement them in a more efficient manner.

But, ultimately, all you can really do is blunt the force of a DoS attack. Generally speaking, you cannot prevent a DoS, and if it hits, you usually end up having to buckle down and waiting for it to pass.

So what about the Ripple servers?

As far as increasing the available resources, obviously that's outside the purview of the code: it can't magically provision more resources. That's the job of server operators who will typically ensure that their servers have sufficient excess capacity to provide servers even when demand for service spikes. So this isn't anything the code can do about something about.

What the servers can do something about, however, is to attempt to detect when they are under heavy load or attack and respond to that. In a sense, both those scenarios play out the same:

The servers will penalize connections which are forcing the server to do more work per unit of time than the server considers reasonable. Typically the penalty is to inform the user that the server is too busy and to ignore the command and to disconnect him if he persists in issuing commands at an unacceptably high rate.

Of course, the server has no real way to distinguish with perfect accuracy whether a user is abusive or not because it doesn't have a crystal ball. All it knows is the commands that it receives from a source and the rate at which the those commands are being sent and it bases its decision on that. So while this countermeasure will affect users who are, indeed, abusive, it can also affect legitimate users.

The server can also track load across all its connections and can decide to make some commands (which it knows are very expensive but not strictly necessary) temporarily unavailable, as load begins to climb. In that way, the server can conserve resources to use in processing the commands which are necessary.

Of course, this approach is more blunt and will affect legitimate users, as the server may refuse to execute an expensive command even from a legitimate user who has not issued any other expensive commands nor caused undue load.

On top of that, there's what Vinnie Falco mentioned: the servers seek to protect themselves and the network from abuse by:

  1. Imposing (miniscule and neglible) transaction fees that are payable in XRP and which scale dynamically in response to various factors, including network load; and
  2. Imposing network-wide 'account' and 'action' reserves.

This means that someone seeking to attack the network in certain ways must, in essence, pay for the "privilege" of doing so and they harder they attack, they more they must pay.

Why is this helpful? Generally those who are orchestrating a (D)DoS attack don't really have to pay and their costs are minimal, making the attack not only cheap to launch but cheap to maintain as well. This is a huge advantage

By imposing fees, which, for regular users are negligible, Ripple servers and the network take that advantage away: they "prevent" (D)DoS attempts because the cost of launching and sustaining an attack against Ripple quickly adds up.

There are a few other mechanisms which Ripple servers implement to protect against and mitigate the effects of (D)DoS attack. Combined, all these things work pretty well, but the bottom line is that we have come full circle to what I said earlier:

A system that is connected to the Internet and is offering a service cannot just magically prevent bad people from connecting to it, nor can it choose to accept only "good" traffic while avoiding receiving "bad" traffic.

One other thing I didn't touch upon: Optimizing the Ripple server code to improve performance. This is something that we at Ripple Labs spend a lot of time on and we still have things we want to do and ideas we want to implement. We also hope that the vibrant community of talented open-source developers will take a look and contribute their many great ideas as well.


All decentralized systems like Ripple that expose shared resources suffer from the problem of transaction spam. Bitcoin solves the problem by allowing a fee for each transaction, and imposing a hard limit on the amount of storage each block in the blockchain may take up.

In Ripple this problem is handled similarly. There's a base "reference fee" paid in XRP (the cryptocurrency built-in to the Ripple network) that sets the cost for transactions. XRP used to pay fees is literally destroyed - no one gets the money. It is there to prevent the monopolization of resources. Servers can vote to increase or decrease the fee. When the network is under load, the fee is dynamically adjusted upwards. This raises the cost for spamming the network above the value of the spam thus thwarting the attack.

  • 3
    @Gracchus An attack on transaction clearing using a large number of transactions will raise the transaction fee. Other kinds of attacks are handled differently, but they can't (at least not easily) affect the stability of the network, more the availability of service to particular endpoints (by attacking the servers that serve those endpoints). Apr 11, 2014 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.