Stellar uses a consensus algorithm, not a proof-of-work algorithm. The concept of mining doesn't apply.

Mining is providing proof-of-work to validate transactions. Public ledger schemes that don't use proof-of-work to validate transactions neither have nor need mining.

I don't want you to assume anything. I want you to understand the procedural controls that I know are in place that make your crazy conspiracy theory extremely implausible.

Did you take a look at some random address from the thread and see that they all did receive their XRP? Did you track the accounts and see that most of the XRP went through to aggregators?

I don't recall the details. I think we did know at the time more precisely how it was gamed. But it obviously was gamed, that's why we suspended it. The evidence is still there for anyone who wants to look at.

The problem is that I can't respond to everything at once. And you have so many objections that I need to respond to that there's really no way to get it sorted out. You're not going to believe me on any one thing because you're holding everything else against me.

Please, at least actually check the accounts on the giveaway thread. This is easy to do. You will see they did receive their XRP and it did go to a small number of aggregator accounts. The giveaway was gamed. That's a fact.

All true. That's how companies work. We're a startup. We're trying to make money and maintain competitive advantage. We don't owe anyone any explanation of anything we do, so long as it's legal.

I agree, it's a good idea to say "I don't know" if you don't know. And I will say "I don't remember" if I don't remember. Or if I think I recall something but aren't confident it's accurate, I'll say so. My best guess about the giveaway on this forum was that people were brute forcing passwords for long-dormant accounts with weak passwords. We had a similar problem with another giveaway where the brute force attempts became a DoS on the service and they had to ask us to stop the giveaway to protect their infrastructure.

I agree now that the whole giveaway idea was a mistake and we never should have done any of them. You either need to collect so much personal information that the giveaway can't be gamed or your giveaway will go to criminals and fraudsters. Neither is what anyone should want.

Unfortunately, I don't remember the details any more of why we stopped that giveaway. I'm pretty sure we had very good reason to believe it was gamed, but I don't recall specifically what it was. It could just have been that most of the people receiving the giveaway immediately transferred the XRP to the same aggregator accounts (and they weren't exchanges or anything like that). But honestly, I don't recall.


I didn't look closely, but I did see the link where you posted your secret rather than your address. That would have allowed anyone to steal your XRP. It's an easy mistake to make, but it definitely would have prevented you from receiving the giveaway because the process was automated.

I don't know how many invalid addresses were posted in the thread. It's easy to check. So if you're going to make the statement, you can easily measure. It might be a lot, it might not. I don't know. I never looked. But I'm not making claims about it. Obviously, invalid addresses didn't receive anything. Valid ones did until we ended the giveaway due to evidence that it was gamed.

That evidence is still available today. Survey the addresses pasted and look at where the XRP went. You can see that it went to a small number of accounts that were not exchanges. I think we had other stronger evidence at the time, but I don't recall for sure.

Honestly, I don't personally know for sure. I don't track all of our partnership deals as they happen and since I left the board of directors, I don't normally get the details on those deals unless I have some reason to ask. We generally wind up making the deals public but not their exact terms and we don't announce them before they're complete. Partners almost always insist such things remain confidential until they can do a press release. We announced a few partnerships with exchanges around that time, it could have been one of those, but I'm just speculating. The ledger is public, so you can probably figure it out if you look closely enough. It wouldn't surprise me if someone already knew and likely discussed it on xrpchat.

Again, I don't know the specifics of this incident. But it would be hard for me to imagine it was anything but. Timing a partnership deal is really complicated and access to our XRP reserves requires multiple parties to act in concert and various levels of internal approval.

I agree that it's kind of strange to compare the "market cap" of systems that operate differently. In a sense, you could argue that the full, eventual supply of both LTC and XRP should be used to calculate the market cap since that's all priced in. But that would make the system gameable too -- say only one XRP was on the market, it might have a very high price. Multiplying that by 100,000,000,000 would obviously give a ridiculously large market cap.

At one time, our strategy was basically to do the same thing bitcoin was doing but to take market share from it by being technically superior. But that was a long time ago. We're not pursuing XRP as a retail payment currency. We're not pursuing XRP as an investment for individuals. Our strategy is primarily to promote XRP as a bridge currency for payments.

Well, that was three years ago. We're a much different company now. Not only are we more than ten times larger, but we've been able to recruit people with expertise in areas other than just crypto-currencies. But, yes, we're still trying to do things that are very new and we'll likely still make lots of mistakes.

You can check the addresses in that thread yourself, just like I did. Go to, say, ten random pages. On each one pick three random ripple addresses. Check what XRP they've received. I wasn't that thorough, I checked one address from each of three random pages (from roughly the middle of the thread, if I recall) and they had all received the giveaway. And yes, they had all forwarded it to an aggregator account, so they were probably all the same person. :/

