Topic: WTF happened to ripple? - page 2. (Read 21828 times)

+1. Excellent summary of the situation.

I find it near impossible to discuss this matter transparently with Joel.

Joel Katz: "I am prohibited from disclosing my opinion about XRP's future value."
(https://bitcointalksearch.org/topic/m.1554983)

This is not a joke, and while some people love to suck up to power authority, most bitcoiners in this forum are smart enough to recognize a rotten egg.

Joel, I recommend to you whole wholeheartedly to either expose your commercial intentions, or commit to altering and democratizing the txn solution at hand; otherwise you will be building a ticking time bomb. You won't end up controlling 50%+ market share but you know what they say: "Power tends to corrupt, and absolute power corrupts absolutely." Don't set yourself up for failure.

From a true open source and decentralized democratized point of view, the idea of centralized txn authority is ridiculous. If this is the "only viable solution" you should either be opening up the platform to multiple fiat currencies so that users can create their own and there is a competitive free market amongst txn fee operators, or define a rock solid democratic distribution plan of all the XRP.

Yet as I find the idea of an unsustainable self destructive txn fee currency a horrible idea akin to building on sand, the focus should be on disconnecting any value system from this txn fee mechanism, and focusing on proof of work as a security measure; or allow the network node operators to have a choice of what currency they prefer be paid as a txn mechanism.

I realize this is a technical challenge but my intention is to open the debate and make sure you are open to change, otherwise I and others will fork our efforts towards bitcoin web of trust enhancement and your "ripple + get rich quick scheme" will bite the dust.

You are clearly smart enough to know that we would realize this "necessary design flaw" as an overly greedy excuse on your part for power and control; therefore your downplaying of the issue leads me to believe your actions are highly strategic and premeditated. If you truly want to succeed with your efforts and with this community your veil of secrecy and prohibited dialog needs to end.

Joel, please do not take my comments as hostile or personal. I really want ripple to succeed, and I'm simply pointing out the elephant in the room.

Credit where credit is due! The following scheme was described by Ben Laurie years ago:

The "central authority" consists of a set of distributed (and preferably independent) servers which keep track of the ledger of balances (a Merkle hash tree) using a Byzantine-fault-tolerant consensus protocol. They enforce constraints on the system (e.g., coin creation and distribution---no need to do it manually or premine) and blacklist dishonest or malfunctioning servers.

All the honest servers will agree to the same transaction log (of course a severe netsplit will stop transactions from committing). The clients need to come preconfigured with a list of servers (which can be updated by the network). So, unless something goes very, very wrong, there is no need for the user to worry about deciding whom servers to trust.

There are clearly some details to fill in to specify a complete implementation, scalability issues, etc., but Laurie's distributed currency uses established ingredients that are mathematically proved to work and gives you transaction confirmation in seconds (no need to "mine"). It could also be used for Bitcoin and other currency transfer/exchange (there seems to be a need for this anyway) as well as more advanced uses.

Now, I indeed remember the original ripple web-of-trust proposal being as gmaxwell described. The "new" system seems to be something else, and I echo people's concerns expressed in this thread and do not see how they have been resolved to any satisfaction. It may be unintentional on the part of the ripple developers, but something seems fishy or opaque about it (at least at this point in time), and it looks like a commercial rather than a community project.

Oh well, next time maybe create a hundred trillion whatzits and give people fifty million each when doing giveaways, maybe instant internet multimillionaires wouldn't be as ungrateful as people who receive handouts of only a puny fifty grand!



-MarkM-

Good one.  I will interpret Joel's _lack_ of disagreement with the previous remark as an implicit agreement :-)

Actually, this says a lot.


I'll do it for you. You're insanely annoyed at the onslaught of newbs who just don't seem to understand that XRPs are not like Bitcoin. And you're frustrated because you can't respond to set them straight, because doing so might make the necessary and difficult bootstrapping process even harder.

Unfortunately, no. I am prohibited from discussing that. Those things that I cannot comment honestly on for any reason, I simply do not discuss. There's nothing I enjoy more than sharing my honest opinions with others, but in this area, I cannot do so.

So, can we get a straight answer?

JoelKatz can I have your personal opinions on the speculation going on with XRP right now (see my example quotes)?

I fully understand that this kind of reasoning has a kind of attractive logic to it, but I think that's an extremely unlikely scenario. I could have made a similar argument in 1950 that people would soon abandon fiat currencies and switch to gold certificates. I can make a similar argument that Bitcoin will make fiat currencies obsolete. Sure, that might be the endgame in the far future, but to focus on that endgame *now*, rather than the many decades of work we have to get there, is navel contemplation.

I have got a similar opinion like OP.

Ripple.com is a mix of Bitcoin-like currency XRP and ripple IOUs. As XRP is more suitable for payments than IOUs, it seems that IOUs would become only a secondary feature, and so it seems unfair to call this system Ripple. The difference from Bitcoin would be no mining, but starting a new server would be more troublesome because the peer has to find some (many?) peers that he would trust not to cheat him, ideally some peers he knows.

How about True Ripple? I can think of a system with just IOUs without XRP. It would also be truly P2P. There wouldn't be the global ledger but just peers transacting with (few) peers they know. All value transfer would be performed using chains of IOU transfers between peers, obviously. To prevent spamming there would be fees for all activities using up resources, like routing a search through a node, or routing a payment through a node. If a node sets fees too high then the traffic would route through someone else eventually. The actual interaction between nodes would need to be somewhat cautious, so the money don't disappear on a half-way, but it seems doable.

Of course it would be currency and with fixed/dwindling supply (after distribution process completes), it would be as good a store of value as bitcoin.  Obviously Joel is just doing the necessary PR to appease the 'premine' outrage.  

If I had such a good PR/image skills I would have my own startup soon  

To paraphrase someone else's post in the forum, one of the intrinsic characteristics of Bitcoin is that every node needs to hear about every transaction. For example, every purchase of a child's popsicle or every microbet on a digital lottery. That's just the way the system works. Another characteristic is that individual nodes do not need to have trust in any other nodes for the system to work.

Ripple solves different problems than Bitcoin, and it seems to me that in exchange for getting decentralized scalability to infinity and multiple currencies, the price is that you have to trust at least one node (among other things). It seems reasonable to also accept that another unique property of Ripple is that, unlike Bitcoin, it must be bootstrapped in a centralized way. There needs to be that initial node of trust (unlike Bitcoin).

It is probably too early to worry about Ripple's current lack of decentralization. Bigger problems are:

1) Confusion over the role of XRPs
2) Lack of mathematical proofs of the security and performance of the system
3) Missing source code

