Bitcoin Forum

I predict one of the two following things will happen:

1) Once OpenCoin releases the source for the Ripple server, we will find a way to fork the project and create a version that does not require XRP to function.

2) OpenCoin will never open source the server, making their claim of decentralization a lie.

Ripple can be a very useful system, allowing rapid payments, trading of IOUs and distributed exchanges. Its main problem is its reliance on XRP, and the company/developers that own the vast majority of them. We HAVE a wealth asset (BTC), and we don't need another one, especially not one with a central bank that controls most of it.

How could you make Ripple work without the XRP? One possibility: per-transaction proof-of-work similar to what's used in BitMessage. If not that, then something else. I have faith in the inventiveness of the developer community.

No as ripple isn't decentralized at all. A single server processes all transactions. Take down the server, take down ripple. Their system doesn't work.

It's not decentralized NOW, because OpenCoin is the only one running servers. But they have clearly stated their long term plan is to open-source the server. The system is definitely designed to be decentralized.

OK. Servers might be decentralized, but if we decided we wanted something changed, could we distribute a patch to 51% of the network and fork the code? If no, it isn't decentralized in the slightest.

Yes, we will be able to do it :)
https://ripple.com/wiki/Consensus

As we haven't seen the code you cannot know that, and at the moment you need to trust a single central agency to have told you the truth about ripple's implementation.

Even if they aren't malicious, you need to trust they succeeded at security by obscurity, and the system won't exhibit critical flaws when (or rather if) open sourced. The chances are slim, as any expert will tell you.

consider that, not only is OpenCoin really closed ClosedCoin for all intents and purposes, but they have also given no indicator as to what open source license they plan to release the code under.  Secondly you also have the issue of patents, which rules out the possibility of forking the way you describe.

XRP serve multiple purposes...

The "transaction fee" aspect might very well be covered by PoW, maybe even the proof of stake/ownership aspect (the "reserve amount" you need to keep on an account).
For the "network internal asset" part however bitcoins are not too useful as they are not tailored towards microtransactions and transactions also take quite long to be finalized.

There might be a market for XRP being mined (maybe for some limited time?) or at least distributed in a different fashion than being distributed by a central authority.
I'm sure that people will release forks with no XRP or other currencies replacing XRP. I doubt though that a system like this would be very useful.

It's still weird that people seem to reduce Ripple to the use of XRP - XRP are a shitty store of wealth and not really useful as a currency. Ripple anyways tries to be something else than Bitcoin, XRP are just a tool amongst many and they are also not required to use the system in any serious quantity (compared to BTC where you HAVE TO own an equivalent ratio to whatever the BTCUSD price is at the moment to buy something from merchants or you can't use the system).

I'm not sure if this thread belongs here though - do you want to have help/ideas in implementing BTC into rippled to replace XRP or do you just want to rant about OpenCoin? In the former case, I'd recommend you to be more explicit in the thread title and OP, otherwise it's very likely that this thread ends up in Alternative Cryptocurrencies.

Do you pay a transaction fee to use email? Do you pay a transaction fee to Jabber? No.

Transaction fees are not necessary in Ripple. Ripple has worked without TX fees for years. Bitcoin cannot work without transaction fees as the supply is fixed, through.

Is Ripple classic a distributed system or do they just have central servers? Who stores the ledger there? Anyways, I'm not too much into Ripple classic and I guess that's also besides the point here.

Bitcoin could work without fees, but then mining would be not paid besides coinbase transactions and it would be only done voluntarily. This would lead to less security probably but higher and more aggressive investments in the early phase, when mining is lucrative. A fixed supply is not a reason to have transaction fees, but I guess fees are generally accepted as being necessary as well as benefitting a certain group of people (Bitcoin: Miners due to reimbursement, OpenCoin Ripple: XRP holders due to deflation). With 0 fees, there need to be other incentives to keep the network up and secure.

Compared to BTC by the way, Ripple fees are negligible. Just loading a Bitcoin client and verifying the last few blocks since I went offline probably already eats up more money in electricity than a Ripple transaction currently costs - so I don't see an urgent need to have PoW attached to Ripple transactions, as this would make them more expensive than a transaction on OpenCoin Ripple with no apparent benefit to me.