Fundamentally, you either need to map what you're giving away to the actual people who receive it or your giveaway will be gamed by scammers. We're definitely not the only people who had to learn that lesson the hard way. I don't believe in those kinds of giveaways anymore -- it makes more sense to use partnership agreements.

I don't have any particular motive here other than to help people understand why we did what we did. The last thing I'd want to do is pump XRP because that will cause short term spikes in price with subsequent drops. That doesn't help us in any way.

It's been a long time, but my recollection is that the giveaway operated for some time, making hundreds of payouts. I just checked a random sample of the accounts pasted on the page, and all of them had received their giveaway. Sadly, most of them had transferred the XRP given to them to a small number of aggregator accounts. That could mean that they sold their XRP, but more likely I think it indicates that a significant fraction of the giveaway went to scammers. Yes, we screwed up. But our heart was in the right place.

No personal information was needed to participate in the giveaway. All you had to do was paste a ripple address. As a practical matter, most people probably did use our hosted services to create those addresses, but they didn't have to. The javascript code to create a secret and ripple address was public at that time.

You did have to publicly map your user ID to your ripple address. In later giveaways, we used a blinding system that made this mapping impossible. But later we switched to giveaways only to people who had completed KYC with us at first and later partners.

We tried again with several other giveaways. Some of them were moderately successful (as I think that one was) but in all cases, the giveaways were gamed. It turns out it's really hard to get this right. I think we were also more concerned than perhaps we needed to be about the legal risks of sending something that might be money to persons unknown to us. But you have to remember, it was 2013, and all this stuff was still pretty new.

It's absolutely fair to criticize us for the problems these giveaways had. We were totally blindsided by how hard it was.

That's definitely a fair criticism. We tried, but we did make an awful lot of mistakes. It turns out that it's *really* hard. We got better as time went on, but honestly not that much better. I'm convinced now that giveaways of the types that we were initially trying are just a mistake, even if you could do them well.

Yes, these are things called facts.

No, but being accused and settling is not proof of guilt either.

As I said, this was only if you were interested in knowing the facts.

I don't know if you particularly care about facts, but "Convicted guilty of a Financial Crime" is completely untrue. There was a criminal investigation and a civil enforcement action. Ripple settled the civil enforcement action by paying FinCen a fine (and agreeing to other terms, basically that we would follow the law as FinCen understood it) and FinCen agreed not to prosecute us.
https://www.justice.gov/sites/default/files/opa/press-releases/attachments/2015/05/05/settlement_agreement.pdf

The agreement is an NPA.
http://us.practicallaw.com/9-608-6205

However, if we breach the agreement, FinCen can bring criminal charges against us. They can use our admissions under the NPA as evidence against us in a future criminal trial. So it's still a very serious matter.

Weirdly, though it was one of the most awful things we went through, it probably strengthened us. There was no actual prosecution, and partners reasoned that we probably would not have been able to get an NPA unless FinCen was convinced that our future conduct would be lawful. Oddly, I think in retrospect it actually helped us!

If you're ever in San Francisco, let me know. I'll buy you a beer and tell you the real story of that action.

I interpret "dumping" to mean selling on the open market. Yes, we absolutely do sometimes put large amounts of XRP into circulation. For example, as a result of a partnership deal, a partner might receive several hundred million XRP. There's always some agreement about how they will use that XRP and clauses that prevent them from dumping it.

Obviously, this can have a negative effect on the price of XRP. But we only do it when we believe the value of the partnership justifies the cost. Anyone who holds XRP, particularly those who are contractually prohibited from dumping it, shares our interest in seeing the price appreciate over the long term.

As important as knowing what you are is knowing what you aren't. The payments business is *huge* and it's going to take us a very long time and maximal effort to both grow it and take a slice of it. We've definitely talked about other things, but we're already trying to do as much in the payments space as we possibly can.

For example, there are a few people within Ripple who think that we should be doing something big in the identity space. I'm not one of them, and they are definitely in the minority. And the reason is this: Imagine if we had a perfect idea and fully-formed product for that space. We'd still need to market it, support it, and so on. Getting significant enough market traction to make it valuable is a massive undertaking,  comparable in scope to our current and planned efforts in the payments space. If we could double those, we would, we wouldn't build a second, equally large, parallel effort in another space.

That said, we do constantly re-evaluate our strategy and direction. And we do constantly evaluate whether we're trying to do too many things (and spreading ourselves too thin) or too few things (and possibly missing opportunities).

