Why Ripple™ is against everything Bitcoin

[SGExodus]

The only people that are advocating Ripple are those that have received large amount of free XRP, and are trying to scam the rest into buying them at inflated rate.

I have a feeling that it's vice versa: most of the people who are claiming that Ripple is scam are those who want to buy large amount of XRP, and are trying to scam the rest into selling them at a low rate.

Why the hell would anyone speculate on XRP at all?   It's just like postage stamp for sending a mail.  Sure, it may appreciate in the next 100 years, but only retards try to buy/sell stamps above face value now.

[1715302531]

1715302531

[1715302531]

1715302531

[1715302531]

1715302531

[1715302531]

1715302531

[🏰 TradeFortress 🏰]

Good luck to those idiot VCs who put in their money based on how little information Ripple had published.  

Yeah, sure. Google Ventures and IDG’s investment are idiot VCs and invested after 15 minutes of reading ripple.com/wiki. They should have read this thread before. Stupid capitalists.

VCs are not always (or generally) right:

http://www.quora.com/Venture-Capital/Why-dont-VCs-list-their-failed-investments-on-their-websites

http://www.forbes.com/sites/ericjackson/2011/12/14/top-ten-reasons-why-vc-backed-companies-fail/

[lexxus]

By the use of vice versa, you're thinking people who think Ripple are a scam are advocating Ripple?

I would say it is a great tactic to buy XRP as low as possible if you believe in it's store value.

[lexxus]

VCs are not always (or generally) right

Sure. Nobody doubts that. This is why it's called venture capital. However, VC is not synonym for "free money".

[SGExodus]

Good luck to those idiot VCs who put in their money based on how little information Ripple had published.  

Yeah, sure. Google Ventures and IDG’s investment are idiot VCs and invested after 15 minutes of reading ripple.com/wiki. They should have read this thread before. Stupid capitalists.

You think too highly of them.  They just throwing money all over and hope to hit a gold mine someday.

VCs lose money all the time.    It's easy to make retarded decision when it's not their own money at stake.

[oakpacific]

https://ripple.com/wiki/Network_splits

I seriously doubt if they have solved the Byzantine Generals Problem.

[🏰 TradeFortress 🏰]

https://ripple.com/wiki/Network_splits

I seriously doubt if they have solved the Byzantine Generals Problem.

LOL, I love this:

Note: There is currently no way to tell if you are in the network minority. This feature is coming.

[JoelKatz]

https://ripple.com/wiki/Network_splits

I seriously doubt if they have solved the Byzantine Generals Problem.

LOL, I love this:

Note: There is currently no way to tell if you are in the network minority. This feature is coming.

It's actually trivial -- if there are, say, 1,000 generally trusted validators and you see validation from fewer than 700 of them, you might be in the minority. This has been implemented in the server about a month ago, the wiki is just out of date. The results of the Ripple consensus process are never sent to clients directly as verified. The ledger must pass a "validation gate" before it's considered confirmed and this validation gate will never be passed if you're in the minority because you won't get back sufficient validations.

In contrast, if you're in the minority, you won't know until manual intervention with Bitcoin. If the world splits (as it did recently) people who are on the minority blockchain have no way to know that they are transacting on a block chain the rest of the world does not think is the longest chain. At best, you could statistically infer you were in the minority eventually based on blocks being found too slowly.

Bitcoin could adopt the method Ripple uses to solve this problem. Major mining pools could periodically broadcast a signed object stating the hash of the tip of the blockchain they are currently building on. You could then know if you were in the minority.

[mmeijeri]

It's actually trivial -- if there are, say, 1,000 generally trusted validators and you see validation from fewer than 700 of them, you might be in the minority.

Can you give some more details on the consensus process? I've studied the material on the wiki and some clarifications you've given on other forums, but it still isn't completely clear to me. I understand that whenever a node detects that the network has reached the 80% consensus level it will somehow try to declare the new ledger closed. Does it then wait for 100% of the nodes on its UNL to concur or just 50%? If the latter, I don't understand how this could mean "fully validated" or "mathematical certainty".

[misterbigg]

The Ripple wiki is very rough; there are plenty of spots that need to be filled in with more data.

The Ripple protocol, server, and client software are also very complicated. There are many more moving parts. Unlike Bitcoin, Ripple cannot be so easily described in a ten page research paper. Correspondingly, it does a tremendous amount more.

