FellowTraveler / Open-Transactions-old

Open-Transactions democratizes financial and monetary actions. You can use it for issuing currencies/stock, paying dividends, creating asset accounts, sending/receiving digital cash, writing/depositing cheques, cashier's cheques, creating basket currencies, trading on markets, scripting custom agreements, recurring payments, escrow, etc. Open-Transactions uses strong crypto. The balances are unchangeable (even by a malicious server.) The receipt history is destructible. The transactions are unforgeable. The cash is unlinkable. The cheques are non-repudiable. Etc.
http://opentransactions.org
407 stars 84 forks source link

Implement Ripple based on my notes #50

Open FellowTraveler opened 12 years ago

FellowTraveler commented 12 years ago

Ripple Notes

You don't need to implement credit lines to implement ripple inside OT.

Ana and Bob issue their own OT dollars.

To represent the credit line, when Ana owes to Bob, he holds her currency (the amount of the debt)

When Bob owes to Ana, she holds his currency.

But they're currencies are not audited (not even backed by real stuff) and only the people who trust them will accept their currencies.

There you have credit lines.

Now you can use OT markets to exchange these IOUs (which is basically what Ripple does, maybe with other terminology).

If Ana wants to pay Charlie through "OT ripple", he has to get Charlie's currency, by trading intermediate IOUs

But she doesn't trust Charlie (nor other intermediaries, she only trusts Bob) and doesn't want to hold his currency. If she can get Charlie's currency and sell it for Charlie's receipt of payment at the same time, she doesn't take the risk of holding intermediary IOUs that belong to people that she doesn't trust.

The only change necessary for OT to have built in Ripple is to make possible to execute various trades atomically.

Alice, Bob, Timón, and FT issue each one their own digital currency.

The denomination is not very important, because it will only affect the exchange rate, that users will have to set manually anyway.

1)

Alice issues aUSDs that are accepted by her and Bob, because they're friends.

Bob issues bUSDs that are accepted by him, Alice and Timón.

Bob usually buys bread to Timón for bitcoins, and Timón sometimes accepts bUSDs.

Timón issues tHours that Bob accepts, because with them he can buy bUSDs (to settle debts with Timón) and bread.

FT issues fOz's (ounces of silver) that really keeps at home and that Timón accepts because he knows FT accepts 1 Oz per hour of programming labor.

2)

Now FT wants to buy a box full of apples from Alice, that see sells for 80 aUSDs.

Let's see the market:

Alice buys up to 100 bUSDs for aUSDs at a 1:1 rate

Bob buys up to 100 aUSDs for bUSDs at a 1:1 rate

Bob buys up to 10 tHours for bUSDs at a 1:10 rate

Timón buys up to 2.5 fOz's for tHours at a 1:4 rate

Tthe balances don't change, they're just putting an offer in the market. For example.

Alice buys up to 100 bUSDs for aUSDs at a 1:1 rate

Would be like an offer like this:

user=alice buying=bUSD, selling=aUSD, price=1, amount=100

3)

So FT could sell 2 fOz's for 8 tHours.

Then sell 8 tHours for 80 bUSDs.

Then sell 80 bUSDs for 80 aUSDs.

Then sell 80 aUSDs for a box full of apples.

But he doesn't want to keep stuck with bUSDs or tHours. Not even with aUSDs. He just wants a receipt from Alice.

That's why the payment described in 3 should be atomic.

What's described here is nothing but a ripple payment, no matter if it is not implemented through "lines of credit".

The market of personal currencies works the same way and also produces a credit network.

Balances before the transaction:

                aUSD       bUSD      tHours       fSLV

Alice 10,000 0 0 0

Bob 0 10,000 0 0

Timón 0 0 1,000 0

FellowTraveller 0 0 0 500

Balances after the transaction:

                aUSD       bUSD      tHours       fSLV

Alice 10,000 80 0 0

Bob 0 9,920 8 0

