Topic: Ripple SOUNDS nice but there are some MAJOR problems - page 3. (Read 7072 times)

I get that bitcoin could profit from this but not how we're supposed to get XRP in the first place?!

Also, this consensus ledger thingy; I don't get that either. If you only use the latest hash of the total sum of ledgers, won't the system be weak to 51% attacks?

Maybe try looking at it from a merchant's point of view. They pay 2% to take credit cards. That's equivalent to losing 7 days gross revenue a year.

I don't see the connection you see between personal credit and exchanges. Perhaps you're not aware how complex, expensive, and slow cross-currency payments currently are. It's a huge real-world problem. There's a similar problem with remittances. Maybe you don't have any problems it solves, but there are plenty of people who do.

And, long term, I think personal credit may revolutionize money.

They don't have to use its full capabilities from the beginning. It just has to do something important better than they can currently get it done.

That's not my intention. I really just don't understand the benefits of Ripple if you're not focusing on the personal credit side. I can see applications for currency exchange if you focus on personal credit, if you can solve the bootstrapping problem, frankly because that can effectively bypass the regulatory barriers that hamper a the existing fiat-bitcoin interfaces. If you don't do that, I don't see how those same barriers won't just result in those companies either not using Ripple, or not using its full capabilities.

Right, but that only works if you want Bitcoin on one end of the transfer -- though you don't get instantaneous competitive exchange rates and you're reliant on a system that isn't open source, does have central authorities, can arbitrarily freeze your account, and so on. There's always a risk that the fiat ends of the transactions will be reversed, so you have to pay someone to take that risk. You also can only store value in Bitcoins, which is not such a bad idea right now, but it may not always be that way. If you use it for a cross-currency transaction (say dollars to Euros), you get hit with a commission on both exchanges too.

This conversation is making me uncomfortable because I feel like you're forcing me to unfairly criticize Bitcoin by unfairly criticizing Ripple. For Bitcoin to succeed and thrive, people need to accept Bitcoins as a means of exchange. Once Bitcoin inbound gateways are working, you'll be able to pay any merchant who takes fiat currencies in the Ripple system with Bitcoins, they'll get dollars in their account, and you'll get competitive exchange rates with no commission on the exchange.

Bitcoin payment processors and exchanges do though.

Bitcoin doesn't allow people to pay each other in fiat currencies or across currencies. If you wish to transact only in Bitcoins, then I agree with you, about all Ripple offers is community credit. Think of Ripple as a way to make dollars more like Bitcoins. (With both the advantages and disadvantages that entails.)

In that case I don't understand what problem you're solving. Personal credit seems to be the only innovation Ripple brings to the table because the others are already being solved by Bitcoin.

That's what gateways are for. A gateway is a company who enters into "redeem on demand" agreements with large numbers of people. They serve as gateways to get money into and out of the system. As soon as enough people hold IOUs from more than one gateway and are indifferent to which gateway's IOUs they hold (or arbitragers provide liquidity at a profit), then most paths will be user->gateway->intermediary->gateway->user.

All I can say is wait and see.

We don't see personal credit as a major application for Ripple in the short term. We see it more as a competitor to things like credit cards and services like PayPal. I agree that community credit is hard to use and understand, but I personally believe that in the long term, it could revolutionize money.

Just decide how many lunches you want to allow each coworker to owe you. When someone buys you lunch, you pay them one lunch. They now either hold a "1 lunch" IOU from you or you've destroyed an IOU they held from you. If I owed you a lunch and someone owed me a lunch, you could take that IOU from me in payment and use it to get someone else to buy you lunch.

Yes. They would have to allow you to owe them $20 on the Ripple system, and then you would pay them $20 (in your own IOUs). They would then consider the $20 debt novated by the IOUs in the Ripple system. (God bless you! I've been looking for an excuse to use the word "novated" for more than two years now.)

We're planning to begin giving away XRP shortly. We're currently releasing them slowly to manage load and use as we work through deployment and scaling issues. Stay tuned.

I'm with justusranvier: trading debt isn't nearly as useful or valuable as what bitcoin offers.

Ripple may have a nice rise but I predict it will succumb to a bubble once the initial enthusiasm wears off.

The basic concept of trading debt along a social network graph seems straightforward enough to me, but I have difficulty seeing how it will actually work in practice. This could be because I lack imagination in this area or because the idea has major problems; I'm open to both possibilities. These are some of the questions that came up for me after experimenting with the site for a while:

At first glance it doesn't look like Ripple is useful at all until a critical mass of users sign up and assign trust. How do you bootstrap the network especially since the concept seems to be even harder to explain than Bitcoin? Have existing major players in bitcoin commerce already bought in to the concept and plan to use Ripple as soon as it's ready? In terms of actual usage Ripple most closely reminds me of #bitcoin-otc or localbitcoins.com. Is Ripple a replacement for, or an enhancement to these services? Are there any plans to link Ripple to them in any way so that existing trust relationships could be incorporated somehow and/or Ripple data exported to them?

Can you document somewhere how Ripple can be used in situations that people are already familiar with so that it's easier to understand how the concept can be expanded to more advanced transactions? For example, how could a group of coworkers use Ripple to keep track of whose turn it is to buy lunch?

Let's say I owe a friend $20 due to some pre-Ripple interaction. Once we both get accounts, is there any way to import this existing IOU into the Ripple ledger?

Finally, why is it so difficult to find out where to get XRP? I only managed to be able to use my Ripple wallet because I was lucky enough to find someone in #bitcoin-otc who would sell me a small amount. I don't have enough to give to some friends to test out the concept and I can't find out where to get more.

Yes. It's an outline.

I'm not sure I follow you. If you want more details, I can provide them. The basic idea is very simple -- a node looks at how long the consensus process has in progress compares to how long the previous consensus round took and adjusts the threshold for a yes vote up from 50% based on that time period.

It's a summary description of a lot of things, for example, no votes on transactions are implicit, you just don't vote yes on them. And, as I mentioned above, nodes increase the number of nodes they require to vote yes to keep their own vote at yes oevr time.

Actually, that's still being adjusted. The current algorithm is as follows:

1) Until 50% of the time the previous ledger's consensus took has passed, 50%.