Not if you connect the miner to a powered hub that's plugged into a wall socket. But you will still lose money, sadly.

I just noticed this post now. It's been five years, but it's still relevant.

Right, but that doesn't matter. I agree that inflation changes the way you invest money, but it doesn't change your incentive to spend versus invest. (Stuffing money in your mattress acts just like a general investment in the economy because taking money out of circulation increases other people's buying power.)

What difference does it make how much they buy it for? Say Bitcoin weren't deflationary and so didn't include the right to hold it and make money, and say the price of bitcoin were $300. Now, say you keep everything else the same but make Bitcoin deflationary so it now includes the right to hold it through its appreciation. The net present value of a bitcoin might now be, say, $100 because it includes the appreciation right. So nobody's willing to sell a bitcoin for less than $400.

There's still not a special incentive to hold it. You can either hold it, and get the value of its appreciation, or sell it for $400 today, which includes that extra $100 that is the value of its appreciation. Either way, you get the same value.

It is essentially impossible to have predictable, excessive, prolonged deflation. Why? Because if we all agreed that some commodity would be worth $500 in a month, almost nobody would sell it for $450 today.

The price of a bitcoin today includes the expected value of its future appreciation moderated by the risk that this appreciation may not materialize. If that appreciation were certain, it would have already happened.

Stable is definitely better than volatile, even with some net increase. But a higher price helps us in several important ways:

1) A higher price means we can sell XRP for more money and thus increase our funding.
2) A higher price will be perceived as success. Perceived success helps drive adoption.
3) You can't use XRP to bridge a $1 million transaction today because you'd take huge losses from moving the price. We want XRP to bridge large transactions.

Of course, any kind of manipulation or hype to raise the price in the short term wouldn't help us. The inevitable subsequent crash would both increase the price of holding XRP making it harder to use it as an intermediate asset and it would be perceived as an indication that price growth doesn't reflect a genuine perception of success. Also, if you are worried that the price will drop, that will mean that you can't rely on XRP to bridge large transactions in the future because it might not have enough value and liquidity, so you won't build systems that rely on it (or perhaps even ones that benefit from it).

One of the ways you build consensus and volume is to get early adopters on board. Early adopters have to make investments in technology and infrastructure and take business risks that won't pay off if you fail. It helps a lot if people believe that your success is inevitable.

Ripple, the company, has never dumped XRP on the market. We definitely have had a problem with founders XRP getting sold in large amounts and we've worked extensively to get that locked up, even getting involved in several lawsuits.

It is absolutely fair to criticize how good or bad a job you think we've done in preventing XRP from getting dumped. But it is absolutely baseless and unfair to accuse us (other than Jed himself) of actual dumping.

We don't need XRP sales to fund the company. If XRP will never be worth more than it is now, then XRP doesn't matter, never did matter, and never will matter. If XRP will be worth more in the future than it is now, then why would a well-funded company with lots of XRP want to dump it?

There were actually two cases where there was attempted dumping that you could make a reasonable argument that we had some responsibility for. In both cases, we immediately took that XRP off the market and sought compensation from the parties.

Currently, we would accept whichever valid ledger (that is, all transactions follow the correct rules) had the highest weight by rippled's current algorithm. That would mean it would have to pass these tests (oversimplified a tiny bit):
1) It would have to have as a prior ledger whatever the last fully validated ledger was.
2) Each step from that last fully validated ledger to the candidate ledger would have to be replayable. That is, the transactions couldn't violate any gross rules.
Of those valid ledgers, we would accept the one with the highest weight. Factors that influence the weight include trusted validations for that ledger and nodes observed to be running that ledger.
So, effectively, we would take the "majority" ledger of those that don't violate sanity rules.

This code is also the code that helps the network recover from a very rare, but always theoretically possible, potential failure mode. There's a trivial proof that consensus will always have some risk of failing. Typically, only a small percentage of nodes fail each round and the split nodes rejoin the pack quickly and cause no harm. It's like a school of fish where 2% of the fish leave every few seconds and the 2% that split off a while ago rejoin. There's always more than 90% of the fish in the school.

But it is theoretically possible for consensus to fragment very badly. You can reduce the probability of this happening, but the cost is reducing the best case speed, so it's better to tolerate it than to avoid it. Imagine this happens and the network splits into ten groups each with 10% of the network and each in their own consensus round. This is effectively the same situation as the one you are hypothesizing, just over a smaller period of time. You need some avalanche of ledgers to get the network back to being able to fully validate a ledger.

Interestingly, this doesn't hurt the transaction rate. Ledgers still close at the same speed. But it does hurt confirmation latency, since you could go several ledgers without any ledger fully validating.

