Why Ripple™ is against everything Bitcoin

[misterbigg]

every individual has the ability to do the exact same thing....Makes the banks play fair and gives the little guy equal opportunity:)

I wouldn't be so sure about that. It definitely creates more competition between banks. But individuals will not have the ability to do the truly interesting things, like transact on the Fedwire, perform ACH transfers, do Wire transfers, or issue Visa/Mastercard enabled Debit cards.

Furthermore individuals are not FDIC insured and there are fewer legal recourses. A bank has to post a bond, they can't just disappear. Although they certainly engage in quite a large share of bad behavior.

[JoelKatz]

I think if you still need to select several third-parties to decide which one of the two transactions invloved in a double-spend is valid, it's essentially a "commander and lieutenant" solution to Byzantine Generals problem.

You go with the transaction that's in the consensus ledger or one of its prior ledgers. If there isn't a consensus ledger, you deem the network fatally broken and don't trust any transaction.

so is it right to conceptualize the entire Ripple system as a replication of the existing banking system with it being likely that banks will act as gateways (and possibly as validators) doing the issuing and redeeming of XRP's (IOU's) except somehow with a p2p aspect layered in btwn individual ppl and open ledgers?

That's a stage it might go through, though I can't imagine that as the end game. On the bright side, if that does happen, payments will be faster, cheaper, and much less subject to arbitrary policies than they are now. People will be able to hold the currency of their choice, so you can get paid in dollars but hold gold, only to sell it right as you buy groceries. Exchanges will be open and decentralized and everyone with an Internet connection will have access to a massive financial network.

Right now, an international wire of $1,000 costs around $40. I'd love to be able to buy that transfer instantaneously on an open market, which would cost around $5.

[cypherdoc]

I think if you still need to select several third-parties to decide which one of the two transactions invloved in a double-spend is valid, it's essentially a "commander and lieutenant" solution to Byzantine Generals problem.

You go with the transaction that's in the consensus ledger or one of its prior ledgers. If there isn't a consensus ledger, you deem the network fatally broken and don't trust any transaction.

so is it right to conceptualize the entire Ripple system as a replication of the existing banking system with it being likely that banks will act as gateways (and possibly as validators) doing the issuing and redeeming of XRP's (IOU's) except somehow with a p2p aspect layered in btwn individual ppl and open ledgers?

That's a stage it might go through, though I can't imagine that as the end game. On the bright side, if that does happen, payments will be faster, cheaper, and much less subject to arbitrary policies than they are now. People will be able to hold the currency of their choice, so you can get paid in dollars but hold gold, only to sell it right as you buy groceries.

so what if an attacker early on in the Ripple system's evolution decides to create a 51% alternative reality ledger to disrupt the consensus?  not too hard given there is no proof of work security system in place.

[cypherdoc]

This is the holy grail, for me at least, because then I don't care if Amazon accepts Bitcoins or uses Ripple, I can just pay them using my debit card like normal except that the money will come from a just-in-time sale of Bitcoins on the distributed Ripple exchange.

you know you can buy from Amazon right now with Bitcoin using Bitcoin Spinner and Gyft Card apps installed on your Android?

[JoelKatz]

so what if an attacker early on in the Ripple system's evolution decides to create a 51% alternative reality ledger to disrupt the consensus?  not too hard given there is no proof of work security system in place.

Why would anyone care what they say? If you mean an attacker who builds trust, it's the same as a 51% attack on Bitcoin where the person builds mining power. Except in Ripple you can just choose to stop trusting them whereas in Bitcoin, you have a real problem.

You're correct that, if they built trust, this would create a temporary denial of service attack. But their bad behavior would be obvious and provable, so people would just stop trusting them. Given that the effort to do this is so great and the payoff so small, it seems unlikely anyone will bother. You're correct that Ripple is more vulnerable earlier on.

[oakpacific]

I think if you still need to select several third-parties to decide which one of the two transactions invloved in a double-spend is valid, it's essentially a "commander and lieutenant" solution to Byzantine Generals problem.

You go with the transaction that's in the consensus ledger or one of its prior ledgers. If there isn't a consensus ledger, you deem the network fatally broken and don't trust any transaction.

What will happen if I send one fake version of the proposed ledger to one validator, and another version to the rest of the network? How can the honest nodes find out who is cheating?

[JoelKatz]