Timón 0 0 992 2

FellowTraveller 0 0 0 498


If you want it step by step, here it is (but remember we want it to occur atomically).

FT sells 2 fOz's for 8 tHours.

                aUSD       bUSD      tHours       fSLV

Alice 10,000 0 0 0

Bob 0 10,000 0 0

Timón 0 0 992 2

FellowTraveller 0 0 8 498

Then sell 8 tHours for 80 bUSDs.

                aUSD       bUSD      tHours       fSLV

Alice 10,000 0 0 0

Bob 0 9,920 8 0

Timón 0 0 992 2

FellowTraveller 0 80 0 498

Then sell 80 bUSDs for 80 aUSDs.

                aUSD       bUSD      tHours       fSLV

Alice 9,920 80 0 0

Bob 0 9,920 8 0

Timón 0 0 992 2

FellowTraveller 80 0 0 498

Then sell 80 aUSDs for a box full of apples.

                aUSD       bUSD      tHours       fSLV

Alice 10,000 80 0 0

Bob 0 9,920 8 0

Timón 0 0 992 2

FellowTraveller 0 0 0 498


WHAT IS A CREDIT LINE?

Alice opening a bUSD account and putting an offer "I buy up to 100 bUSD for aUSDs" is the equivalent of giving credit to Bob.


Would Alice and Bob see that there are actually two currencies (aUSD and bUSD) or would the UI be such that they only need to see them as "dollars", and they see that they are willing to accept dollars from each other?

They could see separately:

-How many dollars they have issued in total (how much they owe).

-How many dollars their neighbors have of their currency (how much they owe by user)

-How many dollars they have from their neighbors (how much each user owes them)

-How many dollars they have from other people in total (how much people owe them)

And the same for each denomination.


Alice opening a bUSD account and putting an offer "I buy up to 100 bUSD for aUSDs" is the equivalent of giving credit to Bob.

In the example, Bob never has aUSDs so he doesn't need an aUSD account.

For the credit line to become two-ways, Bob would need to open an aUSD and place an offer "I buy up to X aUSD for bUSDs".


So here might be the sequence in the user interface:

1) ALICE clicks "Give Credit to…" and then she selects "BOB" from a list.

2) BOB logs in the next day, with a message "Alice has extended credit to you in the amount of $100 USD. Do you accept?" (This means that some sort of message will be sent via the internal OT mail system, to facilitate this notification.)

3) When Bob clicks yes, then the software checks to see if Bob has already issued his own $USD currency. If not, then Bob's currency bUSD is automatically issued at this time. (Bob's "credit line" object will need to manage his issuer accounts for various currencies, as well as manage a list of his credit lines to and from other people, as well as his asset accounts from those people, as well as his bUSD internal asset account, as well as his Ripple market offers. This OTCreditLine object would need to be written.)

4) Alice's offer is created on the new aUSD/bUSD market: "I buy up to 100 bUSD for aUSDs at X:Y rate". (This could probably be done using a modified version of the existing OT market code, to enable to atomic transactions. This modified version would be specially for Ripple, due to the atomic-multi-step transactions.)

5) This means that aUSDs, Alice's own USD currency must ALSO be issued at this time, if they haven't been already.

6) This means that Y aUSDs (from X:Y) must actually be issued into existence by Alice at this same time. That is, not only is the currency in existence, but say, 100 units of that currency are actually transferred at this time from Alice's aUSD issuer acct, leaving it at -100, to Alice's aUSD credit line account leaving it at +$100, so that they are actually available to fill her bUSD market offer, should a "Ripple path" transaction occur.

(This means Alice has an internal account balance of $100 aUSD.)

7) Unlike Bob's silver account, which is private to him, and unlike Bob's gold account, which is private to him, Alice can actually SEE the contents of Bob's aUSD account! Because that shows her how much USD that she owes to Bob. This is unlike the normal OT accounts, where you are not shown other people's balances.

