The client source is open. The server source code is not open yet.

As soon as the server source code is open, it will be very difficult to make changes in Ripple's behavior. Had we released the source code to the public at the same time we made access available to the public, as Bitcoin did, there would have been no chance for public participation in the early design.

Bitcoin was presented to the community as a done deal, take it or leave it. If people had reasons to disagree with the block reward schedule, for example, they had no chance to discuss it or make their case. That was set in stone by the early developers.

We can still make those kinds of changes in Ripple. And we are still discussing structural changes based on community input that will make the system better. See, for example:
https://github.com/rippleFoundation/ripple-client/issues/748
Here's a case where members of the community disagreed with a part of Ripple's design and because Opencoin still runs the majority of validators, it can still be improved. Had we followed Bitcoin's model, we likely would have been stuck with it.

Fortunately, I don't think there's anything in Bitcoin that's bad that we're stuck with. I'm not sure if that's due to luck or just the designer's genius. But we didn't have that kind of confidence, and it turns out that it was probably a good thing that we didn't. There are at least three major things that we're working to improve based on community feedback.

It wasn't entirely within the Ripple system. He approached people outside the Ripple system and used mechanisms outside Ripple to convince them to do things. And it wasn't Ripple itself that was compromised, it was just the accounts of the people who did what he told them to do. He told people to tell Ripple to consider a worthless asset as equal in value to a valuable asset, and Ripple did exactly what they told it to do. He used social engineering to induce people to tell a system to do dumb things, then the system did dumb things, and then he blamed it on the system rather than on himself.

Essentially, what you're saying is that it all works great as long as nothing ripples. And that's basically what I've said, we can implement it with contracts, but it's not going to work with the ripple-based payment system. Rippling can only work if the system can determine the value of something to someone without needing them to specify an exchange rate or time horizon. You can't expect the average person to manually maintain an exchange rate or time horizon nor can the system force a person to accept an exchange rate or time horizon they haven't agreed to. They have to specify an asset value though -- a new account considers all assets worthless and won't give any asset any value until a user specifically assigns it one. If an asset can work with just a value, it can fit into the ripple-based payment system. If not, not.

He's convincing people to hurt themselves with powerful technology as a way of arguing that people are too dumb to have that technology or the technology is bad because it enables people to hurt themselves. It's completely different from arguing that there should be better safeties or warnings.

For example, consider a hammer. A person can bash their thumb with a hammer. The Luddite argument is that because people can bash their thumb with a hammer, hammers are bad. Or, worse, convincing people to use hammers carelessly so you can show lots of pictures of black and blue thumbs to stop this scourge of evil hammers. It's not at all the same as arguing that because people can bash their thumbs with a hammer, people need to understand how to safely use hammers or that it might be worth investigating whether a hammer can be designed such that it's more difficult to hit your thumb.

No. I'm saying that technical criticism about insufficient safeties or warnings is in a completely different category from tricking people into doing things whose consequences they don't understand and that you know will cause harm.

Hey, I'm not the one who lent Patrick money at usurious rates knowing that he was going to use the money in a business that was doomed to fail and then insisted I was doing him a favor. I'm the one who pointed the finger at you for that bit of stupidity.

You're comparing apples to oranges. To make your analogy work, he'd have to be tricking people into shooting each other with that handgun rather than criticizing it.

You're totally off the topic here. This isn't about microscopic design features of Ripple. He didn't criticize a design feature, make points for and against it, and convince people that the design has a defect that should be changed. He devised a scheme to exploit what he thinks is a defect that hurt real people. (And, by the way, rational people are having that rational argument elsewhere. We're already talking about different design changes to reduce this risk.)

Bitcoin allows instawallet to do whatever they want without anyone's approval. Both "attacks" take advantage of the fact that you can trick people into doing things that have negative consequences that they might not be aware of.

Both attacks involve tricking someone into doing something that can have negative consequences of which they may not be aware and then exploiting the results of that trick. Even if it required explicit approval, you could just as easily trick people into providing that approval. By requiring it of them before making a payment to them.

http://www.hrmorning.com/would-you-trade-your-password-for-a-candy-bar/

No.

No. I'm not going to switch from argument to argument while you refuse to either defend or abandon the arguments I've rebutted. Please don't restate my argument but actually address the argument I made.

Here it is again:

Do you agree or disagree that these are comparable? If you think they are different, in what relevant way are they different?

Two people reply to me but neither actually addresses the argument I was making at all. You're welcome to make 800 different arguments, but it gets really tedious when you keep switching to another argument you don't actually believe every time I address the ones you made. Does anyone want to actually respond to this argument:

It's roughly comparable to proving that Bitcoin is broken by starting an exchange or web-based wallet and then running off with the money or tricking people into deleting their wallet files. It's a Luddite attack on Bitcoin, Ripple, and technology in general -- an attempt to prove that people are too stupid to have powerful tools.