3) From 50%-85% of the time the previous ledger's consensus took, 65%.

4) From 85%-200%, 70%.

5) From 200% on, 95%.

That is, initially, if 50% of your weighted trust list (including yourself, if you believe you are synchronized) votes "yes" on a transaction, you vote yes on it. Once 50% of the time the previous consensus process took has passed, this goes up to 65%.

A two second minimum is enforced on a consensus round to ensure that well connected nodes have enough time to get an initial proposal in. In addition, nodes won't let a consensus close significantly more quickly than the previous round, for the same reason.

This algorithm actually is about to be adjusted. It has a slight defect  -- the first round of dispute resolution could occur after 85% of the time the previous round took has passed, resulting in transactions getting excluded without reason. Though harmless, this effect wasn't intended. Most likely, it will instead slide gradually up rather than in steps.

There is no harm in conflicting transactions both getting voted in -- a deterministic algorithm ensures only one of them will actually get applied and nodes will agree on which. The same applies if two conflicting transactions each bump each other out -- a deterministic algorithm determines which one all honest nodes will vote yes on in the next round.

Do you realize that this explanation is rather lacking? Saying "nodes have an internal bias that increases over time towards excluding a transaction" offers no clear insights in writing out an outline of the algorithm. Compare your explanation with an excerpt from the original Bitcoin paper:


Perhaps you could provide an outline similar to the one from the Bitcoin paper that provides a step by step explanation. You said "the entire system has a huge bias towards excluding a transaction" - what does that even mean, in formal terms? What's this "agreement rate" and what is the algorithm for increasing it? Does it go up by 10% each time?

Where's the beef!

Then one node will raise the agreement rate and the other won't. It doesn't particularly matter. The ratcheting up of the agreement rate is only to keep the rate from "puttering" around 50%. If we just used strict majority, and the starting position was about half the nodes saying yes and half no (say because a transaction was introduced just as the ledger closed), you could stall around 50% for a long time, some nodes seeing say 53% and some 46%. To prevent this, nodes have an internal bias that increases over time towards excluding a transaction. This prevents the long stall.

Essentially, the entire system has a huge bias towards excluding a transaction. So long as a transaction remains valid, every honest node that saw it before a consensus window starts will try to include it in that consensus window. So unless the network is heavily overloaded or most nodes trust mostly dishonest nodes, the transaction will get in during  the next consensus window anyway.

This is the key trick to the way our system works. If a transaction should unambiguously no questions asked get in, then every honest node will vote yes on it. If it shouldn't unambiguously no questions asked get in, then nobody particularly cares whether it gets in or not, and not letting it in is perfectly fine. If enough nodes disagree about a transaction for it to stall the consensus process, then honest nodes just switch to no. They value consensus over getting in a transaction that lots of trusted nodes think doesn't belong.

Any node can introduce into its consensus set a transaction to raise or lower the transaction fee. I think we have a rule that only certain ledgers (like one every 256) can have a fee change transaction in them. This is to prevent needless momentary disagreement on every ledger while some nodes want one fee and some another. A fee change transaction either gets voted into the consensus set or it doesn't. If it gets voted in, it is applied and the fees change from that point on.

The current server just votes no on all transaction fee changes. We plan to add a configuration element to set what you think the fees should be and then your server will introduce and vote yes on transactions to change the fee to the fee you set.

We also have a mechanism, I forget whether it's implemented for fee changes specifically, where a node can introduce into specific validations what it thinks the fee should be. This also is done on specific "flag" ledgers. So on flag ledger X, you can put in your validation that you think the fee should be Y. Then on ledger X+2, everyone looks at the validations for the flag ledger to see if there's a super-majority for fee changes. This also helps to void a needless momentary disagreement and it allows nodes to use a more sophisticated algorithm to decide what fee to propose Say the fee is 10, and you think it should be 12, and half your weighted trust wants 11 and half wants 12, you might want to vote yes on 11.