The Ripple guys are primarily developers / cryptography "nerds" and not marketeers. The software could definitely have been presented better. The giveaways could have been handled differently. This having been said, I prefer that their efforts are squarely focused on developing a solid and robust product instead of worrying about what the Marxist Bitcoin Peanut Gallery thinks about it.

[JoelKatz]

Can you give some more details on the consensus process? I've studied the material on the wiki and some clarifications you've given on other forums, but it still isn't completely clear to me. I understand that whenever a node detects that the network has reached the 80% consensus level it will somehow try to declare the new ledger closed. Does it then wait for 100% of the nodes on its UNL to concur or just 50%? If the latter, I don't understand how this could mean "fully validated" or "mathematical certainty".

When the consensus reaches the 80% level, the node stops trying to reach a consensus on that particular set and computes the next ledger assuming everyone else has reached the same conclusion. Someone has to do this first or nobody will ever do it, and the person who does it first can't know for sure that everyone else will do it. This strikes a balance between not taking infinitely long to assure a consensus and not thinking you have a consensus when you don't all the time. At that point, the server moves on and tries to get a consensus on the next ledger assuming that it was correct and everything will work out fine. Basically, the server uses the consensus process to decide which ledgers to validate itself.

Additionally, the server has a "validation gate". This tracks the point in the ledger chain that the server considers fully validated. This is what it reports to clients. To pass the validation gate, ledgers must be validated by other servers. The server has a "validation quorum" that should be slightly more than half the number of validators it trusts. The server listens for validations and allows ledgers to pass the validation gate if they have sufficient validations. A server will do this whether or not it is itself publishing validations.

Once can prove mathematically that theoretically you can go on forever without ever having a consensus. But it's like flipping a coin until it comes up heads. While one cannot place a finite bound on the amount of time it will take, this presents no practical obstacle to actually doing it consistently in a reasonable amount of time.

[mmeijeri]

OK, I thought that the algorithm switched from exchanging and combining proposals, thus implicitly voting on individual transactions, to up or down votes on whole ledgers and waiting for unanimity among its UNL nodes. If I'm understanding you correctly, what it in fact does, is merely to stop seeking a consensus at that point, and to publish a single validated and signed ledger. What happens if it subsequently detects that others on its UNL have signed conflicting ledgers?

[JoelKatz]

If I'm understanding you correctly, what it in fact does, is merely to stop seeking a consensus at that point, and to publish a single validated and signed ledger.

Correct.

What happens if it subsequently detects that others on its UNL have signed conflicting ledgers?

Currently, it treats its own validation as no different from any other validation. If no ledger gets a clear majority, then it won't consider any new ledgers as fully validated until one does.

This works perfectly for servers. However, we plan to modify this behavior a little bit primarily to make things easier for clients. Currently, clients trust their server to tell them which ledger is the most recent fully validated ledger. We want clients to not have to trust the server they connect to. Under the current scheme, that would mean the client would need to see a significant number of validations (and check all their signatures) to become convinced that a particular ledger did in fact get a significant majority.

The planned modification would change the logic as follows:

1) When an 80% consensus is reached, the server terminates the consensus process and builds the next ledger.

2) The server issues a "provisional validation" for the ledger it builds as a result of applying the transactions it thinks are in the consensus set. (This would actually be a new form of proposal and not an actual validation. It probably should be called a "final proposal".)

3) The server goes on to the next consensus process.

4) When a ledger receives sufficient provisional validations to convince the server it's the network consensus ledger, the server only then signs a validation.

This would have no effect on the way servers currently determine ledgers are fully validated. However, it would allow clients to become firmly convinced a ledger had majority support without needing a large number of validations. Each validation now conveys much more information -- the server didn't just build the ledger as a result of the consensus process, it acquired confirmation that a significant number of other nodes also terminated their consensus process at the same point.

This would also protect better against a possible class of bugs where servers might somehow agree on the previous ledger and the transaction set and nevertheless somehow build a different ledger as a result. Imagine, for example, some software bug that causes 32-bit code to produce different results from 64-bit code.

This also makes validators routinely make stronger commitments making it harder for them to claim that a deliberate bogus validation was just a result of unusual conditions.

[mmeijeri]

