Ripple competition

[JoelKatz]

Does Ripple offer instant reliable transactions?

That was the primary design goal of the "continuous ledger close" algorithm that Ripple uses.
https://ripple.com/wiki/Continuous_Ledger_Close
The goal is to provide you a cryptographically-signed receipt for a hash that provably includes confirmation of your transaction from a supermajority of the validators you have chosen to use.

[1714680849]

1714680849

[1714680849]

1714680849

[1714680849]

1714680849

[1714680849]

1714680849

[Coinseeker]

Does Ripple offer instant reliable transactions?

That was the primary design goal of the "continuous ledger close" algorithm that Ripple uses.
https://ripple.com/wiki/Continuous_Ledger_Close
The goal is to provide you a cryptographically-signed receipt for a hash that provably includes confirmation of your transaction from a supermajority of the validators you have chosen to use.

Which in non-tech terms means, "yes".  

[zachcope]

The main thing is if I trust Bitstamp to do my BTC business on it, I trust them to do my Ripple stuff. I don't care about philosophizing with tech terms and such bullshit who trust who, bla-bla-bla...

Bitcoin enthusiasts should be last in line to preach about security, trust and similar stuff with robberies and hacks happening daily in their industry.

I think that's pretty much going to be the view of Ripple as more infrastructure comes online.  Most people will never even know they are using Ripple and won't care that it is powered by Ripple.  Just like people use websites and don't know and don't care they are powered by Wordpress.  Or as has been repeated constantly, email and SMTP.  People don't care how it works, just that it does.  That's the beautiful thing about Ripple, it's a true protocol that can operate completely transparently. People know the weaknesses of Bitcoin and it scares them because just as Erik V. said, "the only thing that can kill Bitcoin, is a superior currency" and they worry that Ripple will provide that.  So fear, causes them to miss that which is amazing about Ripple as a payment network and distributed exchange and more importantly the benefits it provides to Bitcoin, by making up for many of it's weaknesses.  

It can operate transparently until someone with too much trust defaults.  If all the people who trusted them can't back up the defaulter's debts, said default will "ripple" and likely knock quite a few decent people off of the network.

Agree with this.
Consider the incentives Ripple are setting up.
If a gateway has a bad debt there is NO incentive to write this debt off on the Ripple network, as it will make the gateways IOUs less valuable, making it more difficult for the gateway to service the debt.
If the gateway writes off the debt however, for example by covering the fiat loss at their end, the debt stays in the network forever.
Hey presto - new money!
This can go on for quite some time until Poof! the whole network fails.
Bit like all the current banking disasters.
Also I'm not sure how private gateways will police debt without the authority to bear arms, or without becoming loan sharks.
In which case the gateways will have to be as regulated as legacy banks, with no advantages.

[Come-from-Beyond]

Does Ripple offer instant reliable transactions?

That was the primary design goal of the "continuous ledger close" algorithm that Ripple uses.
https://ripple.com/wiki/Continuous_Ledger_Close
The goal is to provide you a cryptographically-signed receipt for a hash that provably includes confirmation of your transaction from a supermajority of the validators you have chosen to use.

Which in non-tech terms means, "yes".  

So, what is sacrificed in Ripple then: Consistency, Availability or Partition tolerance?

[oakpacific]

Does Ripple offer instant reliable transactions?

That was the primary design goal of the "continuous ledger close" algorithm that Ripple uses.
https://ripple.com/wiki/Continuous_Ledger_Close
The goal is to provide you a cryptographically-signed receipt for a hash that provably includes confirmation of your transaction from a supermajority of the validators you have chosen to use.

Which in non-tech terms means, "yes".  

So, what is sacrificed in Ripple then: Consistency, Availability or Partition tolerance?

Imagine what would happen when some gateways losing communication(unverifiably) to some others...........

Or may be they just think centralization is a better idea

If everyone chooses a completely disparate sets of validators the network will be unlikely to reach consensus that a particular version of the ledger is the one true and accurate ledger. But, in practice, people's UNL lists will overlap. This overlap causes the honest validators to come to the same consensus