What will happen if I send one fake version of the proposed ledger to one validator, and another version to the rest of the network? How can the honest nodes finds out who is cheating?

Everything is either signed or sent to a node who already knows the hash of the item it wants because it was referenced by something signed, so you can't send a fake anything anywhere. Basically, consensus just determines the order in which transactions are applied to resolve the double spend problem. Once a transaction is applied, conflicting transactions are blocked.

Candidate transactions must be signed by the account that issued them. Validations and proposals must be signed by validators you've chosen to listen to. Otherwise, you just ignore it.

[oakpacific]

What will happen if I send one fake version of the proposed ledger to one validator, and another version to the rest of the network? How can the honest nodes finds out who is cheating?

Everything is either signed or sent to a node who already knows the hash of the item it wants because it was referenced by something signed, so you can't send a fake anything anywhere. Basically, consensus just determines the order in which transactions are applied to resolve the double spend problem. Once a transaction is applied, conflicting transactions are blocked.

Candidate transactions must be signed by the account that issued them. Validations and proposals must be signed by validators you've chosen to listen to. Otherwise, you just ignore it.

Will every node have to obtain my verification key from other nodes on the network, or will they get it from me?

[cypherdoc]

You're correct that, if they built trust, this would create a temporary denial of service attack. But their bad behavior would be obvious and provable, so people would just stop trusting them. Given that the effort to do this is so great and the payoff so small, it seems unlikely anyone will bother. You're correct that Ripple is more vulnerable earlier on.

but in a monetary system you can't afford to have any mistakes in trust at all or otherwise ppl lose money. and potentially lots.  we had a near escape from the 0.7 to 0.8 upgrade. 

based on what you've said, i see no reason why banks would want to play along with Ripple.  why would they cede control of their fate from the Fed, who is in their pockets, to OpenCoin an unknown small new entrant?

[misterbigg]

You're correct that, if they built trust, this would create a temporary denial of service attack.

You need to be more explicit, and explain in clear well defined terms what the attacker is able to do. I am certain that many people reading this will think that attackers can rewrite account balances, perform double spends, etc... but from my understanding this is not possible. The worst that they can do is prevent transactions from clearing.

Every Ripple transaction has a "sequence number", and two transactions in a row for the same account cannot clear until the first transaction clears.

[jbreher]

Neither shill nor premine screamer, I am one of the hopefully still rational trying to understand the implications behind Ripple. Allow me some continued discussion...

Source code is not "open", you can do what you want in your closed code and nobody can really control you (except governments of course).

Not true. All ledgers are public, and signed by us. All differences between ledgers must be justified by a transaction signed by the account that issued it. All transactions are public and each transaction includes the precise "delta" is applied to the ledger. We can't just do whatever we want.

This is a point I have missed until now - "All ledgers are public and signed by us." While public ledgers seem on the surface a good thing [assuming that fine-grained pseudonymity is still available], I would like to focus upon the "signed by us" portion. Shall I assume that "us" is OpenCoin? Now and forever? Now until some future unspecified eventuality occurs? Is this not then a centralized point of attack?

Also, because you are not Open Source, governments can shut you down at any given time they want.

The code would automatically become open source if that happens. Developers have that in their contract and any number of people have the source code and understand these terms. I've discussed the contingency plans for that case several times, I think at least once in this very thread.

Similar to misterbigg, this struck me as new information. What plans are in place for this to happen? While I do not doubt that an intent has been discussed and generally assented to, there are a litany of chances for failure from that position to actual concrete plans, with M of N safeguards, clearly defined trigger points, and failsafe and backup mechanisms. I'm sure we'll all recall that Pirate and GLBSE claimed to have such plans in place. A public disclosure of the specific plans would likely go a long way of easing at least this particular doubt in the minds of many. If you truly discussed this in this very thread, it must have been disclosed only very obliquely. Or perhaps I (and demonstrably at least one other) were sleeping during that portion of the thread.

...As I catch up with the thread's head, I ran across this...

