Topic: Ripple or Bitcoin - page 51. (Read 34110 times)

Ripple will be just as decentralised as Bitcoin. The protocol is already as decentralised, but currently all servers are owned by OpenCoin and its partners. That will change once the server is released and open-sourced. They will have to do this, or few people will trust the system.

Battle between a centralized virtual currency and a decentralized virtual currency
Which one will win only time will tell
Possibility of both winning and existing in tandem just as likely as well

Ripple is an innovative banking system.  As such, even if it were perfect technically, it is completely unknown how such an inclusive system will turn out to work AS A BANKING SYSTEM, with all the risks thereto pertaining.  Kudos to the creators for letting us find out.

If I ran a bank, I would not welcome competition that put pressure on prices for money transfers and currency exchanges.  However, those are pretty small revenue sources for banks.  Won't they just match the low price?

Bitcoin, on the other hand, is a technical solution to a problem that it turned out is susceptible in its totality to such a solution, namely, digital cash.

If Coke is USD, and Pepsi is EUR, then Bitcoin is New Coke and Ripple is a system of tubes that sprays any liquid you want to deliver into your friends' mouths. XRP would be the pressurized air that runs this system of tubes; you can trade bottles of this pressurized air but you can't drink it, only use it to send liquids throught the tubes. And you'd only let those you trust pour things into your mouth over the internet, so if you want give some raw milk to a friend of a friend in Japan, you pour the raw milk into the mouth of a mutual friend that you both trust, and he'll forward the raw milk to the guy in Japan. Excelsior!

Less than viable investment or protocol, or so it appears at the moment.

Let me start out by point out that someone will have to do an enormous amount of work to control any significant fraction of many people's trust lists. And as soon as they even try to misuse this, as soon as people can act, they will be removed from those lists. (In some cases, that can even be automated.) And they will have very little to show for their effort.

But if you imagine moving far from anything sane towards the absurd, as you increase the poor topology of peoples' validator lists and the number of corrupt validators and how many people trust them, their potential for harm goes from slowing consensus to stopping consensus to causing ledgers to diverge. However, if the validators you trust have diverged, you will know it. In that case, it's basically as if they could stop consensus, because you wouldn't know which side of the fork to trust so in practice couldn't trust either.

You don't have to let them. You don't need a consensus or agreement to know the past. And you can refuse to switch to a ledger no matter how many validators sign it if they can't provide the transactions to get from whatever ledger you've accepted to whatever ledger they claim.

There's something of a tradeoff here. For example, say your server has been shut off for a day for some reason and then you start it up. To ensure there are no double spends and no rewriting of account balances, you'd have to perform every transaction before you did anything else. If you didn't bother with that check, you could just jump to the ledger they're claiming is correct (and fetch history later if you still wanted it). That would mean though that you would begin operation before you knew if they hadn't changed some ledger entry without a correct corresponding transaction.

I think there's merit to both approaches. Probably what it will end up being, by default, is to jump ledgers if you were down for "too long" and do a full validation if you weren't down for very long. This will protect you from everything but happening to be down for a long time while someone takes over the Ripple network and it will still allow you start back up quickly and fill in history lazily.

The paranoid can always demand a path of signed and checked transactions be provided to get from a ledger they've accepted as valid to the claimed valid ledger.

You should be more explicit in defining usability.

From what I have read so far, you mean to say that the worst that a conspirator can do is cause ledgers to stop being closed, leaving the state stuck at whatever the last closed ledger is until a manual process intervenes. Attackers cannot rewrite account balances or perform double spends. (?)

There are a lot of ways you could potentially know that they won't conspire. Remember, the end result of them conspiring is basically that they make the Ripple network unusable. So you can pick people who have no rational reason to conspire to make the Ripple network unusable.

We imagine the primary way people will choose validators will probably be, at least initially, by domain. So you can pick the domains of entities that you know have an interest in keeping Ripple running reliably.

I can also imagine organizations formed to maintain lists of validators and verify their identity.

Generally, you should try to add things to your list rather than not. It might increase the chance that you can be duped into finding your server not working, but it ensures that if there is a ledger split, you will know it. You also want to choose validators who also choose their validators wisely. That way, knowing that they declare the network stable and that you agree with them carries more meaning.