8) On Alice's "Credit Lines" page, she would have a list of currencies (Dollars, Bitcoins, Silver, etc.) When she clicks on a currency, say dollars, the details appear on the right:

9) Details: a list of credit lines. Bob, Carol, Donald, Edward, etc.

10) Alice's "total dollars owed" is the absolute value of her aUSD issuer account. So if her aUSD issuer account has -$2000, then she owes $2000 to all of her various friends (in TOTAL.)

11) For Bob, Carol, Edward, etc, she sees THEIR balances in aUSD:

----------ALICE OWES THEM


12) She also sees HER balances in bUSD/cUSD/dUSD/eUSD:

---------ALICE OWES--------THEY OWE ALICE ----------------

Total owed BY Alice: $2000

Total owed TO Alice: $1924

Net: Alice owes $76.


13) Alice should also see the CURRENT STATUS of her MARKET OFFERS. Above we only see the account balances (what is owed both ways) but we don't see what people are willing to CONVERT.

Let's say Alice and Bob are willing to convert $100 both ways (for each other):

Alice: OFFER: "I buy up to 100 bUSD for aUSDs"

Alice: INTERNAL: $100 aUSD

(To trade $100, this means Alice has an internal account balance of $100 aUSD at least, and -$100 of her aUSD issuer account matches to this. Her market offers trade against this account.)

Bob: OFFER: "I buy up to 100 aUSD for bUSDs"

Bob: INTERNAL: $100 bUSD

(This means Bob has an internal account balance of $100 bUSD at least, and -$100 of his bUSD issuer account matches to this. His market offers trade against this account.)


14) THEREFORE our total picture now looks like this:

---------ALICE OWES--------THEY OWE ALICE ----------------

Total owed BY Alice: $2000

Total owed TO Alice: $1924

Net: Alice owes $76.

Alice: OFFER: "I buy up to 100 bUSD for aUSDs"

Alice: INTERNAL: $100 aUSD

Bob: OFFER: "I buy up to 100 aUSD for bUSDs"

Bob: INTERNAL: $100 bUSD


15) Let's say a "Ripple" flows through and she converts HALF OF the bUSD she's willing to convert. How does our picture CHANGE?

---------ALICE OWES--------OWES ALICE ----------------

Total owed BY Alice: $2000

Total owed TO Alice: $1974

Net: Alice owes $26.

Alice: OFFER: "I buy up to 50 bUSD for aUSDs"

Alice: INTERNAL: $50 aUSD

Bob: OFFER: "I buy up to 100 aUSD for bUSDs"

Bob: INTERNAL: $100 bUSD

QUESTION: Should Bob be able to see how much is LEFT on Alice's offer?

That is: "Alice's bUSD acct contains $50, which you owe to her, and there is still $50 left on her total credit line to you (of $100.)"


NEXT QUESTION: How does this model ever CONVERT one currency to another?

SO FAR, the creation of a CREDIT LINE has only resulted in two-way USD relationships, or two-way Gold relationships, etc.

NOTHING in the above example shows where Alice converts Dollars to Gold, or Dollars to Bitcoin.

FOR EXAMPLE, Let's say Alice extends GOLD credit to Bob…

Even if Bob reciprocates, then they have 100g gold relationship both ways, completely with Alice's offer to buy bGold using aGold, and Bob's offer to buy aGold using bGold….

STILL this doesn't explain how dollars get converted into gold, EVEN THOUGH ALICE AND BOB BOTH DEAL IN DOLLARS AND BOTH DEAL IN GOLD.

===> It's not ENOUGH for Alice and Bob to handle both gold and dollars, and to extend credit to each other in gold and dollars. ON TOP OF THIS, Alice must also be willing to convert gold into dollars, and dollars into gold, AND THIS HAS NOTHING TO DO WITH HER CREDIT RELATIONSHIPS TO BOB OR TO ANYONE ELSE. Rather, it has more to do with her market judgments of the various currencies.

