Bitcoin Forum
April 26, 2019, 04:53:48 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 »
  Print  
Author Topic: ripple: let's test it!  (Read 43518 times)
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1004


Democracy is vulnerable to a 51% attack.


View Profile WWW
March 21, 2013, 06:44:40 AM
Last edit: March 21, 2013, 07:20:15 AM by JoelKatz
 #401

Can someone explain how Ripple and the consensus approach would handle a fork (majority POW for bitcoin vs majority validators for ripple) like bitcoin experienced earlier this month?
Your node tries to obtain a consensus with everyone you asked it to obtain a consensus with. If it can't, then it fails, and it knows it fails. So essentially, the same thing that happened with Bitcoin would happen except for two things:

1) Everyone would immediately know that the network was split because they wouldn't see the validations and consensus they expect. There would be no need to warn people to stop processing transactions.

2) If one chain was invalid, people could manually opt to drop validators that select the invalid chain. There would be no need to persuade 50% of the hashing power to move. However, this wouldn't help much if both chains were equally valid. (Without someone to make a decision, I could see some people moving from .7 to .8 and some moving from .8 to .7, not helping much until a community decision was made. That would be less of a problem if one chain had clearly invalid transactions in it. People would independently choose to leave the invalid chain.)

Quote
One of the huge selling points of bitcoin is no double spends, once a transaction is confirmed there are no rollbacks.. quite clearly that was not the case earlier this month, could Ripple experience the same sort of problem?
Like Bitcoin, it is designed to resist them. Like Bitcoin, bugs can cause systems to do things they were designed not to do. For this specific type of failure though, I believe Ripple's architecture is better able to resist it.

That said, I believe this type of resistance could be added to Bitcoin without too much difficulty. First, if you see blocks are being found way too slowly, stop processing transactions. (There's a risk that the hashing power has gone to another chain, maybe one you're partitioned from due to network issue.) Second, if you see several nodes, particularly nodes close to mining pools are on a different blockchain than you are, stop processing transactions. (Because that other chain might be better than yours for some reason your program can't see.)

Quote
I guess there is no way to avoid a splitting of versions of truth depending on what groups of users want.. thinking out loud, the trick is to be alerted to the fact that there is another fork out there and is it the one you want to be on..
Exactly. This is easier to do in Ripple than in Bitcoin because you see trusted validators validating a different ledger whereas in Bitcoin you can only be aware of a drop in hash rate later by statistical sampling. But it's not hard to add to Bitcoin.

Mining pools could even periodically broadcast a time-stamped signed hash of the tip of the blockchain just as Ripple validators do. Your node could then know if it was on the same block as each mining pool automatically. No central authority or manual intervention is needed -- pools and miners could include their signing key or its hash in blocks that they mine. So you'll know roughly what percent of the mining power each key represents.

Ripple currently has a problem where a few times a day, this logic trips and the Ripple network (more accurately, some client-handling servers) stops processing transactions. Part of it is due to the fact that the number of validators is so small that it's hard to tell if a validator just stopped processing or whether you're split from it. Fortunately, it only takes 20 seconds or so for a new consensus round to start and it all to sort out.

I believe Ripple would be more resistant to this problem with more validators, but testing in edge cases helps us to make sure the algorithm is robust and reliable. We'd prefer to not process a transaction for a few seconds than claim we had processed one when we didn't, of course. But the issue is more with ensuring we know the current state of the network for things like reporting validated transactions to others. Where, again, a 20 second delay is better than an incorrect report of confirmation.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
moocowpong1
Member
**
Offline Offline

Activity: 79
Merit: 10


View Profile
March 21, 2013, 07:59:35 AM
 #402

JoelKatz:

In Bitcoin, because you can verify the validity of the entire blockchain and a valid transaction contains proof that the sender authorized it, you can in principle trace your coins back to their origin and have a proof of authorization for each step along the way. This means that if your coins ever end up disappearing, it must be because either a) they were double-spent at some point, and the current longest chain includes the other transaction or b) the block they originated in isn't part of the longest chain. This also means there's no way to end up controlling coins that you didn't control before except by receiving them or by mining a block, which puts limitations on the kinds of attacks possible. (An attacker must legitimately control coins in order to double spend them, for example – they can't just print money.)