We can't even determine if Ripple can be decentralized until we have answers to the three points above.

I've been willing to set aside the lack of clear technical documentation and trust that the developers have rigorous mathematical proofs for their claims.

But as I have stated over and over again, it seems people are drawing the conclusion that the "Ripple" currency unit (XRP) functions in the same role as the Bitcoin (BTC). Specifically, that it is a store of value. I've been on the Ripple forum and pointed this out to you JoelKatz. People are coming on there saying they "want to buy a lot of Ripples" and I can only conclude that it is because they think that the Ripple will rise in value like the Bitcoin.

From what you've been telling me, this is not the case. But then we have Jed coming on and saying that yes Ripple does function as a unit of currency like Bitcoin. Which one is it? If the people involved with the project cannot even present a consistent description how can we have confidence in the system?

Either Ripples are just a marginally valued, artificially scarce resource designed to make transaction spam prohibitively expensive (in which case, it is being marketed totally the wrong way) or it functions like the Bitcoin as a store of value (in which, the premine rules Ripple out as any sort of legitimate system no matter how much is being given away).

Look at what people on the Ripple forum are saying:

This guy thinks that having XRPs means he has achieved wealth (like having a bunch of Bitcoins)

Conflating XRPs with BTCs:

Thinks Ripple is a "coin"

And it goes on and on.

So what's up? Are XRPs coins, a store of value, like Bitcoin? Or what? Can we please get a straight answer?

It doesn't shut it down. It just refuses the reorg and log the event and tell user about it, and the network is still chugging along. User should be notified so if there was a legitimate network partition event going on, people can notice and start discussion about it.

Of course the concensus mechanism to deal with these partition event would be quite a bit centralized and costly, that's why there needs to be assumption that it rarely happens.

This is the major problem with ripple.  Someone with a botnet can form thousands or tens of thousands of validated nodes and operate them as normal for months on end, then suddenly command them to reject certain transactions as invalid.  It doesn't even have to be a lot of transactions, just small ones that majorly benefit the botnet operator, and this could be performed very easily with no one catching on to it for some time.  You've created a "one IP one vote" system, something that is warned against in the original bitcoin protocol specifications.  If the chain lives long enough we'll all see why.  Sybil attacks are cheap and the threat of them is real.

that means that anyone who can create 100 blocks can shut the network down 'forever'— if that'll never happen, why secure against it?  If you have some consensus method that can easily resolve the shutdown why not use that for your consensus system instead of a PoX hashchain?  ::meh::  It might actually be a prudent sort of thing to do, but I'm skeptical.

There is a reasonable fix for this though, just set a reorg limit say 100 blocks, and prompt for manual intervention from the user. Given a prolonged network partition situation, there would be either a central or democratic procedure to determine the winning branch, via a checkpoint. This assumes that network partition does not happen too often for longer than a day in practice.

Actually this might be the approach ppcoin eventually adopts.

Hmm Joel I don't know if I like your answer here or not, are you saying a split of trust network is fine? I agree with gmaxwell here that your probably need some ensurance that this doesn't happen (at least make it very very unlikely). Network split is very very serious issue.

Another point I didn't get from your description is that what's your assumption on server node availability? Under a peer-to-peer setting a lot of nodes on UNL may have less than ideal availability, so making a 50% rule to solidify the ledger could be problematic. Also you don't know whether they have solidified they could suddenly all change their mind.

All scale-free networks are vulnerable to directed attacks: just go after the most connected nodes. In Bitcoin we have seen successful attacks on major mining pools in order to steal their potential mining profits. Anyway, sure you can detect netsplits, but your high-volume network has still ground to a halt. Similarly you must assume worst-case placement of conspiring nodes. Crossing your fingers and hoping your scheme is robust is not enough...

If they conspire once and that one time someone loses 1 million xrp its a flawed system. After all attackers will be motivated to go after clients who hold large balances.

Yes, I meant trust. Real social graphs have structure like that.  How do you prevent trust structures that will guarantee convergence failure from evolving? How will you manually resolve a loss of convergence from resulting from one?  How can you distinguish one that arose naturally from one created maliciously for plausibly deniable culpability in attacks?

Or more generally— What are the trust topological requirements to prevent failure?  This is the kind of requirement that needs to put into the security assumptions statement.