why you think there is a consensus mechanism that actually carries weight in a decision making process moreso than just being able to view balances and transactions on a gateways ledger (which i think is a long shot feature especially if we're talking about banks).

Each validator signs the consensus ledger each time a new one is created. So you have a set of cryptographic signatures for each ledger produced by a large number of independently-operated validators, none of which gets to choose the rules by which new ledgers are created from prior ledgers. Further, the ledgers contain hash chains which lead to prior ledgers and signed transactions that justify the changes between them. Also important -- the gateways don't get to choose the rules by which transactions are executed, nor can they make exceptions to them.

Are the "us" in "All ledgers are public and signed by us" above actually the validators? Who are the validators? And what makes them able to judge what is and what is not a valid transaction? Can anyone be a validator? What is the criteria?

As far as the "rules by which new ledgers are created from prior ledgers", are these rules encoded in immutable protocol? Or are the subject to change over time? And if the latter, who can participate in these rule changes?

Last in the above, what happens if a gateway refuses to honor their previous commitment to carry out all transactions on a non-discretionary basis? Would this be synonymous with refusal to honor their IOUs? What if a gateway becomes insolvent?

[QuestionAuthority]

I see the most blind Ripple hate coming from miners. I suppose Ripple is seen by some as a threat to the value of mining.

Not only do I agree with Erik Voorhees (the epitome of a Bitcoin bull) that in a general sense competition is always good. I also feel Bitcoin and Ripple are allies in a competition that's happening in a bigger arena than most people are aware of.

"A Billion dollars isn't cool. You know what's cool? A trillion dollars." - Nameface

Also, some people say Ripple is "just trying to be a better Paypal". Can someone please explain to me WTF is wrong that? We need that yesterday.

Hey, what's up with this: https://bitcointalk.org/index.php?topic=204533.0

[JoelKatz]

Will every node have to obtain my verification key from other nodes on the network, or will they get it from me?

Why would they need your verification key at all? If you mean to process your transactions, it works much the same way as Bitcoin. Your "account" is a hash of the public key and transactions include the public key in them. If you mean you're acting as a validator (which is absolutely not needed to introduce transactions) then they would get your public key from whatever source induced them to trust you. You can publish it through HTTPS.

[oakpacific]

Will every node have to obtain my verification key from other nodes on the network, or will they get it from me?

Why would they need your verification key at all? If you mean to process your transactions, it works much the same way as Bitcoin. Your "account" is a hash of the public key and transactions include the public key in them. If you mean you're acting as a validator (which is absolutely not needed to introduce transactions) then they would get your public key from whatever source induced them to trust you. You can publish it through HTTPS.

If it's just me, as a validator I can always propagate two versions of my signatures corresponding to different keys, I can still cheat without being found.

If they have to obtain it from someone else, then you have to use either PKI, or a web of trust, which I assume is what you use no?

[mmeijeri]

I wouldn't be so sure about that. It definitely creates more competition between banks. But individuals will not have the ability to do the truly interesting things, like transact on the Fedwire, perform ACH transfers, do Wire transfers, or issue Visa/Mastercard enabled Debit cards.

But crucially, they can settle netted transactions in cash every now and then, which would give us a p2p payment system for cash.

[JoelKatz]

Will every node have to obtain my verification key from other nodes on the network, or will they get it from me?

Why would they need your verification key at all? If you mean to process your transactions, it works much the same way as Bitcoin. Your "account" is a hash of the public key and transactions include the public key in them. If you mean you're acting as a validator (which is absolutely not needed to introduce transactions) then they would get your public key from whatever source induced them to trust you. You can publish it through HTTPS.

If it's just me, as a validator I can always propagate two versions of my signatures corresponding to different keys, I can still cheat without being found.

Then you would be two validators. If either validator wasn't behaving rationally, people would just stop trusting it.

To do any real harm, you'd need to control a significant fraction of the validators that people trust. Then it'd be much like a Bitcoin 51% attack -- except after all that trouble, people would just stop trusting you and you'd have to start over from square one. Whereas, with a 51% attack on Bitcoin, it's much harder to recover. (Though not impossible, of course.)

With Bitcoin's proof of work based algorith, you have to trust that the majority of mining power will not collude against you. With Ripple's consensus algorithm, you get to choose the validators that you trust not to collude against you. Admittedly, this has disadvantages as well -- if you choose very badly, you could suffer for it. In realistic scenarios though, I don't think it's that hard to choose wisely. And the attack is so hard to make and gains you so little (just a denial of service attack unless you control the *vast* majority of validators), I don't think anyone is likely to bother.

If they have to obtain it from someone else, then you have to use either PKI, or a web of trust, which I assume is what you use no?

Not really a PKI or a web of trust. The simplest way is to publish it using HTTPS. Look at https://bitstamp.net/ripple.txt for example.

[oakpacific]

Will every node have to obtain my verification key from other nodes on the network, or will they get it from me?

Why would they need your verification key at all? If you mean to process your transactions, it works much the same way as Bitcoin. Your "account" is a hash of the public key and transactions include the public key in them. If you mean you're acting as a validator (which is absolutely not needed to introduce transactions) then they would get your public key from whatever source induced them to trust you. You can publish it through HTTPS.

If it's just me, as a validator I can always propagate two versions of my signatures corresponding to different keys, I can still cheat without being found.

Then you would be two validators. If either validator wasn't behaving rationally, people would just stop trusting it.

To do any real harm, you'd need to control a significant fraction of the validators that people trust. Then it'd be much like a Bitcoin 51% attack -- except after all that trouble, people would just stop trusting you and you'd have to start over from square one. Whereas, with a 51% attack on Bitcoin, it's much harder to recover. (Though not impossible, of course.)

With Bitcoin's proof of work based algorith, you have to trust that the majority of mining power will not collude against you. With Ripple's consensus algorithm, you get to choose the validators that you trust not to collude against you. Admittedly, this has disadvantages as well -- if you choose very badly, you could suffer for it. In realistic scenarios though, I don't think it's that hard to choose wisely. And the attack is so hard to make and gains you so little (just a denial of service attack unless you control the *vast* majority of validators), I don't think anyone is likely to bother.

If they have to obtain it from someone else, then you have to use either PKI, or a web of trust, which I assume is what you use no?

Not really a PKI or a web of trust. The simplest way is to publish it using HTTPS. Look at https://bitstamp.net/ripple.txt for example.

The problem is how can you prove I am trying to be two validators? Say I only give one guy a false key, and if he's trying to accuse me then I can say everything including the supposedly signed ledger is made up by him, I can say I never produced such a thing, and the guy trying to accuse me is a fraudster himself.

Not really a PKI or a web of trust. The simplest way is to publish it using HTTPS. Look at https://bitstamp.net/ripple.txt for example.

It's not really relevant, you have to either trust a authoritative third-party or the people who transmitted this information to you, like the digital certificate of the website(PKI), forum on which your website address is published, or other Ripplers who told you where the validator's website is(web of trust). Most importantly, you can't prove I am cheating if I try to frame someone by claiming I received a copy of ledger signed with a different key from him, especially if I control more nodes than him(nowhere near 51%), which are not known to collude.

[OnkelPaul]

The problem is how can you prove I am trying to be two validators? Say I only give one guy a false key, and if he's trying to accuse me then I can say everything including the supposedly signed ledger is made up by him, I can say I never produced such a thing, and the guy trying to accuse me is a fraudster himself.

"Prove" is a stronger word than "mistrust".
To mistrust you (or your two validator identities) I don't have to prove anything, it's enough that my gut feeling tells me that there's something fishy with those two validators, so I stop trusting them.

Onkel Paul

[oakpacific]

The problem is how can you prove I am trying to be two validators? Say I only give one guy a false key, and if he's trying to accuse me then I can say everything including the supposedly signed ledger is made up by him, I can say I never produced such a thing, and the guy trying to accuse me is a fraudster himself.

"Prove" is a stronger word than "mistrust".
To mistrust you (or your two validator identities) I don't have to prove anything, it's enough that my gut feeling tells me that there's something fishy with those two validators, so I stop trusting them.

Onkel Paul

It's equally possible that I am indeed being framed, and by ostracizing me, you effectively choose to trust the evil guy.

[OnkelPaul]

It's equally possible that I am indeed being framed, and by ostracizing me, you effectively choose to trust the evil guy.

In a sense, yes. Trust cannot be objective, it's a subjective issue - and if my assessment of a situation is wrong, I might trust the wrong people.
But when I mistrust your validator I don't automatically trust the other guy's validator, so the worst thing that could happen to me is that my validator needs to run with a smaller list of trusted nodes. As long as the list is sufficiently diverse that doesn't hurt.
If doubts about your validator are being spread around, it might be trusted by fewer other nodes. However, this would not affect any signed transactions that you send into the network, so your ability to use Ripple is not reduced.
The only effect it might have on you is that your validator is doing its work without being noticed. Big deal.

Onkel Paul