[Come-from-Beyond]

Imagine what would happen when some gateways losing communication(unverifiably) to some others...........

Still don't see the answer.

[oakpacific]

Imagine what would happen when some gateways losing communication(unverifiably) to some others...........

Still don't see the answer.

I fixed my post.

[JoelKatz]

So, what is sacrificed in Ripple then: Consistency, Availability or Partition tolerance?

Partition tolerance, of course, the same as Bitcoin.

Imagine what would happen when some gateways losing communication(unverifiably) to some others...........

Imagine what happens when some mining pools lose communication, unverifiably, to some others. You might have six confirmations but on the other side of the partition a conflicting transaction has eight confirmations.

Ripple would be much more vulnerable to this than Bitcoin would because you would need a partition that separates well-connected mining pools for many minutes to cause a problem for Bitcoin. Because of this, Ripple actually needs to detect and deal with partitioning. Which it does, of course.

[amencon]

I will try to explain in simple words why Bitcoin and Ripple are complementary tools...

Imagine that Bitcoin becomes widely adopted currency and that you can pay with bitcoin in every store.

Do you see the problem?

Just imagine how long would be a waiting line if every customer waits for a 6 confirmations.

Bitcoin needs a payment system that could send Bitcoins instantaneously and the solution is Ripple.

I hope that you now understand how Ripple could help Bitcoin to reach wide adoption.

Cheers!

Won't most day to day transactions not require 6 confirmations anyway?  Why would you need the full 6 or any for that matter for a small quick low cost purchase?  Not saying Ripple won't compliment Bitcoin but I'm not see this as it.

[JoelKatz]

Won't most day to day transactions not require 6 confirmations anyway?  Why would you need the full 6 or any for that matter for a small quick low cost purchase?  Not saying Ripple won't compliment Bitcoin but I'm not see this as it.

It's hard to predict the future. Right now, zero confirmations is probably fine for in person low cost transactions and one for transactions under $2,000. But the block reward is what's protecting us from the Finney attack. In the future, the block reward might be small compared to the value of a double spend.

[oakpacific]

So, what is sacrificed in Ripple then: Consistency, Availability or Partition tolerance?

Partition tolerance, of course, the same as Bitcoin.

Imagine what would happen when some gateways losing communication(unverifiably) to some others...........

Imagine what happens when some mining pools lose communication, unverifiably, to some others. You might have six confirmations but on the other side of the partition a conflicting transaction has eight confirmations.

Ripple would be much more vulnerable to this than Bitcoin would because you would need a partition that separates well-connected mining pools for many minutes to cause a problem for Bitcoin. Because of this, Ripple actually needs to detect and deal with partitioning. Which it does, of course.

No problem at all, as long as the merchants are well connected and see all the blockchains, they can decide if their transaction is in the longest chain , and when to release the goods.

A Ripple merchant would not have such good luck if his trusted validators are disconnected from a bunch he doesn't trust....

[JoelKatz]

No problem at all, as long as the merchants are well connected and see all the blockchains, they can decide if their transaction is in the longest chain , and when to release the goods.

This would work if they were directly connected to at least 50% of the hashing power and confirmed that they saw a block from each major mining pool prior to processing transactions in it. I wonder if anyone actually does this.

A Ripple merchant would not have such good luck...

This is automatic with Ripple. If you don't see validations from a supermajority, you know you are partitioned. There's nothing special you need to do -- it's built in.

if his trusted validators are disconnected from a bunch he doesn't trust....

He will soon. If his trusted validators are disconnected from the majority, they will report this, and he will know the network is partitioned. (This isn't implemented on the live network yet, it is still being tested. It's needed to support trustless clients.)

[Come-from-Beyond]

So, what is sacrificed in Ripple then: Consistency, Availability or Partition tolerance?

Partition tolerance, of course, the same as Bitcoin.