In Ripple I understand that validators only needs the most recent ledger, meaning there isn't any guarantee that such a chain of proof exists. Are there any attacks that have the rough form

Quote
... -> valid ledger -> valid ledger -> HuhHuhHuh -> superficially valid ledger with incorrect balances -> ...

That is, is there some event like a massive power outage or a network split or colluding validators which somebody could exploit to update balances in their favor? Perhaps it might go like this: a power outage makes it so that a colluding set of validators is temporarily the majority, and they propose a ledger with malicious changes. Several ledger closes go by before the rest of the validators are up again, and when they look at the network they see that the current ledger includes the malicious changes. Because no record of a transaction needs to exist for a balance to be considered valid, there's no way to prove that the new balances are illegitimate, and the malicious ledger looks valid.

Am I understanding things correctly? What conditions could this happen under? What sort of resources would an attacker need to make this happen? Are there any limitations on what could be done in this type of attack? How could the community recognize and react to such an attack?
markm
Legendary
*
Offline Offline

Activity: 2254
Merit: 1005



View Profile WWW
March 21, 2013, 08:09:46 AM
 #403

Wouldn't the total balance no longer be zero?

Unless they also faked origins for the newly appeared assets?

(That is, issuing accounts with negative balances equal in absolute value to the total positive balances of that asset?)

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
moocowpong1
Member
**
Offline Offline

Activity: 79
Merit: 10


View Profile
March 21, 2013, 08:24:25 AM
 #404

Wouldn't the total balance no longer be zero?

Unless they also faked origins for the newly appeared assets?

(That is, issuing accounts with negative balances equal in absolute value to the total positive balances of that asset?)

-MarkM-


I don't see an obstacle to such an attacker, for example, zeroing their debt with all their creditors, or causing somebody to trust them and owe them money (although there's no reason to believe that person would pay that debt), or transferring arbitrarily large amounts of XRP from other accounts, or even creating XRP (although if they broke the 100 billion XRP cap, I don't know if validators would consider it valid). As far as I can tell, they can rewrite the ledger at will, so long as it appears valid afterwards.
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1004


Democracy is vulnerable to a 51% attack.


View Profile WWW
March 21, 2013, 10:20:35 AM
Last edit: March 21, 2013, 11:12:20 AM by JoelKatz
 #405

In Bitcoin, because you can verify the validity of the entire blockchain and a valid transaction contains proof that the sender authorized it, you can in principle trace your coins back to their origin and have a proof of authorization for each step along the way. This means that if your coins ever end up disappearing, it must be because either a) they were double-spent at some point, and the current longest chain includes the other transaction or b) the block they originated in isn't part of the longest chain. This also means there's no way to end up controlling coins that you didn't control before except by receiving them or by mining a block, which puts limitations on the kinds of attacks possible. (An attacker must legitimately control coins in order to double spend them, for example – they can't just print money.)
That's correct, though it doesn't protect against many kinds of attacks. For example, someone with sufficient hash power can alternately deposit and withdraw Bitcoins at a large exchange and then rewrite the block chain to turn his deposits into double spends. This might undo a large number of transactions made by other people who withdrew from that same exchange. So even though he can't touch Bitcoins that never moved, he could contaminate a huge fraction of Bitcoins that do move. (By invalidating prior transactions that they depend on.)

Quote
In Ripple I understand that validators only needs the most recent ledger, meaning there isn't any guarantee that such a chain of proof exists.
Strictly speaking, that's all they need. But a validator can demand whatever proof it wants. Of course, if it doesn't agree with the majority, it won't do much good. But validators can get together to instill any rules they wish for how to determine the valid ledger.

Quote
Are there any attacks that have the rough form
Quote
... -> valid ledger -> valid ledger -> HuhHuhHuh -> superficially valid ledger with incorrect balances -> ...
We don't think so. Should this ever be an issue, a validator can adopt a policy to defend. While your policy could be to accept any ledger that has the majority rule, your policy could also be to be the "valid minority" if the apparent majority can't prove the validity of the ledger it claims. It is the validator's job to, in consultation with the other validators, declare the valid ledger. If you don't like a validator's policy, you are free to ignore it.