The algorithm is remarkably forgiving, stunningly so. When I first started simulating it, I genuinely expected that you would need significant list overlap for the algorithm to be stable, and I expected a small number of malicious attackers to render it unstable. The truth is quite the reverse. It's remarkably stable because if the algorithm detects any instability, everyone just immediately switches to voting no on any transactions not assured approval. (This causes no harm because any fully valid transactions just go in the next set.)

It works, unless the majority is conspiring and dishonest, because every honest node wants it to.

Also, I should point out that dishonest and untrustworthy does not mean conspiring. I don't trust the government of the State of Israel, I don't trust North Korea, and I don't trust Al Qaeda, but I'd add all three of these to my "trust not to conspire" list because they're very hard to conspire with.

Though it's not in the code currently, it's not too hard to measure validator quality. So if a particular validator is consistently delaying consensus or validating wrong ledgers, you can automatically reduce their dynamic trust. When we observe how the network really operates after it's decentralized, we can add features like that.

BTC has already won the race, it is the first, most widely supported online store of wealth by virtue of its mathematical security and limited inflation.

I expect Ripple and many other online currency type options will be much better suited for day to day purchases than BTC

A digital currency suited to being an online store of wealth looks like BTC.
A digital currency suited for day to day purchases looks different, faster confirmation times, and more inflationary to prevent hoarding.

A main problem now is converting fiat to BTC and vice versa, but as long as BTC is convertible to whatever the most popular digital future transaction method is, say Ripple, then this problem is eliminated.

I mean, there is a statistical analysis to make about this "trust a set of servers not to conspire against me" concept.  Has it been done?

Let's say there are 100 servers and people are requested to select at least 10 servers.

Among the 100 servers, there might be 10 of them that are actually secretly controlled by a super-villain.     He plans on the odds of a user picking exactly his ten servers in his list.

What are those odds?  If a user picks 10 servers randomly out of the 100 servers, there are 456440 ways to do that.

Doesn't that mean that the super-villain can screw one user out of 456440?  If there are a large number of users, this number might not be negligible.

Now, I picked some random numbers, but the generic case should be studied.  One should wonder what proportion of the total number of servers a villain should control in order to be able to screw a given proportion of users randomly selecting a list of servers.

How can I know about which servers will not conspire?  I can just make a wild guess but unless I know people who run them IRL or something, I have no clue.  Maybe lots of servers really want to screw the system and will actually conspire.

@ JoelKatz : Thanks, this is a really thorough explanation. Sorry again, i was supposed to read the specifications first instead of asking on a public forum. I'm sure other people are as lazy as i am though, and you will have to convince them too.

Straight away, and with my limited knowledge of how Bitcoin or Ripple works, I have to say that i don't know if you will find a fixed point (stability) in your consensus dynamics. If you do, it will be more complicated than with Bitcoin. If you don't, it doesn't matter that much anyway since you will be able to fix this with a bit of centralization. In any case, people might say your spec is less perfect than Bitcoin, although your system does have nice properties too that Bitcoin doesn't have.

Bitcoin has the "stability property" and it's quite simple to prove, what i mean is that people with majority computing power are incentivized to follow the original algorithm, because that's the one that maximizes returns for them. Hence limiting the potential for divergence and mis-behaving peers. The current mining and transaction behavior, fees, etc. , is a stable point.

My feeling is that your hardest problem to tackle will be how to prevent DOSes attacks coming from sybil attacks, and that it will make your algorithm very complicated once you address all the different scenarios.

Anyway, nice project, now my turn to read all these papers properly.


EDIT: by the way, i'm the designer of a rather large and well known proprietary P2P network (not sure if it's wise to put the name in my signature), that's how i started being interested in Bitcoin a couple of weeks ago.

In the near future, if you're running the standalone client and not running a server, you'll be able to select a list of servers to use. Currently, the client trusts the server for pretty much everything except forming and signing transactions (so your private keys never go to the server).

The protocol is designed so that the client doesn't have to trust the server to tell it which transactions have cleared or what their balances are. But currently the client does trust the server to report this information. In the future, if the client is enhanced not to trust the server in this way, it will need its own list of nodes it's willing to trust to sign a statement of which ledger is the valid, last closed ledger. Validators already issue this signed statement every time a new last closed ledger is produced. So a client that doesn't trust the server would also need a list of validators whose signed statements of the hash of the last closed ledger it was willing to trust.

