When GoLang was first announced, it began an never-ending amount of confusion for me (a Go board game player), as I started to see all these articles around Go on HN, just to be continually disappointed.
"Our consensus process uses peering ... instead of mining. The ledger is a data structure that describes the current state of the network as a merkle tree"
And all of the architects here have probably bemoaned the sudden shift in interest when "architecture" inevitably refers to software and nothing about buildings. (Though excitement for both is certainly not mutually exclusive!)
Sometimes it's just a funny way of getting introduced to something that's really cool.
As a mobile developer, these Ripple articles always trick me because to us Ripple is the fastest emulator for testing PhoneGap apps (HTML5 that runs on multiple mobiles wrapped inside a native app). An emulator for PhoneGap that runs in Chrome as a plugin basically.
From a mobile dev perspective this other Ripple is some worthless alternative payment method no one uses because PayPal has all the accounts so is easier for the user, or iTunes or Google or amazon or Samsung Fusion payments are built into their stores and protected by TOS as being the only payment processor you can use.
So an article on another payment method is pretty worthless and the name collision is pretty annoying because I have to sometimes follow the link before I see it for what it is.
Well they rather cheaply added on a currency that made no sense, which they issued to themselves and force people to use (or at least hold) to participate in the protocol. If it was open source from day one, the very first thing anyone would do would be to remove XRP.
XRP exists to help protect the Ripple network by making it costly to mount an attack against the network.
The drama that took place earlier this year when there were several denial of service attacks against Mt. Gox, causing the price of BTC to drop so that it could be bought cheaper by the attackers and their friends is way less likely to happen to Ripple.
Unlike transfering BTC, sending XRP from one Ripple user to another is free and confirmation is instant—no need for miners to confirm the transaction.
There are so many other, better ways to solve that problem which don't involve an unnecessary transfer of wealth to OpenCoin Inc. Also, I wouldn't even call it a solution: it makes opening accounts costly, which directly hampers scalability and eliminates entire classes of use cases. That's a weakness, not an advantage.
There may very well be better ways. But creating a distributed p2p exchange protocol is probably a lot harder to do than some of the people raising funds and making promises would have you believe.
So I'm just curious...but how does the ledger work? It's supposed to be eventually consistent, so nodes on the network eventually get a copy. How do they determine that everyone gets one?
I'm very interested in this project as it essentially can be used as a currency the same way that Bitcoin is, without any mining required. It uses the concept of trust from a variety of different nodes. If a node acts dishonestly it loses trust and therefore loses reputation which in this system accounts for your actual currency: http://bitcoin.stackexchange.com/questions/7550/how-does-rip...
The idea that I'm interested in is that it seems to solve the double-spending issue that Bitcoin so eloquently solved, but without all the electricity wasting issue, and the 51% issue, that currencies with proof-of-work (POW aka mining) have. Currencies that use the POW system are designed to work well only if half of the computational power of the network is used by honest nodes. If by any means more than 50% of the network is in control of dishonest nodes, they could do all kinds of things and perhaps even kill the entire currency.
Double spending isn't really about trust. It's about transactional atomicity.
After reading a bit, I've concluded that Ripple doesn't actually solve the consensus problem. Whether it works or not depends on the shape of the graph of the core validating nodes. If the graph is too centralized (as it is now, and probably will always be), it can be controlled by fiat.
Transactional atomicity is exactly the reason why ripple needs a native currency - the native currency is what provides byzantine fault tolerance[1], just as in bitcoin.
Supposedly, ripple reaches consensus under diverse graphs of validator node networks. But its a research topic still undergoing study (Ripple Labs say they have whitehats closely examining the protocol).
Now it gets interesting. For a long time the lack of an open-source server and the associated centralization was a big point of criticism against Ripple.
Personally I don't think we'll see much grassroots adoption of any cryptocurrency technology that can be categorized as "pre-mined" or anything less than full decentralization, and that includes both Ripple and Mastercoin.
Now if they're able to get the existing banking system on board they could have some chance. It sounds like they're handing out large chunks of XRP (the Ripple cryptocurrency) to companies that implement Ripple integration as an incentive.
Ripple is still semi-centralized. If Alice and Bob trust different nodes they may end up with different ledgers and thus they may be unable to transact. The only way to keep Ripple unified is for everyone to trust the same nodes, which is the definition of centralization.
Everyone doesn't have to trust the same nodes, the network will actually come to consensus with minimal overlap of trusted validators in the UNLs (and more importantly it will detect and halt when the network isn't coming to consensus, instead of forking like the bitcoin blockchain).
Besides, the definition of centralization is that there's a central authority with arbitrary power, such as changing balances or freezing accounts.
Does that mean it does an intersect of sets of trusted validators? How does it determine which sets of trusted validators to use? What if the intersection is the empty set?
What do you mean by "it"? There is only a p2p network, with each node acting independently. Nodes which are on multiple other nodes UNLs could be considered the intersection of a set. But it makes more sense to think of it as a directed graph. There's no such think as an "untrusted validator", if you run rippled and your node isn't on anyone else's UNL, then you aren't really part of the network because your votes aren't considered in anyone else's consensus decisions (but you would get real-time access to the proposals and candidate sets).
So the set of of validators which gets used is exactly the union of nodes in the UNLs. If you have two networks without any overlap in the UNLs, then you'd get two separate ledgers.
This is incorrect. All Ripple servers go through a consensus process to validate transactions; after which the Last Closed Ledger (LCL) is generated and sent to every server.
Every server has a copy of the LCL, so there can't be a case of ledgers being different anyway.
Anyone on Ripple can send XRP to anyone else regardless of who they trust; in order for Alice and Bob to transact in a currency other than XRP, the Ripple network will find a path between them to allow the transaction.
The video is misleading. There are possible network configurations where nodes keeping different trust lists will end up partitioned from each other (separate lost closed ledgers). OpenCoin, to my knowledge, has done nothing to fix this as it is a problem inherent in the consensus mechanism they are using. The way you fix it is using some other deterministic method for decentralized consensus... like proof of work.
Do you have a source for that claim? There is no reason why nodes with different trust lists would become partitioned. Even if a majority of the nodes were malicious, all they could do is prevent the honest nodes from reaching consensus. The honest nodes would effectively stop operating, as every ledger confirmed by the malicious group would be marked as unreliable by the honest group.
Yes, it's in the original bitcointalk thread where Ripple.com was announced. A note about your example: it's not a majority of all nodes, it's a majority of your trusted node list. Which is different for every node.
Nope, it's entirely correct. During the consensus process, each server only listens to servers that its operator has marked as trusted - there is no way for servers outside the trusted clique to affect in the consensus within the clique. This has a few consequences:
- Currently, there's a small clique of servers run by OpenCoin Inc and their partner businesses which only trust each other and which everyone uses. The ledger closure process and transaction acceptance are effectively centrally controlled by that group; if your server closes the ledger itself rather than waiting for the official ledger from on high, it will be permanently stuck on its own fork of the network.
- Because of the way the ledger closure process works, if you set up your server wrong and end up in a part of the trust network that's poorly connected to the official servers you will end up permanently stuck on your own fork of the transaction history. (In practice, since you can't disagree with the official OpenCoin servers and you can't influence their consensus, you should just set your trust list to the OpenCoin-approved list exactly and forget about peer-to-peer stuff.)
- There's a mandatory transaction fee in a virtual currency, XRP, and unlike in Bitcoin the XRP used in that transaction fee is destroyed. The fee is set as part of the ledger consensus process, which is controlled by OpenCoin Inc. They also control the supply of XRP. In effect, there's a central organisation with the power to charge arbitrarily large fees for the use of Ripple.
Other than having a Ripple wallet, I have no affiliation with Ripple Labs. That being said, I'd like to respond to this article.
Nope, it's entirely correct. During the consensus process, each server only listens to servers that its operator has marked as trusted - there is no way for servers outside the trusted clique to affect in the consensus within the clique.
No, it's entirely incorrect; you have a misunderstanding of how the consensus process works[^1]. To reach consensus, all nodes have to agree on the set of changes to be applied to the ledger.
A server gets proposals for these changes from the servers on its Unique Node List[^2]. But in order for these transactions to be applied to the next ledger, enough of them have to match transactions coming from other servers on the network the aren't on the UNL. If a transaction from a server matches a transaction proposed by servers on the UNL, it gets a vote.
This process repeats until 80% of the transactions match from the UNL matches everyone else's, which is the threshold for mathematical certainty. And remember, every node on your UNL is doing this same process with the nodes on their UNLs, which makes it decentralized.
When you're running a server, you don't trust the nodes on the UNL; you just trust that more 50% of them won't collude against you.
Currently, there's a small clique of servers run by OpenCoin Inc and their partner businesses which only trust each other and which everyone uses.
Also incorrect. As of 2013.09.02, there were 30 public servers and 11 validators on the Ripple network[^3]; most likely, there are more now.
This Ripple wiki[^4] says "As long as there is some minimal degree of inter-connectivity between UNLs consensus will rapidly be reached. This is primarily because every honest node's primary goal is to achieve a consensus."
And since anyone can download and run the Ripple server software, anyone who does so is part of this so-called "small clique of servers everyone uses".
Of course there will be bad actors on the net running questionable servers and validators. But we're on this thing called the internet; we could share data on which servers to trust and stuff[^5]
The ledger closure process and transaction acceptance are effectively centrally controlled by that group; if your server closes the ledger itself rather than waiting for the official ledger from on high, it will be permanently stuck on its own fork of the network.
Not only is this incorrect, but it shows either you don't actually understand how this works or you have some agenda for making shit up…
There is no such thing as an "official" ledger and there's no "from on high" (the network topology is a graph; there's no hierarchy). By definition, a server can not close a ledger itself; a ledger can only close when there's agreement among the servers and validators using the consensus process.
And even in the the case of disaster where the network splits in half and there are conflicting transactions and ledgers, when the network is reconnected, everything get back into sync.[^6]
Because of the way the ledger closure process works, if you set up your server wrong and end up in a part of the trust network that's poorly connected to the official servers you will end up permanently stuck on your own fork of the transaction history. (In practice, since you can't disagree with the official OpenCoin servers and you can't influence their consensus, you should just set your trust list to the OpenCoin-approved list exactly and forget about peer-to-peer stuff.)
Even if you use the default UNL (which can be changed at anytime regardless), you're still participating in a peer-to-peer network and you're still part of the distributed consensus process. Nice try though. And remember, we don't trust everyone on the UNL; we just trust that most of them won't collude against us.
You got clown dollars from Ripple. It just so happens that XRP has some value. It's pretty obvious that Ripple is buying back XRP to support the currency, despite its obvious scamware-nature. It is worthless and centralized, no different than some island coming up with a cryptocurrency and saying "trust in thee." No thanks.
It's pretty obvious that Ripple is buying back XRP to support the currency, despite its obvious scamware-nature.
There you go again making shit up. Again, Ripple ledger is open and available to anyone to look at, just like the bitcoin block chain.
Please show us where Ripple Labs is buying XRP. Oh yeah—you can't.
Like any currency, the price is based on supply and demand. We can see that buying and selling of XRP has increased dramatically in the last few week. That ain't Ripple Labs buying XRP but China certainly is: http://www.ripplelounge.com/1/post/2013/12/the-new-normal-in...
It's pretty obvious that Ripple Labs is buying back their own currency on the exchanges based on the volume. It's called damage control, and their plan is to uphold the fake value as long as they can, until people are duped enough to create volume for that 'fixed' price. Ripple is a scam, stop lying to yourself.
And all of that volume happening on the various exchanges (like the 232,348.28 that traded on [RippleChina](https://ripplecharts.com/market/CNY:RippleChina/XRP) the past 24 hours) is mostly Ripple Labs buying XRP, right?
This is just… dumb. And it makes no sense.
Ripple Labs can slow down or even stop distributing XRP until the price goes back to where they'd want it. No need to do buybacks when RL (at least for now) control the vast majority of the currency.
You should stop with these posts; it's just getting more embarrassing.
XRP is essential as the native currency of the protocol.
All other currencies exist on Ripple in the form of balances. (Similar to how I store my money at Citibank in the form of USD balances. This is how our traditional financial system works).
The protocol needs a native currency (XRP) in order to pay the anti-DDOS fee. Every payment or trade requires the user to pay a 0.0001XRP fee which the protocol destroys.
It's purpose is to create a cost to sending "transaction SPAM" and make it extremely expensive to DDOS Ripple servers for any sustained period of time. This transaction fee is dynamic and scales higher in terms of heavy server load.
It's important that this type of fee be paid in a currency that is native to the protocol. This allows the protocol to remain neutral and global.
But why do we need special Ripple servers at all? Couldn't the system have been designed with a larger collection of nodes in mind and simply done without XRP?
Ripple is a distributed database of bid/ask offers. A distributed system needs to be byzantine fault tolerant (BFT).
Bitcoin achieves BFT by using its native currency (bitcoins) in a proof-of-work scheme. Basically BFT means a malicious node can't do anything which will break the blockchain, because the only way any node can make changes to the blockchain is if it has solved a block (has the private keys to next block of bitcoins). Nodes with private keys to previous bitcoins have to get changes relayed through the node which solves the next block.
Likewise, Ripple achieves BFT by using its native currency (XRP) in a consensus scheme. The consensus scheme relies on Unique Node Lists (UNL), instead of proof-of-work. So nodes can only propose changes to the ripple ledger if they are on the UNL of some other node. And changes will only be accepted if they are signed by the private keys of the native currency (XRP). Nodes which aren't on any UNLs have to broadcast their changes to nodes which are on a UNL, and of course, must still have the private keys to make those changes.
There are probably other ways to provide BFT, but using a native crypto-currency is one of them.
> The protocol needs a native currency (XRP) in order to pay the anti-DDOS fee.
No, it doesn't. Have you seen the various pre-OpenCoin ripple protocols, or the currently competing colored coin proposals? None of them necessarily needed or would have benefited from a scarce-money fee currency. Ripple is a protocol for generating ad-hoc user-issued assets and arranging trade networks for exchanging these currencies. There's no reason fees can't be collected in whatever currency is being transacted, and then atomically converted into whatever currency the collecting node desires. That's what ripple is designed to do.
The fact is that you can't transact separate currencies which are on separate protocols, unless you represent one as an issued-asset on the other. Colored Coins use the native currency of its protocol - bitcoin. The developer of the first colored coins client, Stefan Thomas, moved on to become CTO of ripple. Ripple is a new protocol altogether, with advantages over extensions/overlays on the bitcoin protocol, the main ones being no mining and much quicker ledgers.
User-issued assets on ripple have a customizable transit fee which is effectively collected in the issued currency (since the fee is paid from the balance of the issue back to the issuer). For example, bitstamp's issuer fee is 0.2%, so any trades of bitstampBTC or bitstampUSD pay 0.2% of the amount back to bitstamp's issuer address. (the fee is set at creation of the issuing address and can't be changed later).
This is not true. There are mechanisms for cross-chain trade, and with a few small changes theres quite a bit more that you can do. See the smart contracts page of the wiki, and the freimarkets whitepaper for example.
I wrote the earlier Ripple designs [1]. To me, the main thing XRP adds to the concept is a way of bootstrapping the network by providing a way to bridge the gap between islands of nodes with no trust pathway for monetary value to flow between them. I tried getting Ripple going for nearly 10 years (including a YC interview in 2007), and this bootstrapping issue was a big one.
XRP also provides anti-DDOS, which is also something you'd also need to consider carefully in implementing my original designs, as well as a brilliant way to finance the creation, development, and maintenance of the network.
> To me, the main thing XRP adds to the concept is a way of bootstrapping the network by providing a way to bridge the gap between islands of nodes with no trust pathway for monetary value to flow between them
XRP adds nothing new to the bridging problem. Any other common currency could have been used, such as USD-backed assets or bitcoin. XRP was Jeb McCaleb's stab at Bitcoin 2.0, and the bridging issue simply a post-facto rationalization. In a world where there is already existing decentralized currencies, or multiple legacy options for a common currency, there is no need for yet another centrally issued scarce-money... except that OpenCoin stands to materially benefit from forcing XRP down our throats.
> XRP also provides anti-DDOS...
It does so by economically limiting its own usefulness. Accounts and assets cost real money to create and maintain - more so than the fees involved with bitcoin. That brings us back to the traditional banking model of institutional asset issuers and heavyweight accounts, and rules out a number of protocols involving ephemeral asset issuance or privacy-enhancing one-time-use accounts.
I don't consider the problem solved if the "solution" involves restrictions that unnecessarily limit the capability of the system.
> as well as a brilliant way to finance the creation, development, and maintenance of the network.
On this I could not disagree more. XRP is an unnatural, ill-fit hack on top of Ripple which provides no tangible benefit that could not be achieved by other less restrictive, and less obviously self-serving means. It therefore ads risk to anyone investing time or resources into using Ripple, as it may be surpassed by a superior fork which removes XRP.
Financing the creation of a new, distributed, peer-to-peer network is not easy, I know - it's been hard trying to get funds for Freimarkets. But the OpenCoin / Mastercoin / Bitshares model is not the way to do it, in my opinion. Rather the bitcoin model is: distributed issuance and make your money from the economy that develops, not an underhanded wealth transfer written into the protocol.
I have talked with many of the devs from Ripple that post on BitcoinTalk often, they are so adamant that the XRP is required I feel that it's a stealth currency.
One developer was paid, instead of stock a billion ripples. The first thing Opencoin/Ripplelabs did was giveaway very small amounts to create artificial scarcity and then open an exchange (through Bitstamp) to sell off as many as possible for Bitcoins. At the peak Ripples were worth more than all the Bitcoins in the world.
I remember Joel (I think) was adamant that Ripple was not a currency at all, except we ended getting him to admit it was meant to be a competing currency to Bitcoin.
I do not trust them at all, especially now Google are involved in backing them.
Okay so ripple achieves consensus through network effects: biggest room wins. So far so good.
Now Mallory deploys ripple clients, which behave like ordinary ripple clients, but are under her control. After a while, 51% of the biggest consensus room are straw men for Mallory. She "flips the switch" introduces a transaction that places the entire network's balances into her accounts.
59 comments
[ 0.18 ms ] story [ 114 ms ] threadAs a Mesh Networking Practitioner, I see I'm once again going to have to deal with namespace collision. (Ripple has been well used name in another domain: http://www.ietf.org/proceedings/75/slides/roll-2/roll-2_file...)
Interesting - Ripple the routing protocol is primarily about Directed Acyclic Graphs, while Ripple, the payment network, works with merkle trees.
Combine the two concepts together, a directed acyclic graph of tags stored as a merkle tree, and you basically have git.
"Our consensus process uses peering ... instead of mining. The ledger is a data structure that describes the current state of the network as a merkle tree"
Sometimes it's just a funny way of getting introduced to something that's really cool.
From a mobile dev perspective this other Ripple is some worthless alternative payment method no one uses because PayPal has all the accounts so is easier for the user, or iTunes or Google or amazon or Samsung Fusion payments are built into their stores and protected by TOS as being the only payment processor you can use.
So an article on another payment method is pretty worthless and the name collision is pretty annoying because I have to sometimes follow the link before I see it for what it is.
I know what you mean, I love Ripple chocolate bars. ;)
So am I surprised? No.
The drama that took place earlier this year when there were several denial of service attacks against Mt. Gox, causing the price of BTC to drop so that it could be bought cheaper by the attackers and their friends is way less likely to happen to Ripple.
Unlike transfering BTC, sending XRP from one Ripple user to another is free and confirmation is instant—no need for miners to confirm the transaction.
The idea that I'm interested in is that it seems to solve the double-spending issue that Bitcoin so eloquently solved, but without all the electricity wasting issue, and the 51% issue, that currencies with proof-of-work (POW aka mining) have. Currencies that use the POW system are designed to work well only if half of the computational power of the network is used by honest nodes. If by any means more than 50% of the network is in control of dishonest nodes, they could do all kinds of things and perhaps even kill the entire currency.
Replacing the proof-of-work system with something based on reputation seems very interesting in my opinion: https://bitcointalk.org/index.php?topic=10193.0
After reading a bit, I've concluded that Ripple doesn't actually solve the consensus problem. Whether it works or not depends on the shape of the graph of the core validating nodes. If the graph is too centralized (as it is now, and probably will always be), it can be controlled by fiat.
Supposedly, ripple reaches consensus under diverse graphs of validator node networks. But its a research topic still undergoing study (Ripple Labs say they have whitehats closely examining the protocol).
1. http://en.wikipedia.org/wiki/Byzantine_failure#Practical_Byz...
Personally I don't think we'll see much grassroots adoption of any cryptocurrency technology that can be categorized as "pre-mined" or anything less than full decentralization, and that includes both Ripple and Mastercoin.
Now if they're able to get the existing banking system on board they could have some chance. It sounds like they're handing out large chunks of XRP (the Ripple cryptocurrency) to companies that implement Ripple integration as an incentive.
Besides, the definition of centralization is that there's a central authority with arbitrary power, such as changing balances or freezing accounts.
Does that mean it does an intersect of sets of trusted validators? How does it determine which sets of trusted validators to use? What if the intersection is the empty set?
So the set of of validators which gets used is exactly the union of nodes in the UNLs. If you have two networks without any overlap in the UNLs, then you'd get two separate ledgers.
http://bitcoin.stackexchange.com/questions/13330/what-is-the...
http://bitcoin.stackexchange.com/questions/10227/why-does-ri...
Every server has a copy of the LCL, so there can't be a case of ledgers being different anyway.
Anyone on Ripple can send XRP to anyone else regardless of who they trust; in order for Alice and Bob to transact in a currency other than XRP, the Ripple network will find a path between them to allow the transaction.
There a video from Ripple Labs that explains how consensus works: http://ripplefederation.org/videos/how-ripple-works-gateways....
- Currently, there's a small clique of servers run by OpenCoin Inc and their partner businesses which only trust each other and which everyone uses. The ledger closure process and transaction acceptance are effectively centrally controlled by that group; if your server closes the ledger itself rather than waiting for the official ledger from on high, it will be permanently stuck on its own fork of the network.
- Because of the way the ledger closure process works, if you set up your server wrong and end up in a part of the trust network that's poorly connected to the official servers you will end up permanently stuck on your own fork of the transaction history. (In practice, since you can't disagree with the official OpenCoin servers and you can't influence their consensus, you should just set your trust list to the OpenCoin-approved list exactly and forget about peer-to-peer stuff.)
- There's a mandatory transaction fee in a virtual currency, XRP, and unlike in Bitcoin the XRP used in that transaction fee is destroyed. The fee is set as part of the ledger consensus process, which is controlled by OpenCoin Inc. They also control the supply of XRP. In effect, there's a central organisation with the power to charge arbitrarily large fees for the use of Ripple.
Nope, it's entirely correct. During the consensus process, each server only listens to servers that its operator has marked as trusted - there is no way for servers outside the trusted clique to affect in the consensus within the clique.
No, it's entirely incorrect; you have a misunderstanding of how the consensus process works[^1]. To reach consensus, all nodes have to agree on the set of changes to be applied to the ledger.
A server gets proposals for these changes from the servers on its Unique Node List[^2]. But in order for these transactions to be applied to the next ledger, enough of them have to match transactions coming from other servers on the network the aren't on the UNL. If a transaction from a server matches a transaction proposed by servers on the UNL, it gets a vote.
This process repeats until 80% of the transactions match from the UNL matches everyone else's, which is the threshold for mathematical certainty. And remember, every node on your UNL is doing this same process with the nodes on their UNLs, which makes it decentralized.
When you're running a server, you don't trust the nodes on the UNL; you just trust that more 50% of them won't collude against you.
Currently, there's a small clique of servers run by OpenCoin Inc and their partner businesses which only trust each other and which everyone uses.
Also incorrect. As of 2013.09.02, there were 30 public servers and 11 validators on the Ripple network[^3]; most likely, there are more now.
This Ripple wiki[^4] says "As long as there is some minimal degree of inter-connectivity between UNLs consensus will rapidly be reached. This is primarily because every honest node's primary goal is to achieve a consensus."
And since anyone can download and run the Ripple server software, anyone who does so is part of this so-called "small clique of servers everyone uses".
Of course there will be bad actors on the net running questionable servers and validators. But we're on this thing called the internet; we could share data on which servers to trust and stuff[^5]
The ledger closure process and transaction acceptance are effectively centrally controlled by that group; if your server closes the ledger itself rather than waiting for the official ledger from on high, it will be permanently stuck on its own fork of the network.
Not only is this incorrect, but it shows either you don't actually understand how this works or you have some agenda for making shit up…
There is no such thing as an "official" ledger and there's no "from on high" (the network topology is a graph; there's no hierarchy). By definition, a server can not close a ledger itself; a ledger can only close when there's agreement among the servers and validators using the consensus process.
And even in the the case of disaster where the network splits in half and there are conflicting transactions and ledgers, when the network is reconnected, everything get back into sync.[^6]
Because of the way the ledger closure process works, if you set up your server wrong and end up in a part of the trust network that's poorly connected to the official servers you will end up permanently stuck on your own fork of the transaction history. (In practice, since you can't disagree with the official OpenCoin servers and you can't influence their consensus, you should just set your trust list to the OpenCoin-approved list exactly and forget about peer-to-peer stuff.)
Even if you use the default UNL (which can be changed at anytime regardless), you're still participating in a peer-to-peer network and you're still part of the distributed consensus process. Nice try though. And remember, we don't trust everyone on the UNL; we just trust that most of them won't collude against us.
The...
There you go again making shit up. Again, Ripple ledger is open and available to anyone to look at, just like the bitcoin block chain.
Please show us where Ripple Labs is buying XRP. Oh yeah—you can't.
Like any currency, the price is based on supply and demand. We can see that buying and selling of XRP has increased dramatically in the last few week. That ain't Ripple Labs buying XRP but China certainly is: http://www.ripplelounge.com/1/post/2013/12/the-new-normal-in...
It's pretty obvious that the only lying going on is coming from you.
It's pretty obvious that Ripple Labs is buying back their own currency on the exchanges based on the volume. It's called damage control…
Yes because Ripple Labs, fresh from raising [an additional $3.5 million in funding](http://www.finsmes.com/2013/11/ripple-labs-raises-3-5m-fundi...) was clearly in really bad shape.
And all of that volume happening on the various exchanges (like the 232,348.28 that traded on [RippleChina](https://ripplecharts.com/market/CNY:RippleChina/XRP) the past 24 hours) is mostly Ripple Labs buying XRP, right?
This is just… dumb. And it makes no sense.
Ripple Labs can slow down or even stop distributing XRP until the price goes back to where they'd want it. No need to do buybacks when RL (at least for now) control the vast majority of the currency.
You should stop with these posts; it's just getting more embarrassing.
You should stop with these posts; it's just getting more embarrassing.
I'd still prefer something like Open Transactions which supports blinded instruments, though.
All other currencies exist on Ripple in the form of balances. (Similar to how I store my money at Citibank in the form of USD balances. This is how our traditional financial system works).
The protocol needs a native currency (XRP) in order to pay the anti-DDOS fee. Every payment or trade requires the user to pay a 0.0001XRP fee which the protocol destroys.
It's purpose is to create a cost to sending "transaction SPAM" and make it extremely expensive to DDOS Ripple servers for any sustained period of time. This transaction fee is dynamic and scales higher in terms of heavy server load.
It's important that this type of fee be paid in a currency that is native to the protocol. This allows the protocol to remain neutral and global.
Bitcoin achieves BFT by using its native currency (bitcoins) in a proof-of-work scheme. Basically BFT means a malicious node can't do anything which will break the blockchain, because the only way any node can make changes to the blockchain is if it has solved a block (has the private keys to next block of bitcoins). Nodes with private keys to previous bitcoins have to get changes relayed through the node which solves the next block.
Likewise, Ripple achieves BFT by using its native currency (XRP) in a consensus scheme. The consensus scheme relies on Unique Node Lists (UNL), instead of proof-of-work. So nodes can only propose changes to the ripple ledger if they are on the UNL of some other node. And changes will only be accepted if they are signed by the private keys of the native currency (XRP). Nodes which aren't on any UNLs have to broadcast their changes to nodes which are on a UNL, and of course, must still have the private keys to make those changes.
There are probably other ways to provide BFT, but using a native crypto-currency is one of them.
No, it doesn't. Have you seen the various pre-OpenCoin ripple protocols, or the currently competing colored coin proposals? None of them necessarily needed or would have benefited from a scarce-money fee currency. Ripple is a protocol for generating ad-hoc user-issued assets and arranging trade networks for exchanging these currencies. There's no reason fees can't be collected in whatever currency is being transacted, and then atomically converted into whatever currency the collecting node desires. That's what ripple is designed to do.
User-issued assets on ripple have a customizable transit fee which is effectively collected in the issued currency (since the fee is paid from the balance of the issue back to the issuer). For example, bitstamp's issuer fee is 0.2%, so any trades of bitstampBTC or bitstampUSD pay 0.2% of the amount back to bitstamp's issuer address. (the fee is set at creation of the issuing address and can't be changed later).
XRP also provides anti-DDOS, which is also something you'd also need to consider carefully in implementing my original designs, as well as a brilliant way to finance the creation, development, and maintenance of the network.
[1] http://archive.ripple-project.org/Protocol/Protocol
[1] http://freico.in/docs/freimarkets.pdf
> To me, the main thing XRP adds to the concept is a way of bootstrapping the network by providing a way to bridge the gap between islands of nodes with no trust pathway for monetary value to flow between them
XRP adds nothing new to the bridging problem. Any other common currency could have been used, such as USD-backed assets or bitcoin. XRP was Jeb McCaleb's stab at Bitcoin 2.0, and the bridging issue simply a post-facto rationalization. In a world where there is already existing decentralized currencies, or multiple legacy options for a common currency, there is no need for yet another centrally issued scarce-money... except that OpenCoin stands to materially benefit from forcing XRP down our throats.
> XRP also provides anti-DDOS...
It does so by economically limiting its own usefulness. Accounts and assets cost real money to create and maintain - more so than the fees involved with bitcoin. That brings us back to the traditional banking model of institutional asset issuers and heavyweight accounts, and rules out a number of protocols involving ephemeral asset issuance or privacy-enhancing one-time-use accounts.
I don't consider the problem solved if the "solution" involves restrictions that unnecessarily limit the capability of the system.
> as well as a brilliant way to finance the creation, development, and maintenance of the network.
On this I could not disagree more. XRP is an unnatural, ill-fit hack on top of Ripple which provides no tangible benefit that could not be achieved by other less restrictive, and less obviously self-serving means. It therefore ads risk to anyone investing time or resources into using Ripple, as it may be surpassed by a superior fork which removes XRP.
Financing the creation of a new, distributed, peer-to-peer network is not easy, I know - it's been hard trying to get funds for Freimarkets. But the OpenCoin / Mastercoin / Bitshares model is not the way to do it, in my opinion. Rather the bitcoin model is: distributed issuance and make your money from the economy that develops, not an underhanded wealth transfer written into the protocol.
One developer was paid, instead of stock a billion ripples. The first thing Opencoin/Ripplelabs did was giveaway very small amounts to create artificial scarcity and then open an exchange (through Bitstamp) to sell off as many as possible for Bitcoins. At the peak Ripples were worth more than all the Bitcoins in the world.
I remember Joel (I think) was adamant that Ripple was not a currency at all, except we ended getting him to admit it was meant to be a competing currency to Bitcoin.
I do not trust them at all, especially now Google are involved in backing them.
Now Mallory deploys ripple clients, which behave like ordinary ripple clients, but are under her control. After a while, 51% of the biggest consensus room are straw men for Mallory. She "flips the switch" introduces a transaction that places the entire network's balances into her accounts.
How does ripple prevent this?