Bitcoin sacrifices Consistency (it is eventual one). Partition tolerance can't be applied to Bitcoin coz the blockchain can't be partitioned. The same with Availability, the local copy of blockchain provides 100% availability.

Who is CTO of Ripple? I think he should know better what the answer to CAP issue is.

[oakpacific]

A Ripple merchant would not have such good luck...

This is automatic with Ripple. If you don't see validations from a supermajority, you know you are partitioned. There's nothing special you need to do -- it's built in.

Hmmm, so instead of work, sheer numbers matter right? Our botnet operating Russian friends will be very pleased I guess...

He will soon. If his trusted validators are disconnected from the majority, they will report this, and he will know the network is partitioned. (This isn't implemented on the live network yet, it is still being tested. It's needed to support trustless clients.)

That is to say when partitioning is not resolved, availability will be gone, so instant transaction is only available as long as most of the major trusted validators on the network are connected to each other, I am not sure if I can call it "reliable".

[JoelKatz]

That is to say when partitioning is not resolved, availability will be gone, so instant transaction is only available as long as most of the major trusted validators on the network are connected to each other, I am not sure if I can call it "reliable".

That's correct. If the majority of validators are not connected to each other, the network is not reliable. It does not pretend to be. The same is more or less true with Bitcoin -- if you're not connected to 51% of the hashing power, you cannot rely on a transaction no matter how many confirmations it has. The difference is that Ripple detects this case.

[mmeijeri]

Ripple is more resistant to a gateway collapsing than bitcoin is. The scenario you were describing is similar to inputs.io's meltdown. It didn't take down btc, and in the case of Ripple anyone could tell how much outstanding debt there was at any instant. And of course,  XRP, like BTC held in your self hosted wallet, is immune against all this. The strength of Ripple lies in the combination of its subsystems. Critics like to pick one, pretend that's all there is, and then point out the flaws of having just that system as if that were criticism of the whole. The truth of the matter is that Ripple can do everything Bitcoin can and much more, all in one package.

[JoelKatz]

Hmmm, so instead of work, sheer numbers matter right? Our botnet operating Russian friends will be very pleased I guess...

No, of course not. You actually have to convince human beings that public keys are controlled by organizations that cannot collude. And all that happens if they do is that the network does not reach consensus and those who betrayed this trust have done so provably with cryptographic signatures. So any trust in them can be removed and the problem solved and the attacker has to start over. Which is better -- an attacker just needs money and can double spend and then the system is broken or an attacker needs to build human trust and then can prevent the network from operating and then the attacker has to start over from scratch?

He will soon. If his trusted validators are disconnected from the majority, they will report this, and he will know the network is partitioned. (This isn't implemented on the live network yet, it is still being tested. It's needed to support trustless clients.)

That is to say when partitioning is not resolved, availability will be gone, so instant transaction is only available as long as most of the major trusted validators on the network are connected to each other, I am not sure if I can call it "reliable".

The same is true of Bitcoin. If you are not reliably connected to 51% of the hashing power, no number of confirmations is sufficient. The difference is, with Ripple it's possible to reliably tell if you are or are not connected.

[Come-from-Beyond]

The difference is, with Ripple it's possible to reliably tell if you are or are not connected.

From http://www.links.org/files/decentralised-currencies.pdf:

To match this to the notion of “decentralised” (i.e. lacking central authority), the consensus group must be, at least, all participants in the currency. This does not present any real problem when that group is known. For example, it would be possible to define the group as “all people currently in the United States”– where the currency would be something akin to the US Dollar. Assuming the majority decide to behave honestly (as seems likely, after all, that is what happens now), then they should have no difficulty in forming consensus on who has how much money at what time. However, the most general notion of decentralisation does not admit such re-strictions. After all, in some sense, placing any such restriction simply pushes the central authority back a layer: instead of controlling the currency, the authority controls membership of the consensus group.

Seems that reliability of telling if u r connected is provided via sacrificing of decentralization? Or even worse, users decide themselves and this can lead to fatal consequences.

[JoelKatz]