Gavin could have released bitcoin code that produced new bitcoins, but had no ability to force anyone to run it. It's absurd that he would have done so, but if you go through the thought experiment, very few people run it and Gavin loses credibility. Maybe bitcoin finds a new Gavin, maybe it goes on without a benevolent dictator, maybe it dies. But it's very hard to imagine him successfully forcing everyone else to accept a change like that.

And the same reasoning applies to Ripple and XRP. Sure, we can make any change to the code we want. And we can try to get people to run it. And maybe they will and maybe they won't. In practice, we probably have a lot of power right now. We could probably do some evil at the margins for a short period of time if we wanted to, just as Gavin could have. But if we did something truly crazy, it's hard to imagine people following us.

I mean, either people care about the network or they don't. If nobody cares, then what difference does it make? If people care, why would you expect them to go along with changes that hurt them dramatically when they have a clear alternative?

There is no RCL secret source. The public source code is the source code we run. Our validators run the same code everyone else's validators runs. We hold no power to control the validators other people trust or who runs a validator.

On the other hand, we do hold an awful lot of XRP. We could, for example, crash the market for XRP by selling a huge amount in a short period of time. That would hurt us more than anyone else. And our conduct has demonstrated to date precisely the opposite -- we've worked to lock up XRP and we've discussed our plans for how we'll release XRP to the world. But, of course, we remain free to follow our own interests as we see them. That is a big difference between XRP and many other assets. If you think we will be good stewards and our plans are likely to build demand, then you will tend to expect the price to go up. If you think we will screw it up, abandon XRP, or fail for some reason, then you will tend to expect the price to go down.

You just run rippled.

CAUTION: Oversimplified explanation. -- At all times, rippled has an "open ledger" that is uses kind of like a scratchpad. When your server receives a transaction, it applies it to the open ledger. If the transaction applies successfully, your server relays the transaction to other servers. When the next consensus round starts, your server will propose (just to itself if it's not a validator, to the world if it's a validator) that the transactions in your open ledger be applied to form the next "real" ledger. The network reaches an agreement on that set of candidate transactions, applies it to the last closed ledger, and then builds a new open ledger based on that.

My test is usually this one -- is there a head that, if you cut it off, the thing will die even if the folks who are left want it to continue?

So, for example, eBay is somewhat decentralized in that the items are sold by individual people. eBay doesn't have a centralized warehouse. But, of course, if the company stopped operations, the platform would die no matter how much everyone else wanted to continue selling. The company has the secret sauce ... the database, the licenses, the server software, and so on.

Even back when everyone ran the Bitcoin software Gavin told them to, Bitcoin was still decentralized. If Gavin went away, someone else could replace him. He had no legal means to force people to do what he wanted. He held no patent, no restrictive license, no secret sauce. People just ran the software Gavin told them to because a benevolent dictator that everyone chooses to follow is a damn good form of governance, particularly when there aren't that many stakeholders who really care about the platform.

Similarly, Ripple holds no secret sauce. Others can run validators, and do. Others can trust whatever validators they wish to, and do. Generally, people tend to do what we tell them to because we make good decisions and we care about the network more than pretty much anyone else does. But we hold no stick, no legal powers, no secret sauce, no real authority. People follow us because it's easier than making their own decisions and we haven't screwed up badly enough yet for people to justify the effort of doing the work that we do for them.

If we're lucky and the platform becomes more valuable and important, it will be harder and harder to remain the benevolent dictator who keeps everyone happy. Ask Gavin.

For projects that don't use this form of analysis already, typically between 1 to 2 in 100 of these reports on security critical code reflect an actual issue. But without surveying a statistical sample of them in that particular code base, you're really just guessing.

When we ran the first such report on rippled, we debated "fixing" every issue to get the number down to zero. The advantage would be that it would make it easier to scan future versions of the code as you wouldn't have a large number of false positives to wade through. We ultimately decided not to because in many cases it would require making the code harder to understand and maintain.

I wonder, if we had done so, would this report said we were the most secure or would they just have left us out? (And, to be clear, it would have also been absurd to say that a zero count from a tool like this makes us the most secure.)

Did you read my reply? Their methodology appears to be totaling the number of potential issues detected by automated, static analysis. This is almost completely meaningless because the vast majority of issues reported by such tools are false positives with no actual security implications. But it's doubly meaningless when you use it on code that already uses that exact same methodology because every issue that can be identified by this method has already been found and fixed. In fact, due to our use of this very same methodology, we've found and fixed bugs in third-party libraries we use such as RocksDB and Boost.
https://github.com/facebook/rocksdb/pull/333
https://github.com/boostorg/coroutine/pull/20