The client would operate like this:

1) The client gives the server a list of validators it trusts.

2) The server tells the client the hash of the last closed ledger and a collection of validations for that ledger from the client's list of ones it trusts.

3) The client verifies the signatures on the validations and then it knows the hash of the last closed ledger.

4) The client can now determine if transactions have cleared, determine current balances, see offers and order books, and so on just by walking hash chains from the ledger's root hash. No further trust is needed. All the client needs to do is say to the server "I need the object that has this hash" and it can walk to past ledgers, past transactions, account histories, and so on. (And it can query different servers or even future nodes whose sole purpose is to retrieve data by hash, taking pressure off the network.)

The ledger was carefully designed to be sufficiently self-descriptive that it can be "walked" in this way.

We must pick a set of servers, not just regular users only running the client, right?

Trust that they won't conspire against you, yes.

It's hard to say who really has the decision power of Bitcoin. Is it the key developers? Is it the miners? Is it the exchanges? Is it the community that has to agree on changes? Probably, it's a combination. However, you do have to trust that the people with 51% of the mining power won't conspire against you. And you have no control over who that will be.

The way Ripple works, servers come to a consensus about what order to apply transactions. Basically everything else is subject to deterministic rules. As long as everyone agrees on the ordering of transactions, there's no double-spend problem. If transactions conflict, the first one wins.

Server operators set in their servers who they wish to come to a consensus with. A ledger split in Ripple would be the equivalent problem of a blockchain fork in Bitcoin. So it's important that you try to come to a consensus with other major Ripple players. The math is very forgiving because everyone's main priority (after ensuring that the deterministic rules are followed) is coming to a consensus.

We think this is superior to Bitcoin's proof of work algorithm for three fundamental reasons:

1) While they both require you to rely on other people to make the system work, Ripple lets you choose who to come to a consensus with. You aren't stuck with whoever has the most hashing power. If you pick people in Ripple who misbehave you can simply stop listening to them.

2) Everything validators do is signed with the key by which you can decide to add them to your list of nodes you try to come to a consensus with. So if they misbehave in any way, it will be provable via, say, conflicting signed statements or incorrect signed statements that disagree with everyone else. So you'll have to behave until you get your one chance to attack and that that will be that, you'll be back to square one.

3) The worst case failure should be much less severe. With Bitcoin, the worst case failure is constant double spend attacks and requiring more and more confirmations to rely on a transaction. With Ripple, the worst case failure (that an outside attacker can cause for you, I'm assuming your own trust list isn't massively broken) should be a denial of service attack. You'll see that the nodes you need to come to a consensus with don't agree with each other, and you'll know the network can't reliably resolve disputes. The network could be frozen until it is manually fixed. With Bitcoin, you can't tell what block chain mining pools are building on. If there's a fork, you wouldn't know it. It will take manual intervention to know there's a problem

And while this isn't a major reason, it's also interesting that, while being a trusted validator doesn't give you any superior access to the Ripple network, it does give you a say in which new features are added and which aren't. Ripple has a well-defined change process, and consensus is used to enable new feature sets. If a widely trusted validators votes for a feature (or vetos it) that will carry weight in proportion to how many node lists they're on and how influential in turn those nodes are.

Of course, Bitcoin's algorithm is proven and ours is not yet. I'm convinced it's fundamentally sound. But subtle defects or bugs may manifest, of course. We may have growing pains, scaling problems, and the like. I'm confident we'll be able to fix any such problems, and we have an amazing team, but there's no 100% guarantees here.

So correct me if i'm wrong, but, to sum up, people in power in the Ripple consensus system are the people with money and/or trust?
As opposed to Bitcoin where the decision power is hold by the people with computing power.
Sorry if my question is naive, I'm new here and haven't read either Ripple or Bitcoin specification fully (i know, i know). But i'm supposed to be able to understand these protocols quite easily.

We discourage it by having a reserve of XRP that is locked to the account. But obviously we have no say over who opens accounts.

How do they prevent people from creating, say 1 million Ripple addresses?
I mean, without asking for personal information. I don't think it's possible.

you mostly have everything in one account or Ripple address, you can't create any arbitrary number of them like in Bitcoin. Theoretically possible, but costly and very inconvenient. It's basically part of their security model that you can't do it so easily.

Ripple has the same level of anonymity as Bitcoin.