What if one node believes the avalanche has stalled, but another node doesn't?

Where's the part where base_fee is negotiated up or down and finally changed?

Feel free to ask any specific questions. I thought I already pointed you to where the consensus process is explained in the wiki.

It's basically this:

1) Nodes announce the hash of the last closed ledger. To keep things simple, I'll assume we start from a consensus.

2) Nodes propose the hash of the tree of transactions they think should be applied to the ledger in this consensus window.

3) Nodes acquire the transactions other nodes have proposed.

4) Nodes form disputed transaction entries for transactions so long as at least one node they trust included that transaction and one didn't.

5) Nodes avalanche to a consensus on each disputed transaction by going with the majority weighted based on their trust.

6) If avalanche stalls, the agreement rate requires to get a transaction into the consensus set is raised.

7) As nodes detect that the nodes they trust have reached a consensus, they apply the consensus transaction set and publish a validation of the next ledger.

8 ) Validations push other nodes towards consensus.

9) Nodes acquire sufficient validations from other nodes they trust of the new ledger and consider that the next accepted ledger.

10) If any new transactions occurred during the consensus process or any valid transactions didn't get in, a new consensus process starts immediately.

This trust is just trust not to collude. See the wiki page on consensus.

The main reason it works is:

1) Every honest node wants a consensus. They will wait as long as it takes in order to get one. We have no fixed amount of time in which a consensus must be reached.

2) There is no moving target during a consensus window. With respect to establishing that consensus, the world is frozen. There is a fixed amount of information to be known about the state, and more information is always gathered by nodes. They don't forget anything. The ratcheting up of the agreement level required ensures a consensus will eventually be reached.

3) Dishonest nodes cannot stop transactions from propagating to the vast majority of honest nodes. A node would have to have every single one of its connections to a dishonest node. (And we imagine 'core' nodes agreeing to directly connect to each other as a safety.)

4) So long as a transaction can be applied to the ledger and the vast majority of nodes see it before the consensus window, there's nothing dishonest nodes can do to stop honest nodes from including it. (Nodes will extend the consensus window if they aren't getting votes or acquiring transaction sets from trusted nodes that have voted.)

5) If a transaction does not get into a consensus set, but is valid, every honest node that has seen that transaction will vote to include it in the next consensus set.

6) No honest node particularly cares what's in the consensus set, provided it includes transactions that were seen well before the consensus window started. There is no way a dishonest party could get something into the transaction set that shouldn't be there and have that cause any harm. Invalid transactions will have no effect, even if they get in the consensus set.

I'd be happy to answer any further questions you have.

Now this is exactly what I am talking about. You go and claim this enormous feature, and there is no algorithm given.

You're saying that you have already implemented a secure system for generalized decentralized consensus and deployed it to Ripple? I find that extremely difficult to believe. Claims like this are abundant throughout the Ripple framework. But there is a dearth of explanation.

OP is totally wrong.  Ripple doesn't even sound nice.

The cost of transactions is managed by consensus much the same way as which transactions get into the ledger is managed by consensus. The system has a 'base_fee' that all other fees and reserves are based on. A node can introduce a transaction to change the base fee. If a trust-weighted majority of nodes vote "yes" on the transaction, it will be incorporated into the ledger and the fee will be changed.

Even without this, if there's a consensus that the transaction fee is too high, nodes could just propagate and vote "yes" on transactions with lower fees.

Destruction of RXP for each transaction is bad economics. The number of transactions will continually decrease since the supply of RXP will continuously decrease, meaning RXP value will increase. People will begin to value their RXP more than they value their transactions, so the RXP fee per transaction will have to be manually adjusted to get people making transactions again. Ultimately what you will have is an economy dependent entirely upon a centrally-managed currency. It's exactly the opposite problem of inflationism in the real world.

To fill the donut hole, we need reliable gateways. If we don't have that, you're absolutely right, it's not usable for medium-sized transactions denominated in fiat currencies. (At least not without real community credit which, if it ever happens, is certainly far off.) We have a lot of things built into the system to encourage the creation of reliable gateways, we'll see if it works.

As for the benefits of Ripple versus something like PayPal, see the list I posted previously. Key advantages are lower fees, cross-currency transactions, the inability of a single entity to freeze your funds, higher speed, no chargebacks, the ability to easily change who handles your money without changing payment arrangements, and so on.

The big advantage of Ripple here, I hope, is competition. It would be like if you could choose PayPal and I could choose Dwolla and we could still pay each other seamlessly, with me putting money into Dwolla and you pulling money out of PayPal. We could choose the service that best covers our needs or our location. And if PayPal decides they have a problem with me because someone stole my identity a decade ago and they give me a lifetime ban (long story), I can move my business to another service without disruption.