I don't know much about ripple classic in practice, but on my scale OpenCoin's centrally held closed source servers are already the worst case, both in trust and security issues. Do you really believe they are immune to greed, governmental meddling, or stupid bugs?

I also don't concur Ripple fees are negligible, since there is a *vast* difference in security and trust in Ripple and Bitcoin. You get what you pay for in this case. Personally I think you get the short end with ripple, the risk exposure in no way justifies low or even zero fees.

And yes I think hashcash pow could be used instead of XRP, it was invented to fight email spam. A single internal reserve currency is not necessary; bitcoin could fill this role de facto, but the dollar might as well, and a true mesh exchange system would be possible too.

Sukrim makes a good analysis and I believe this Ripple XRP is Proof-of-Stake. Open Transactions with Bitcoin will prove far superior though may face unfair regulatory hurdles that TBTF banks do not. Due to the secrecy nature of Opencoin, I suspect their project is a threat to decentralized crypto-currencies and a friend to centralized virtual currencies.

No.
And billions are spent by the operators of the receiving servers to stop the flood of spam that would not be sent if a fee we required to send.

You pay for those operating costs one way or another.

If Opencoin ever does release code, the "server" will be limited or require some sort of lookup/call back/phone home to their own official servers. Ripple will ALWAYS need some form of centralization, because it does not appear that they have solved the double-spend problem.

The only solution to double-spend that we know of is a proof-of-work system. Their system does not appear to use PoW and is doomed-to-fail as a cryptocurrency. Why you guys even post topics about Ripple or try to sign up for free Ripples is simply ridiculous. Wait for them to release a whitepaper detailing how they've solved the double-spend problem without PoW before you even consider wasting time on a currency.

Pretty much every alt-coin is superior to Ripple in every conceivable way because they at least solve the double-spend problem.

They did and there is no need for central servers. https://ripple.com/wiki/Consensus is probably the starting point to read about their solution.

Currently the Client code is released, which is something that you proabbly would consider "calling home" as you can send JSON encoded RPC calls and receive answers from the official public server(s).

Still this is again just starting to derail into a Ripple bashing thread - you can do that elsewhere! As far as I get it the topic is about integrating BTC (or maybe some other existing crypto currency) natively into the OpenCoin Ripple implementation as soon as server code is being released. It is reasonable to expect that this will indeed happen and it also makes sense to think about ways how this could be done already now.