Seems that reliability of telling if u r connected is provided via sacrificing of decentralization? Or even worse, users decide themselves and this can lead to fatal consequences.

Right, those are the two extremes, and neither extreme is very good. But there are quite satisfying options in the middle. For example, you can have any number of "authorities" who publish lists of who they think should be in the consensus group and users can select whatever set of such "authorities" they want (or none, but then they are taking upon themselves the obligation to ensure their own reliability). The biggest downside of the consensus process is that it requires more management than proof of work does. As the recent blockchain split proved, proof of work does occasionally require management too.

Consider Bitcoin. You could just use the official distribution and update all the time. But then what if someone slips something bad into the official distribution? And is that decentralized? Or you could maintain the code yourself. But that would take a lot of time. And what if you screw up a fix to a severe vulnerability? That would make you fully independent, but it's not practical.

Most users track official releases because it saves them the trouble of keeping code up to date themselves, evaluating new features, and so on. But Gavin puts out new releases of the code and could, in principle, put out a release that steals everyone's Bitcoins, doubles the block reward, or does anything else he wants. Of course, if Gavin did anything as crazy as the things I suggested above, he'd cease to be an authority immediately. If he isn't responsive to the community and stakeholders, people will stop listening to him. And anyone who wants to maintain a fork of the official code is welcome to and can convince people to follow their code changes instead if they want to.

Of course, if you don't follow official code changes, or do the work yourself of tracking protocol changes and fixing vulnerabilities, or follow someone else doing something comparable, you can be compromised. But there is no "Bitcoin software central authority". When you can have any number of "central authorities" and users are free to choose to become their own such authority if none of the existing authorities meet their requirements, you actually don't have a central authority.

But, of course, you can't just run any code and expect to remain secure.

[oakpacific]

Hmmm, so instead of work, sheer numbers matter right? Our botnet operating Russian friends will be very pleased I guess...

No, of course not. You actually have to convince human beings that public keys are controlled by organizations that cannot collude. And all that happens if they do is that the network does not reach consensus and those who betrayed this trust have done so provably with cryptographic signatures. So any trust in them can be removed and the problem solved and the attacker has to start over. Which is better -- an attacker just needs money and can double spend and then the system is broken or an attacker needs to build human trust and then can prevent the network from operating and then the attacker has to start over from scratch?

LOL, what human trust do I need to build? Just validating reasonable transactions from other gateways automatically and being trusted by my bots will make me a gateway that has a say in the "supermajority network consensus" after some time.

He will soon. If his trusted validators are disconnected from the majority, they will report this, and he will know the network is partitioned. (This isn't implemented on the live network yet, it is still being tested. It's needed to support trustless clients.)

That is to say when partitioning is not resolved, availability will be gone, so instant transaction is only available as long as most of the major trusted validators on the network are connected to each other, I am not sure if I can call it "reliable".

The same is true of Bitcoin. If you are not reliably connected to 51% of the hashing power, no number of confirmations is sufficient. The difference is, with Ripple it's possible to reliably tell if you are or are not connected.

There is a very big difference between partitioning between you, a user, and the rest of the network, and  the partitioning of the rest of the network, (especially the major miners), to maintain your connection is way easier than trying to make sure the whole network is well connected, in Bitcoin, only the former case matters, in Ripple, the latter case matters too, or even more, that's why I doubt the claim of "reliable instant transaction" very strongly. Besides, even if my Bitcoin node is completely isolated, it still costs much more to convince me, if I demand to see a sufficient number of confirmations, as long as I remember how many zeros I should expect to see in each newly mined block, a significant hashrate drop by more than 50% is also very detectable, and should make any sensible merchant suspicious. Ripple actually doesn't seem to fare much better on the detection of the former case either: if you don't keep record of every validator which has a long history of honest validations from time to time(kindly enlighten me if you have some better algorithms), you can't detect if the partitioning takes place because the supermajority you are seeing could just be "phantom validators" operated by a botnet, while with Bitcoin, all you need to know is a number: the hashrate.