All of these policies work. If some vulnerability were ever spotted in the policy, it can easily be changed with no need to get everyone to agree on the change. The current code goes with a strict majority and does not demand a chain of proof. We're investigating whether this is the ideal approach.

The advantage of the Bitcoin approach is that the result is unambiguous and (barring bugs like the one that caused the recent split) everyone with the same data should agree on the same result. This does guarantee that if you don't try to move your coins, they stay safe. The advantage of the Ripple approach is that validators can be flexible and you're immune to attacks based on people who gather hash power. If someone does cheat, a consensus can revert the ledger just as was done with the bug that create Bitcoins out of thin air. The disadvantage of the Ripple approach is that unless validators adopt a policy of always demanding proof, you can theoretically lose coins you never moved. Of course, validators could insist on such proof before allowing a rejoin after a split.

Ripple is much more flexible than Bitcoin in this regard. That is both an advantage and a disadvantage.

Quote
That is, is there some event like a massive power outage or a network split or colluding validators which somebody could exploit to update balances in their favor? Perhaps it might go like this: a power outage makes it so that a colluding set of validators is temporarily the majority, and they propose a ledger with malicious changes. Several ledger closes go by before the rest of the validators are up again, and when they look at the network they see that the current ledger includes the malicious changes. Because no record of a transaction needs to exist for a balance to be considered valid, there's no way to prove that the new balances are illegitimate, and the malicious ledger looks valid.
Right, that would be the type of attack you'd have to try to make work. It can be defeated by validators demanding proof of a valid chain. We do need to investigate what the right policy is. I think it's that you just go with the majority on startup but that if you see things change while you are running, you demand to see a proof chain and be the "correct minority" if you cannot get it. (Of course, while you remain in the minority among nodes you choose to trust, you have to pronounce the network "broken" this protects those who trust you from transacting on a split network. Failures should not be silent.)

Another possibility might be to demand proof if you've been down for less than a certain amount of time. If you shut down for ten minutes to reboot a server and all of a sudden a majority is claiming something completely different, you probably should try to build the minority. But things would already be fairly broken if it got to that point.

We have a "clustering" capability to declare nodes that you fully trust. This allows a group of servers under common administration to distribute the cost of ECDSA signature checking. If we're part of a cluster, we could go with other nodes in our own cluster on startup. That would get the node back in service faster.

As I explained earlier in this thread, Bitcoin could pretty easily adopt some of the same techniques Ripple uses to deal with disagreement. While you can't really change the rule that the most PoW is the valid chain, you can at least automatically detect when there's disagreement over the longest chain and stop transaction processing sooner, without requiring the manual intervention that was required in the 0.7/0.8 split.

To summarize: There are two types of ways a system can be attacked or fail. One is due to a bug or design flaw. Systems develop resistance to this type of attack by good design, many eyes looking over the design, and over time. But the other way is due to an understood weakness -- one that you defend against but ultimately must accept as fundamental to the design. For Bitcoin, this would be a Finney attack or a 51% attack. For Ripple, this would be some kind of consensus breaking attack. We believe Ripple is less vulnerable to this type of attack because consensus is more flexible. You can choose who to trust, rather than having to trust whoever has the most hashing power, and you can choose how you use that trust, rather than having to go with the longest chain. There can, however, be endless arguments over what the very best way is to use this flexibility, and we will continue to improve it to make these attacks even more unpossible. Wink

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
chriswen
Hero Member
*****
Offline Offline

Activity: 756
Merit: 500


View Profile
March 21, 2013, 12:37:13 PM
 #406


I believe Ripple would be more resistant to this problem with more validators, but testing in edge cases helps us to make sure the algorithm is robust and reliable. We'd prefer to not process a transaction for a few seconds than claim we had processed one when we didn't, of course. But the issue is more with ensuring we know the current state of the network for things like reporting validated transactions to others. Where, again, a 20 second delay is better than an incorrect report of confirmation.


Well, it seems difficult to host a validator node, or even a regular node for that matter.  How do you do that?
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1004


Democracy is vulnerable to a 51% attack.


View Profile WWW
March 21, 2013, 01:11:05 PM
 #407