If no ledger gets a clear majority, then it won't consider any new ledgers as fully validated until one does.

So how does it get out of that situation if the consensus process has been stopped? What makes nodes change their mind then?

[JoelKatz]

So how does it get out of that situation if the consensus process has been stopped? What makes nodes change their mind then?

Until there's a clear majority, no transactions will be considered confirmed. We'd rather stop than tell people they can rely on information that's not reliable.

Nodes have an avalanche algorithm to restore the consensus process. Typically, there will be one ledger that at least has a slight majority and the vast majority of nodes on that ledger will stay with it and the vast majority of nodes not on that ledger will switch to it. The result of the next consensus round after that happens will then get fully validated.

[mmeijeri]

Nodes have an avalanche algorithm to restore the consensus process. Typically, there will be one ledger that at least has a slight majority and the vast majority of nodes on that ledger will stay with it and the vast majority of nodes not on that ledger will switch to it. The result of the next consensus round after that happens will then get fully validated.

Can you say more about that avalanche algorithm? Or is it just the process of switching to the majority (or plurality) ledger if there is one? And what does a node do if for whatever reason all of its UNL nodes suddenly endorse a ledger that's on a different branch?

[ihsotas]

The Ripple wiki is very rough; there are plenty of spots that need to be filled in with more data.

The Ripple protocol, server, and client software are also very complicated. There are many more moving parts. Unlike Bitcoin, Ripple cannot be so easily described in a ten page research paper. Correspondingly, it does a tremendous amount more.

The Ripple guys are primarily developers / cryptography "nerds" and not marketeers. The software could definitely have been presented better. The giveaways could have been handled differently. This having been said, I prefer that their efforts are squarely focused on developing a solid and robust product instead of worrying about what the Marxist Bitcoin Peanut Gallery thinks about it.

First of all, that's an insult to Marxists.   

Second, Ripple/OpenCoin doesn't need "marketeers"; they need good technical writers or developers who have experience dealing with non-technical humans like, you know, their parents or their wives. The nice thing about Bitcoin is that there are hierarchical levels of description available for newbies; you can start with a very simple top-level view of what's going on, and then drill-down, filling in gaps along the way, to whatever level of detail you desire (even if you're a crypto expert, or just a developer like me).

In contrast, Ripple's site/wiki/videos have a few vague use cases and then, elsewhere, wiki fragments that touch on conceptually isolated entities.

If you think top notch developers are poor presenters/writers by definition, take a look at anything that Google publishes (from GFS all the way to Spanner). Great thinkers are often great communicators. No one is seeing that from the Ripple team so far, and they're squandering the PR spike from the recent investment rounds.

[hashman]

Bitcoin could adopt the method Ripple uses to solve this problem. Major mining pools could periodically broadcast a signed object stating the hash of the tip of the blockchain they are currently building on. You could then know if you were in the minority.

While we're at it we could get rid of all this finicky barely usable software such as bitcoin-qt or minerd, and just have all users login to bitcoin.org where the decentralized network can be managed in entirety by venture capitalists instead of botnet operators and criminals.  The foundation can then distribute the remaining 8 or 9 million coins as they see fit.  

Then we could trust that the people claiming to be mining pools are really broadcasting valid headers as you suggest, and we could have a list of all of them to check if we are in the majority or not.  

    

[Stampbit]

If i wanted a central bank i'd stick with fiat.

[JoelKatz]

Can you say more about that avalanche algorithm? Or is it just the process of switching to the majority (or plurality) ledger if there is one?

Yes, you switch to the majority valid ledger.

And what does a node do if for whatever reason all of its UNL nodes suddenly endorse a ledger that's on a different branch?

The node basically uses the following algorithm:

1) It switches to the majority of the ledgers it has not rejected. But it does not endorse that ledger.

2) The node tries to determine if that ledger can be endorsed -- determining whether it's a valid following ledger or not.

3) If the node determines the ledger is invalid, it rejects that ledger.

4) While this is going on, the node keeps tabs on any other nodes that have changed their position.

Over time, more and more nodes will veto any invalid ledgers in the mix and soon all honest nodes will be endorsing valid ledgers. The valid ledger with the most endorsements will eventually win.

This doesn't take nearly as long to actually happen as it might sound like. The ledgers will tend to be very, very similar and only differences are analyzed.