It doesn't automatically treat any debt as having any value at all. It considers all assets as completely worthless until and unless you specifically tell it to value some particular asset.

See the part you quoted above. A Ripple invariant is that someone else's transaction can do something to you so long as you have agreed that it is fair. There is no way to tell if something is fair to you unless we know how you value assets, and if those assets have interest rates associated with them, their value cannot be determined without knowing the time horizon.

If someone owes you $10 and is paying you 6% interest and someone offers to owe you $9 at 18% interest (assuming you trust both of them), is that a fair trade? Which is worth more? Well, it depends on the time horizons.

I'm not sure what you mean by how do you differentiate them. It seems like you already have -- these are different because they are worthless. If you want to get rid of them, drop your trust line to him to zero and see if anyone will take them from you. If not, you can "write them off" by paying them back to him.

While I believe this can be made to work from a technical angle, I'm very nervous about how well it will work in the real world because of the incentives it creates. We want validators to have a strong incentive to broaden their UNL to avoid a network split. In this scheme, each validator you add to your UNL costs you money, and there's a much greater risk that the set of validators will be a small group that refuses to listen to anyone outside the group and presents a "take it or leave it" choice to the outside world.

Assuming you want the mining rate to be relatively fixed, every node except the one that "mines" a block now has an incentive to prevent a consensus being reached on that block because that's one more reward it won't get rather than a chance at that reward. Bitcoin doesn't have this problem because every miner has a strong incentive to build on the longest chain. I'm not sure how you could replicate that in this scheme.

It's not possible in principle unless you have a time horizon set on every interest bearing asset. It is a necessary system invariant that if you want to ripple through someone, you give them something they value equally to (or greater than) what you take from them. This is not possible to enforce for interest bearing assets without a time horizon set on every asset.

Say you have an asset that you value today at 10 USD and it has an 8% interest rate. And say I want to ripple through you and take in exchange another asset that you value today at 10 USD that has an 8% interest rate. Is that fair? Well, it depends on the time horizons. Worse, a longer time horizon is good if the interest rate is good but bad if the interest rate is bad. So you need every user to set a target interest rate and a time horizon for every asset.

So it can't work unless you know the time horizon and, worse, also the baseline interest rate. But if you know the time horizon, the interest can just be added to the balance at issue time. Then it all "just works" because you know the present value of every asset.

Unless you're talking about some insane rate, demurrage can be ignored over the lifetime of a single trade offer.

Whoever decides it, it has to be decidable. If you don't know the time horizon, you can't value assets that have interest. If you have assets you can't value, you can't rationally trade them.

It's purely because you cannot value such an asset. Ripple is based on being able to value assets so that they can be traded. We'll do it in contracts, but I don't see how it can be part of the normal exchange system because you cannot value it.

I can mock you as easily as you can mock me.

You can make up every conspiracy theory you want. The lack of evidence just makes the conspiracy all the more evil. But I don't make an argument I don't believe.

Your universe doesn't fit well with reality either. You want demurrage so that people can't sit on a pile of money at no cost. However, you also want currency freedom so people can choose a currency without demurrage if they wish to.

That's redundant. Already, the quicker they pay, the sooner they destroy the obligation. Having them pay more interest as well would be double dipping.

Say I trade a chair for a couch, and we agree that the chair and the couch are equal in value but that we'll swap back in a year. If I trade you back earlier, you get the couch back sooner, but I don't have the chair for as long. There's no reason either of us should charge the other. So long as the two things exchanged are roughly equal in value (which they must be, or the exchange wouldn't have taken place), it doesn't matter how long the exchange goes on. Loans in Ripple are exchanges of more liquid IOUs for less liquid IOUs of equal value.

It can't default because it was paid at the time it was made.

We will support interest through contracts, but IMO, it's not necessary and doesn't work well. If a $10 IOU from me is worth $9, then we can just trade the $10 IOU for $9 and there's no need for interest because it's an even exchange.

You have to know the time horizon to value an asset that pays interest. For example, if one person owes you $10 at 10% and another person owes you $10 at 15%, which asset is worth more? Well, you might think it's the one at 15%, but if they pay you back tomorrow, the interest rate is irrelevant. So you must know the time horizon to value an asset with interest. But if you do know the time horizon, the interest is not needed. If I'm going to loan you $100 at 10% and I know the time horizon is a year, we can just make the IOU for $110. There's no need for interest.

This is a bit oversimplified, but hopefully the basic idea comes across.

Yes, but they won't add as much to the security of the system because of the added latency. The rest of the network won't always wait for them. If there are too many high-latency validators, it will make the network slower because the code won't let the network shrink to a small subset of "super fast validators", nor will it run as slow as the slowest validator. It strikes a balance, and nodes running over tor push that balance towards slower confirmations while more often finding themselves excluded because by the time they have enough information to help make a decision, a super-majority has already made the decision.

I'm not exactly sure what tor's latency is. If it's less than a second round-trip, then it probably won't matter.