Well, it seems difficult to host a validator node, or even a regular node for that matter.  How do you do that?
Once the server source code has been publicly released, you pretty much just install it, run it, and then tell it to generate a validation key. Then you can publish your validation public key either manually (by telling it to other validators) or by associating it with your domain. (Check out https://ripple.com/ripple.txt or https://weexchange.co/ripple.txt to see how domain association works.)

Validators actually need less horsepower than servers that deal directly with clients. They don't need to keep any history. The don't need to find payment paths. They don't need to handle "expensive" queries for complex information. Theoretically, they only need the current ledger. Of course, they do have to process all transactions. They do have to negotiate with other validators. They do have to sign validations and proposals. They do have the check the signatures on proposals and validations from other validators. They do need to do this fast enough to not hold the consensus process up. If part of a cluster, they can distribute the ECDSA signature checking load.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
moocowpong1
Member
**
Offline Offline

Activity: 79
Merit: 10


View Profile
March 21, 2013, 04:21:28 PM
 #408

<snip>

Very interesting, thanks for the detailed reply!
chriswen
Hero Member
*****
Offline Offline

Activity: 756
Merit: 500


View Profile
March 21, 2013, 06:18:57 PM
 #409

Well, it seems difficult to host a validator node, or even a regular node for that matter.  How do you do that?
Once the server source code has been publicly released, you pretty much just install it, run it, and then tell it to generate a validation key. Then you can publish your validation public key either manually (by telling it to other validators) or by associating it with your domain. (Check out https://ripple.com/ripple.txt or https://weexchange.co/ripple.txt to see how domain association works.)

Validators actually need less horsepower than servers that deal directly with clients. They don't need to keep any history. The don't need to find payment paths. They don't need to handle "expensive" queries for complex information. Theoretically, they only need the current ledger. Of course, they do have to process all transactions. They do have to negotiate with other validators. They do have to sign validations and proposals. They do have the check the signatures on proposals and validations from other validators. They do need to do this fast enough to not hold the consensus process up. If part of a cluster, they can distribute the ECDSA signature checking load.


Yes something like this is needed.  Like how on bitcoin you can download a p2p client to help the network.
SebastianJu
Legendary
*
Offline Offline

Activity: 2338
Merit: 1030


Legendary Escrow Service - Tip Jar in Profile


View Profile WWW
April 02, 2013, 01:17:37 AM
 #410

Is it possible to use ripple to get paid by customers for shopitems? Or does it really only work with friends or trustworthy exchanges?
How about moneybooker, paypal and so on? Can they be traded with ripple when you dont have an account there? And is it safer this way?
I still dont find a case where its useful to use ripple.

Please ALWAYS contact me through bitcointalk pm before sending someone coins.
dchapes
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
April 02, 2013, 03:13:29 AM
 #411

Is it possible to use ripple to get paid by customers for shopitems?

Sure, one way would be to set the price of your items in the currency or currencies of your choice, USD, EUR, BTC, whatever. (e.g it'd be a lot easier for an American just to price items in USD rather than always looking up the daily or hourly BTC exchange rate). Generate a QR code and/or a Ripple URI something like https://ripple.com//send?to=r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV&dt=12345&label=Invoice23&amnt=15.23/USD on your checkout webpage or invoice or whatever.

Probably trust a well known gateway like Bitstamp for the currencies you want to accept. This will help ensure Ripple will be able to find a payment path to you.

When people go to pay on you via Ripple the system will see what payment paths are available and give them the option of which of their IOUs to use. E.g. you wanted $15.23 USD and Ripple says I can use $15.468 CAD to pay you. You don't care what currencies I use or if I'm borrowing from a trust line or whatever; you just get what you asked for from one of your trusted sources.

If you're using an automated checkout you'd add a destination field in the payment request URI and wait for payment(s) and adjust the "amount due" field on your customer's page as required until you get the full amount (perhaps I want to pay you $10 USD + 1 DYM + $3.28 CAD using several payments instead of one).

When you want your funds out of Ripple you transfer them to a gateway and have them added to your bank account (or sent to you via BTC).

Or does it really only work with friends or trustworthy exchanges?
Those are the only ways to get value out of or into Ripple.

The same way if you want to use Paypal or Google Wallet as a payment processor you need to trust them until you get the funds in your own account, you need to trust the gateway (or your trust lines) until you can get your money out. With Paypal and Google Wallet you pay high fees and have lots of restrictions, charge backs, limited currency support, etc.

IMO, Ripple questions are best asked (and answered) on the Ripple forum and/or StackExchange
SebastianJu
Legendary
*
Offline Offline

Activity: 2338
Merit: 1030


Legendary Escrow Service - Tip Jar in Profile


View Profile WWW
April 04, 2013, 07:55:15 PM
 #412

Thanks dchapes for the explaination. It looks i still dont get ripple fully. Smiley

What does a buyer need then? A ripple account of course right? But how secure is it that i get the payment? I have a shop where i only offer liberty reserve at the moment. I had paypal, alertpay and moneybookers once but the amount of scams where to high. Chargebacks, stolen accounts and so on. So how secure would such payment be? Can the buyer make a chargeback somehow? Or can the buyer create a new account and scam me with the trust somehow?

Most buyers come to me and ask me if they can pay with paypal. They only have paypal and so on... but the risk for me is too high to accept this. So when such a buyer has a paypal account can he pay me when he opens a ripple account? Could i tell them that they can pay with paypal when they have a ripple account?

It would be great if i could get paid through this without having to fear being scammed and when the buyers could use the system without trouble. I mean i tell them they can use liberty reserve but thats a problem for most. They have to create an account there and have to send money there. I wonder if ripple could help here.

How can i find exchanges to trust? For example is mtgox in ripple? Or Liberty reserve? I tried the trust-part but it wants a username, no search possible it seems.

Please ALWAYS contact me through bitcointalk pm before sending someone coins.
Peter Lambert
Hero Member
*****
Offline Offline

Activity: 756
Merit: 500

It's all fun and games until somebody loses an eye


View Profile
April 04, 2013, 09:18:13 PM
 #413

Thanks dchapes for the explaination. It looks i still dont get ripple fully. Smiley

What does a buyer need then? A ripple account of course right? But how secure is it that i get the payment? I have a shop where i only offer liberty reserve at the moment. I had paypal, alertpay and moneybookers once but the amount of scams where to high. Chargebacks, stolen accounts and so on. So how secure would such payment be? Can the buyer make a chargeback somehow? Or can the buyer create a new account and scam me with the trust somehow?

Most buyers come to me and ask me if they can pay with paypal. They only have paypal and so on... but the risk for me is too high to accept this. So when such a buyer has a paypal account can he pay me when he opens a ripple account? Could i tell them that they can pay with paypal when they have a ripple account?

It would be great if i could get paid through this without having to fear being scammed and when the buyers could use the system without trouble. I mean i tell them they can use liberty reserve but thats a problem for most. They have to create an account there and have to send money there. I wonder if ripple could help here.

How can i find exchanges to trust? For example is mtgox in ripple? Or Liberty reserve? I tried the trust-part but it wants a username, no search possible it seems.

If you only trust the gateways (currently Bitstamp or weexchange) then there should be no way for them to scam you. To get money into the ripple system they would open an account at either of those two gateways, deposit the money, then send it to you in Ripple. You could then withdraw the money through the gateway and send it wherever you want.

The power of Ripple comes in if they have already set up a trust network. Then if anybody who trusts them holds GatewayIOUs then they can send the money to you without having to deal with the gateway directly: the Buyer initiates the transaction, their truster gets BuyerIOUs and you end up with GatewayIOUs. Then you can, as above, withdraw the money using the Gateway.

Use CoinBR to trade bitcoin stocks: CoinBR.com

The best place for betting with bitcoin: BitBet.us
Beepbop
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
April 04, 2013, 10:02:10 PM
 #414

If I understand correctly, each gateway would be free to set terms of service, just like PayPal sets terms of service, limiting who they'd do business with. But thanks to people who transfer IOUs from one service to another, a customer who only has a trust relationship to "PayCheck IOUs" could pay a business who only trusts "CheckPal IOUs" either by a settlement agreement between PaYCheck and CheckPal, or by third company or individual offering a sort of exchange/arbitrage between them (rippling through).

This makes it a pretty powerful idea, but it might raise some challenges in addition to the problem of rippling defaults, namely to do with regulatory compliance. Let's say CheckPal has a stricter ToS than PayCheck but CheckPay has more businesses using them - how would CheckPay stop their IOUs from being part of transactions that are illegal or decided to be against he ethics of its owners?
ahbritto
Full Member
***
Offline Offline

Activity: 132
Merit: 100


Ripple


View Profile WWW
April 04, 2013, 10:18:08 PM
 #415

... - how would CheckPay stop their IOUs from being part of transactions that are illegal or decided to be against he ethics of its owners?

See: https://ripple.com/wiki/Authorized_accounts
Beepbop
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
April 04, 2013, 10:41:53 PM
 #416

Thanks for the link. The tl;dr is that they can't easily do what I asked about - they could limit who holds their IOUs, but it seems the only way to prevent people from rippling their IOUs for ToS-breaking transactions is to watch how their IOUs move through the network and ban any users who facilitate those transactions after the fact. (A bit like how Dwolla is closing down accounts which are used for BTC transactions.)
SebastianJu
Legendary
*
Offline Offline

Activity: 2338
Merit: 1030


Legendary Escrow Service - Tip Jar in Profile


View Profile WWW
April 04, 2013, 10:50:29 PM
 #417

That means they have to create accounts with bitfountain or weexchange. I doubt they will be happy doing this because it would be the same like creating an account for liberty reserve. They would have to load up money to the site after registering too. So i dont see much advantage. I believe very few people will have an account there anyway. And when they have they would be able to pay with bitcoins too.
So paypal, alertpay or moneybookers dont have a ripple account right?

Please ALWAYS contact me through bitcointalk pm before sending someone coins.
Peter Lambert
Hero Member
*****
Offline Offline

Activity: 756
Merit: 500

It's all fun and games until somebody loses an eye


View Profile
April 05, 2013, 12:33:39 AM
 #418

That means they have to create accounts with bitfountain or weexchange. I doubt they will be happy doing this because it would be the same like creating an account for liberty reserve. They would have to load up money to the site after registering too. So i dont see much advantage. I believe very few people will have an account there anyway. And when they have they would be able to pay with bitcoins too.
So paypal, alertpay or moneybookers dont have a ripple account right?

No, they wouldn't need to use btc. For Weexchange, they could use AUD or USD, for Bitstamp I think they could use USD or EUR.


Use CoinBR to trade bitcoin stocks: CoinBR.com

The best place for betting with bitcoin: BitBet.us
Beepbop
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
April 05, 2013, 12:52:36 AM
 #419

They would need an account on an exhcange, or have enough credit with a friend or friend-of-a-friend who has an account on the exchange.

Ripple does provide a bitcoin-like way to transfer USD, EUR and other currencies, but at the moment they would need both a Ripple account and an exchange account to get started with paying, so it doesn't really make things simpler for them, or you.

As more gateways and web stores using Ripple come into being, this should become easier for both end users and merchants, since integrated solutions would be offered, like web stores that both sell products, sell IOUs, offer a Ripple client, and takes care of transaction costs behind the scenes by quoting them in USD or including them in the shipping and handling fee, and automatically aquiring the needed XRPs on the user's behalf.
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1004


Democracy is vulnerable to a 51% attack.


View Profile WWW
April 05, 2013, 01:14:12 AM
 #420

Thanks for the link. The tl;dr is that they can't easily do what I asked about - they could limit who holds their IOUs, but it seems the only way to prevent people from rippling their IOUs for ToS-breaking transactions is to watch how their IOUs move through the network and ban any users who facilitate those transactions after the fact. (A bit like how Dwolla is closing down accounts which are used for BTC transactions.)
In principle, they can have any redemption agreements with their customers that they want. But if they insist on terms like "we can refuse to redeem anytime we want for any reason" (and they actually start exercising that right capriciously) they'll start to reduce their own value drastically. Nobody's going to want to deposit $100 and get a balance that's worth significantly less than that. Nobody's going to want to accept a balance at a gateway in good faith reliance on their redemption agreement and have to worry about the gateway refusing to redeem that balance. Gateways will have to work out their policies and we hope competition and ingenuity will produce a wonderful result.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!