So let's recap, XRP (can) serve as:
* Asset (actually the only asset in Ripple one can own), intended to be used as shortcut/general currency when trading IOUs (USD->XRP->EUR instead of USD->INR->BTN->JPY->RUB->EUR)
* PoS mechanism to make sure there cannot be an infinite number of accounts (50 XRP minimum on each account means there can be only Ripple accounts for 1/4 of the world's population of ~8 billion humans at most)
* Fee payment by being destroyed when sending transactions

All of these things are fulfilled quite well, where XRP really suck is the following:
* Store of wealth/investment vehicle - a central authority does not really help if this central authority is able to hold and being tasked to disperse a huge portion of funds to begin with.

Interestingly Bitcoiners seem to really be into BTC because it seems like it is a good store of wealth (I have mixed feelings about that too, but that's not part of this thread) and a lot of criticism goes in that direction. Still there might be a way to use BTC for the other parts too instead of XRP. I see a bigger problem in the slowness of BTC transactions though, as Ripple is designed to come to a resolution much faster and transferring BTC would take too long on the main chain. Once you start transfers off the chain though, you deal with IOUs which then again by definition are not assets that you actually own. I would be interested in actual ideas to replace XRP in a meaningful way.

@coinft:
PoW attached to transactions would be more expensive than current XRP fees (which are also much lower than other closed source bitcoin exchanges btw.) and it does not help with the (imho elegant) solution of having a native embedded currency/asset one can own. If you replace this with IOUs (BTC or USD), who should then be the truly decentralized entity that issues these? Maybe you could elaborate a bit more on your true mesh exchange that uses USD as asset?

The Consensus page is just marketing, only code speaks the truth. The promise was to open it as soon as possible, but the more time passes in silence the more we can reason it to be either a lie, or impossible due to security constraints resulting from a proprietary and rushed development process. It's getting tiresome to repeat this and hearing no arguments but "look, consensus!". If you believe in reading web pages, read that one for a different perspective: http://ripplescam.org/.

I am not sure what you mean by natively integrating BTC into ripple. For one there are already gateways which do this via ripple IOUs. If you think there'll be native bitcoin proof of ownership in ripple, dream on. Second, for open sourcing the server code, I wouldn't bet on it.

Regarding POW to fight spam, clearly this can be tuned, and there is no reason (except maybe shilling for OpenCoin) to assume this is necessarily more expensive than current XRP. You are correct the current fees are ridiculously low, but so is spam protection, and an equivalently weak proof of work protection could be done in the blink of an eye with hardly any energy. Even with my meager amount of free hand out XRP I could do some 1000000000 transactions, I doubt the network is ready for that.

As for a mesh exchange, again this is not something new, ripple users can elect to exchange whatever IOUs they have directly instead of via a centrally controlled reserve currency. There is no need for a privileged reserve currency to facilitate exchanges. Users are likely to adopt bitcoin or USD or something else for this purpose voluntarily, something they can trust. But at the moment they cannot trust the ripple network, XRP or not.

Where on ripplescam does it give proof that the consensus mechanism does NOT work (or can not work)?
Just saying "it's not Open Source, so it cannot be true" is a position that I cannot really identify with - existance of an implementation does not guarantee or imply correct workings. Also you're free to implement a consensus mechanism as outlined in the Wiki and use this to either prove or disprove the feasability of dispute resolution using consensus.

IOUs are inherently different from currencies like (native) BTC or XRP. IOUs have a certain value (0%-100% of the thing that is owed) but get destroyed once you actually redeem them. They exist to be destroyed. Currencies have 0 redeemable value (yes, both BTC and XRP), but have utility in being used for price discovery and have the big advantage that they can be actually owned as an asset, since they won't (and cannot) be redeemable with anyone for anything. The actual price of a currency comes from it's utility and even more the trust that people have in it.

If you use now BTC IOUs (e.g. MtGox BTC codes) as "currency" in Ripple or elsewhere, you again need to trust a person to redeem them and not a currency to be useful. It wouldn't matter if you used USD IOUs, XAU IOUs, BTC IOUs or LTC IOUs - what you are using is always IOUs that have different features than an actual currency.

Actually I disagree with you on this - if there is no generally accepted currency (it does not need to have a reserve, it  just needs to be trusted by people and be useful as a currency), there will be one created implicitly. The big danger imho is that if there is no native currency (something that you can own) this will be the most dispersed or otherwise highly trusted IOU. Bitcoin trading already suffers from high centralization towards MtGox, now imagine you cannot trade Bitcoins any more but only coins deposited at MtGox. Once you take away a central 0-value currency, another central currency would emerge. If that turns out to be an IOU, bad things can and will happen.

The point of this thread now is on how BTC can be used as this central currency (meaning I can exchange Ripple IOUs or native BTC for Ripple IOUs within Ripple instead of Ripple IOUs and XRP for Ripple IOUs) or at least be used next to XRP. There is already a thread at the Ripple forums about this, JoelKatz' stance seems to be that BTC would not be useful as they have a different target group, are slow and would be taken over by XRP because of this as XRP are inherently more useful than BTC in a Ripple system. If you disagree with this, I'd like to hear your reasons and ideas and please not again some rants about how the code should be open sourced yesterday. Please get more concrete - instead of "clearly this can be tuned" say "Sha512 hashing with a difficutly of 0.01 just takes X cycles on a modern CPU, so this costs just 0.000x USD assuming a power usage of 50W and Y cycles per second."

Lastly, I'm really fed up with the "shilling" accusations. I try my best to be constructive here, it is not very easy sometimes though. It would be great to have some useful discussions as this would also help the OT+BM implementation probably, which seems to me to be something similar to this "mesh exchange". I'm not too sure how one can trade there though (with trading meaning something different than investing) and what the implications of that would be.

Double post to seperate this rather personal piece above from this one:

How to integrate BTC as native currency in Ripple (next to XRP, as I believe there would be some benefits in staying compatible to the existing network):
The block chain needs to be stored by
 * end user clients to send transactions/trade offers
 * validators to validate these transactions and check if the attached BTC are actually valid
 # servers probably should have the block chain too (to not send bad transactions to validators) but I'm no 100% sure if they need it

There needs to be a way to:
 * make Ripple wait for a certain external event until a transaction has been confirmed (let's say for a certain amount of confirmations)
 * ensure that this does not create a double spend scenario (e.g. I buy USD IOUs for native BTC, I send my BTC and the USD need to be frozen at the same time. Now I can double-spend my BTC or my counterpart could doble-spend the USD IOUs, as the transaction isn't finalized yet and there won't be consensus for some time until the BTC are credited at their destination.)
 * do all this without requiring a mutually trusted escrow (the current way BTC <--> IOU trades are being done)

I assume XRP are still used for transaction fees and account funding, if that also needs to be done via BTC, you're looking towards an implementation that has to provably destroy BTC forever (using them as fees doesn't work as then bitcoin miners would have other incentives, especially if they also operate validators). Account funding might be replaced by PoW, this is tricky though as a past PoW gets worth less and less over time thanks to Moore's law.

Basically what you have said is, in order to make Ripple work with Bitcoin, fork Ripple to mimic the Bitcoin system almost perfectly. Why not just stick with Bitcoin?

Because bitcoin is not an IOU exchange system and would benefit from one. Just look at the amount of topics regarding distributed exchanges.

Ripples usefulness does not lie in its currency and some people seem to dislike this aspect so much that they dismiss the whole idea. Maybe bitcoin as a second native currency can also have other benefits, after all it is much better established compared to xrp.

Bitcoin would die if a "credit" or IOU system was implemented. Digital debt is not something that can even be considered, as who would force such Bitcoins to be returned and repaid?

All btc trades that are not settled face to face in cash are IOU trades. Most of the merchants out there give you IOUs in return for btc.

Ripple with btc would extend the capabilities of bitcoin and just like any other use case have no to minimal influence (depending on trade volume) on the actual system.

Bitcoin survives just fine even though besides local bit coins EVERY exchange transaction is using IOUs on at least one side.

Also i suggested to implement vanilla bitcoin next to xrp, these are not debt or IOUs.

We could pick a block number at which to archive a copy of the bitcoin blockchain, then decide how many opensource ripples there are going to be and compare that to the number of bitcoins on the archived blockchain. Then anyone who wants some RIpples produces a request signed by a bitcoin address that had bitcoins at the time the blockchain was archived and receives that many ripples and that address is ticked off as having received its allotment of ripples.

That way we can distribute the ripples and not even actually know whether in fact they will all end up redeemed/distributed, since we do not know how many of the bitcoins in the archived blockchain still have somewhere someone or something that knows or remembers (records) the private key that would be needed to actually redeem those ripples.

To avoid a central authority we could do a whole distributed system for ticking off which addresses have been redeemed (and to what ripple address the corresponding ripples were sent. If we even care, or need to know, to what ripple address they went).

A problem with trying to 51% an existing ripple network is the incumbents do not have to listen to anyone they don't want to. They list only the servers they want to as ones to care about when making a consensus. So they can open source the code but just not bother telling any of the existing servers to pay any attention to any new nodes other than ones they hand pick based on the new node having paid them off, having know your customer rules, having anti money laundering procedures in place, being owned by a direct descendant of Bill Gates or Jed or Obama or whatever criteria they choose to use to decide which nodes their node will give any weight to in the "consensus" process.

-MarkM-

If you want to distribute XRP according to BTC amounts in addresses, you could even simpler calculate a Ripple address from a BTC address... ;)

Yeah but then you will have imported gosh knows how many dead accounts/coins.

Might be better to only have a fixed window of time in which to claim your ripples, after which we will know for sure exactly how many ripples were put into circulation, the rest can just stay dead in the original address from which the distribution was done.

-MarkM-

Ripple is all marketing at this point.

No one knows if the consensus scheme will work...
When scaled up... or under attack... or decentralized.

The current Ripple network is just a Dev Playground.

There are reasons why they are WAAAAAY behind schedule and not open sourced...
My guess is that there are fundamental problems with the design...

This is a group that can't even debug a Client after 2 years.