===>Therefore, there still needs to be ANOTHER page, where Alice can set up her CONVERSION RATIOS between gold=>dollars and dollars=>gold, and BTC=>dollars and dollars=>BTC, etc.

Does this make sense?

It seems to me that the "Ripple path" mechanism would need to make use of markets that included offers for the credit lines, as well as offers for the currency conversion, before it could operate properly.

Does that make sense?


FYI, this is a whole new batch of code to build -- it's not a small amount of work. It DOES build on top of the existing OT accounts, currencies, and markets--but not without a significant amount of additional coding to get it to that point.

ANOTHER QUESTION: Given the above charts, what is Alice's ACTUAL BALANCE? Like, what if she wants to spend dollars -- how many dollars will the system actually allow her to spend, and why?

FellowTraveler commented 12 years ago

Ryan Fugger:

On Mon, Sep 19, 2011 at 2:28 AM, Fellow Traveler f3llowtraveler@gmail.com wrote:

The only change necessary for OT to have built in Ripple is to make possible to execute various trades atomically.

Yes, plus the ability to find Ripple flow paths through the network to your desired payment recipients.

===>Therefore, there still needs to be ANOTHER page, where Alice can set up her CONVERSION RATIOS between gold=>dollars and dollars=>gold, and BTC=>dollars and dollars=>BTC, etc.

Does this make sense?

Yes.

It seems to me that the "Ripple path" mechanism would need to make use of markets that included offers for the credit lines, as well as offers for the currency conversion, before it could operate properly.

Does that make sense?

Yes.

ANOTHER QUESTION: Given the above charts, what is Alice's ACTUAL BALANCE? Like, what if she wants to spend dollars -- how many dollars will the system actually allow her to spend, and why?

You can just sum up the amount of available credit on all her credit lines, and convert that to dollars. But that doesn't really tell you much, the interesting number is how much she can transfer to any particular seller, which will be different for each seller. A useful Ripple marketplace would give her access to this information as she is browsing ads, and perhaps even filter ads so that she only sees ones for things she can actually buy.

Ryan

FellowTraveler commented 12 years ago

On Fri, Sep 23, 2011 at 5:59 AM, Fellow Traveler fellowtraveler@rayservers.net wrote:

On 9/19/11 10:14 AM, Ryan Fugger wrote:

On Mon, Sep 19, 2011 at 2:28 AM, Fellow Traveler f3llowtraveler@gmail.com wrote:

The only change necessary for OT to have built in Ripple is to make possible to execute various trades atomically.

Yes, plus the ability to find Ripple flow paths through the network to your desired payment recipients.

YOUR THOUGHTS on this part?

Seems to me that there'd be lots of accessing local storage, while trying to find the path.

Unless you have some sort of lookup table... But then there's a price to pay in ram.

-- Ah you probably did it as a stored procedure in your database. What kind of DB, and do you have a link to that code?

This is an example of a min-cost-max-flow problem, and there are many examples of algorithms out there. The implementation isn't necessarily that interesting until we start to worry about millions of users.

ANOTHER QUESTION: Given the above charts, what is Alice's ACTUAL BALANCE? Like, what if she wants to spend dollars -- how many dollars will the system actually allow her to spend, and why?

You can just sum up the amount of available credit on all her credit lines, and convert that to dollars. But that doesn't really tell you much, the interesting number is how much she can transfer to any particular seller, which will be different for each seller. A useful Ripple marketplace would give her access to this information as she is browsing ads, and perhaps even filter ads so that she only sees ones for things she can actually buy.

Ryan Okay.

So if I went to my "Ripple Pay" screen, and entered a recipient, AND a currency type, then it should be smart enough based on that for a read-only label to display the total amount I can send that person. As I change the recipient or currency type, then it recalculates that label each time.

Correct?

Sounds right.

Ryan