Giter Site home page Giter Site logo

fellowtraveler / open-transactions-old Goto Github PK

View Code? Open in Web Editor NEW
409.0 73.0 91.0 47.13 MB

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.

Home Page: http://opentransactions.org

Shell 0.04% C++ 85.41% Objective-C 1.83% C 3.43% C# 2.14% PHP 1.09% Python 0.96% JavaScript 0.17% D 2.28% Go 0.89% Java 1.44% Perl 0.33%

open-transactions-old's Introduction

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, free-software toolkit implementing the OTX protocol as well as a full-strength financial cryptography library, API, CLI, and prototype server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

Please see the official wiki: http://opentransactions.org/

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 receipts are destructible and redundant. The transactions are unforgeable. The cash is untraceable. The cheques are non-repudiable. Etc.

This product includes software developed by Ben Laurie for use in the Lucre project.

open-transactions-old's People

Contributors

albertocabello avatar bluewall avatar da2ce7 avatar fellowtraveler avatar klzns avatar martinhbramwell avatar matthewholt3 avatar paulrd avatar thosmos avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

open-transactions-old's Issues

Implement Ripple based on my notes

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.

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.

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

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.)

  1. 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.

  2. 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:

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

  4. 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.)

  5. For Bob, Carol, Edward, etc, she sees THEIR balances in aUSD:

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

  • Bob: $A 0
  • Carol: $A 1000
  • Donald: $A 500
  • Edward: $A 500

  1. She also sees HER balances in bUSD/cUSD/dUSD/eUSD:

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

  • Bob: $A 0 Bob owes Alice: $0 bUSD
  • Carol: $A 1000 Carol owes Alice: $877 cUSD
  • Donald: $A 500 Donald owes Alice: $142 dUSD
  • Edward: $A 500 Edward owes Alice: $905 eUSD

Total owed BY Alice: $2000

Total owed TO Alice: $1924

Net: Alice owes $76.


  1. 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.)


  1. THEREFORE our total picture now looks like this:

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

  • Bob: $A 0 Bob owes Alice: $0 bUSD
  • Carol: $A 1000 Carol owes Alice: $877 cUSD
  • Donald: $A 500 Donald owes Alice: $142 dUSD
  • Edward: $A 500 Edward owes Alice: $905 eUSD

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


  1. 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 ----------------

  • Bob: $A 0 Bob owes Alice: $50 bUSD *
  • Carol: $A 1000 Carol owes Alice: $877 cUSD
  • Donald: $A 500 Donald owes Alice: $142 dUSD
  • Edward: $A 500 Edward owes Alice: $905 eUSD

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?

Node.js API

Node.js is javascript for the server-side, essentially, with a lot of extremely attractive features, running on Google's V8 js engine. I don't want this to be a huge priority or anything since it could be a while before I use it, but the three things on the top of my list to develop with are node, couchdb, and open transactions, and I've got a little pet project going with the former two.

I'd love to toy OT as the backend for a payment gateway whenever I get that far on it. The PHP api is great, I already do PHP professionally, so don't feel like this is a must have, but if you'd like to kick around something hip and new I'd love to see a JS-native API as well. I can always write a little php socket server to handle things too.

Review all datafiles / start encrypting them

Currently the Nym file, since it's not derived from OTContract, is saved to local storage via OTSignedFile.

I plan to extend this mechanism to OTEncryptedFile.

Then need to review ALL the files in the system, on client and server side, and make sure they are encrypted appropriately.

Currently most data is clear (but signed). There are a few weak links, most notably wallet.xml and notaryServer.xml.

Soon it should all be encrypted. This is all connected also to adding the password callback for OpenSSL. Up until now I've been using the test password, but now with the GUI working, and with people building stuff with the API, it's necessary to encrypt the files and use the passwords.

Need to add digital cheques

The system supports transfers as well as cash, but it doesn't support cheques (yet.)

This is actually simple to implement, but it adds some cool functionality, such as the ability to give out vouchers where you keep the money if they are never redeemed. (With cash you would lose the money.) Cheques can also have expiration dates on them, just like paper cheques.

And checks can be made out to specific people, or left blank.

The thought occurred to me... I have to sign the check in order to create it. And the recipient has to sign the check in order to deposit it. So why not just use the transfer system? (I sign a request, goes into my outbox and his inbox, then he signs his own request to accept my transfer. Both signatures are received here as well.)

THE DIFFERENCE is that with a transfer, the money comes out of my account immediately. Whereas with a check, it only comes out when it is cashed. Perhaps the cheque will never be cashed, and the money will stay in my account. Perhaps the cheque will expire. Perhaps it was just a coupon.

The other big difference is, a record is created on the server when I make the transfer request, whereas with a check, there's no need for me to contact the server at all. I just hand it over to the recipient, and no record will be created until he DEPOSITS the cheque. This may seem like a small difference, and the accounts are all numbered anyway yadda yadda yadda but it's still significant.

Another interesting thing about cheques is that a receipt is created when it's deposited. The server will send a copy of the cashed check into my inbox (for my records.) I do not get this same sort of receipt when I pay someone in cash. (I DO get a similar receipt when doing an online transfer.)

Add multiple-signers for asset accounts

Asset account should have a list of signers instead of a single Nym.
Asset account should have an integer denoting how many signers are necessary to perform a transaction.
If that integer is 1, then ANY of the signers can perform a transaction.
If that integer is >1, then when a single signer performs a transaction, it goes into the inbox for that account. (Awaiting further signatures.)
Any of the other signers on that account can get the inbox, downloading the transaction request and choosing whether or not to add their own signature.
Once there are enough signatures, the transaction is processed.

Transaction numbers are real, and they are really used, but they are not verified properly.

Will probably put these in the spent token database since the concept is identical. Right now the server is checking the transaction numbers only to see that they are lower than the most recent one issued (which is wrong, but matches the Request Number functionality.) Now that the client is actually requesting and receiving real transaction numbers, and serializing them, we might as well start verifying them, too.

Also will probably institute version for both, since that allows us to maintain a 1 month DB or a 6 month DB, which is perfectly reasonable, (instead of having to maintain a massive DB that grows forever, the loss of which would destroy the cash float.)

encrypt cheque memos (if there's a recipient)

Encrypt cheque memos (if there's a recipient)

But if there's NOT a recipient, then leave it base64-encoded like it is now.

Also need to encrypt transfer notes for the same reason. There's no reason for the server to have access to that data. Only the users on each side.

testwallet/API compiling csharp / python

I have been trying to build the csharp and python client api on OpenSUSE 11.3 and 11.4 . I have been running into a couple of things that prevent me from building it.

With the python api, I needed to add an include path -I/usr/include/python, which is odd because I have /usr/include/python2.6. and am running python 2.6.5. The build system is getting python2.5 somehow. After that, it starts building, but I get this: http://pastebin.com/1ejzz5Ar

Building csharp gives: http://pastebin.com/Xm3E44Ki

Patents?

are any of the technologies used in this software under patent protection?

Standing Orders

Hmm another thought. If I'm going to cash it myself anyway (on the last day before expiration, in case the recipient hasn't cashed it) then I might as well put a standing order with the bank to process a certain transaction on a certain date. "In 90 days, cash this check."

These "standing orders" would simply be requests to process a transaction at a certain time, paid in advance. You can cancel the transaction but the bank keeps the payment!

Standing orders would be processed first, before other orders.

You get the benefit of guaranteed processing on a certain date, with priority over other transactions, and the bank gets the benefit of the transaction fee paid in advance.

Add "Stop Payment" for cheques

Normally a cheque instantly takes the funds from your account (because you've already signed off on it.) So ANYTIME, that cheque could come through and hit your account a BAM, the money disappears.

The only way to prevent this would be to place a "STOP PAYMENT" on the transaction number for that cheque. (Which you used when you first wrote the cheque.) This "stop payment" is basically just a ledger item in my inbox. When the cheque is cashed, the server would scan my inbox for that ledger item before actually removing the funds. When it sees there is a "stop payment" for that cheque, it refuses the transaction.

This is cool because people use cheques in real life already knowing up front that the person writing the cheque always has the option to stop payment up until the time that you actually cash it and get the money in hand.

Add a "Digital Space" like Loom

This is like Loom. Basically add an API function where any client can access a virtual location (by hash ID) for units of any specific asset type (by asset type ID.)

The client's wallet will contain a list of these virtual locations.

If you want to send assets to another user, your wallet simply requests a random location ID, moves the assets to that location, and then sends the location ID to the recipient. The recipient's wallet moves the digital assets from the location ID you sent, to a new location ID that is known only to him. (His wallet has a list of virtual locations, just as yours does.)

I probably won't get to this for a long term (if ever) but I think it would be cool to have this functionality built into the library someday.

Add "Request Invoice"

Alice is at Bob's store and she wants to buy a carton of eggs. She scans the barcode with her android phone, and her wallet software promptly sends Bob a REQUEST INVOICE for the product ID.

This "request invoice" goes into Bob's inbox. The cashier pulls up the inbox, filtered for Alice, and processes the invoice, which attaches the right price and then sends to Alice's inbox. (And Bob's outbox.)

When Alice does a "get inbox", she receives the invoice. She clicks "approve" or "accept" and the money is processed from her account to Bob's.

IN PRACTICE, Alice scans her various items as she adds them to her cart. Then she hits "checkout" when she is standing in front of the cashier (sending the invoice request). The cashier says, "That will be $138." (sending the invoice.) Alice clicks "I approve" (authorizing payment, which is transacted.) All done.

Add message to exchange tokens for other tokens

Would this really be any different than depositing and immediately withdrawing again?

Really?

Except the exchange wouldn't require a user account, but even then it would still need a public key so it could write the user back, and that's all a user account really is, anyway.

add cashier's cheques

money comes out of user's acct and goes to bank's acct. Bank then issues normal cheque to recipient. If cheque expires, bank keeps money.
The cheque itself is also its own receipt. As long as you have a copy, you can always cash it yourself if your recipient doesn't.

A smart wallet software will keep track of all issued checks and DO THIS AUTOMATICALLY so the money doesn't go back to the bank.

(Of course you could have used a different instrument but....)

make java on Ubuntu

having trouble with

make java

on Ubuntu 10.x

I think you've got it set up to use the open source JDK rather than the Sun JDK. It is highly preferable to use the Sun JDK. I don't know how the open source JDK might behave and most likely finding out is going to be costly and tedious exercise. Where do you set the -I option for gcc in the Makefile? can I edit that?

Change basket exchanges to a transaction

Currently basket exchanges are handled as a simple server message. They must be changed to be real transactions, with balance agreement OR with receipts (that will require balance agreement). Either way, need to get sign-off on the balance changes like with any other transaction, and baskets are not immune to this requirement.

Might need to do a similar thing for the "Cancel Market Order" message...

using Cash functions

Im also somewhat unclear on how the cash functions work... can you show me an example?

Need code to convert PGP Private Key to OpenSSL format

We are currently converting PGP Public Keys, which means they are good on contracts.

But for the user to connect with a PGP key instead of OpenSSL, we need to be able to convert PGP PRIVATE keys to OpenSSL as well. Need to find some code that will do this.

Add a message validation server.

There should be a front server that performs certain message validation, for security reasons.

VoucherSafe seems to have a front server that manages the user accounts, and a "voucher publisher" server where the tokens are signed and exchanged. (OT does this in a single server.)

THAT's when I realized, couldn't OT work in that exact fashion???

Couldn't I put up an OT server that ONLY issues notes, and another OT server that ONLY manages accounts?

and have one manage all the users, and have the other process certain messages on behalf of the first?

in effect, just putting up two copies of OT — and replicating the VoucherSafe system?
It would still require a modification to store the actual serial numbered notes, but I think that's about it...

Basically look at my Fully-Anonymous diagram. The "cash-only" interface would be the first OT server, managing the accounts, and then the other OT server would be the main server.

then add the modification for tracking serial numbers, and it seems the same as Voucher Safe, no?

The key is not in the technical setup itself — it's more of a configuration issue — the KEY is in how you structure the entities, just like you would structure corporate entities. Same science.

Verify token has been unblinded...

Re: [Lucrative-L] double spends, identity agnosticism, and Lucrative
Fri, 20 May 2005 19:44:12 -0700

James A. Donald wrote:
From: "Patrick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Lucrative-L] double spends, identity agnosticism, and
Lucrative Date: Tue, 29 Apr 2003 14:46:48 -0600 Importance: Normal
Sender: [EMAIL PROTECTED]

A quick experiment has confirmed the obvious: when a client
reissues a coin at the mint, both the blinded and its unblinded cousin
are valid instruments to the Lucrative mint.

Example: Alice uses the Mint's API to reissue a one-dollar note,
blinding the coin before getting a signature, and unblinding the
signature afterwards. She's left with both a blinded and a non-blinded
version of the coin. The mint believes they are both valid. Instant,
unlimited inflation.

I believe the solution to this is to have the mint track both
spent coins and issued coins (that is, it automatically cancels coins
it issues, before the client receives them). The client is left with
no choice but to go through a blinding and unblinding process in order
to have a usable coin.

This seems to make identity-agnostic cash difficult or
impossible, at least with Lucrative:
http://www.io.com/~cman/agnostic.html,
http://cypherpunks.venona.com/date/1995/09/msg00197.html .

Laurie responds:

Would do if it were true - this is exactly why unblinded lucre coins have structure - that is, you can check that they are well-formed by doing hash operations on them. Blinded coins will fail these checks.

I forget the exact form of lucre coins (read the paper), but consider the construction x || H(x) - clearly only the unblinded version of this will have the right form.

Server should store the last Client Balance Agreement

Maybe this should be stored in the outbox. Because I was thinking, for digital checks, there can't be balance agreement, since the balance may change before the check is cashed. The client may have agreed to the balance change, but he won't know what the new balance will be when the check is cashed, because he can't predict that.
Option 1) Put the outgoing check money in the outbox. That way, I've signed off on it, agreed to the balance, and then whenever the recipient cashes it, he agrees to HIS new balance and it also comes out of my outbox. Anytime up until then, I can cancel the check and it reverses it back into my account.
Option 2) Make it a real check. I sign off on it, though I don't know what the new balance will be. But meanwhile, the server will store the last signed balance in a balance file, which is always signed by the client. (It will be one of the transaction item types.) Whenever one of my checks is CASHED (or deposited), it gets added to that SAME balance file. (And it ALSO has my signature on it, just like the balance agreement transaction item does.)
By subtracting the amount of each check in that file, from the balance that's also in that file, (all of those items have my signature on them) the server should be able to prove the balance that's in the account file. Nifty! Actually perhaps I will put all of this in the INBOX! Just put a balance record in the inbox, plus the cashed checks. Then it's up to the user to process his inbox and accept each of the check items, thus agreeing to the new balance as a result. It's in the user's interest to accept the check items, because otherwise they will just build up on the server, storing up a financial history of his transactions that otherwise would have been destroyed. The server is protected because at all times, it has either the user's signature on the balance alone, or the user's signature on the last balance before the checks came in, plus the user's signature on the checks themselves.

Need to add payment requests

I should be able to put a payment request into someone's inbox. When they display their inbox, they choose to accept it (which pays me) or reject it (which sends me a rejection receipt.)

Smaller ID size officially needed (for Windows)

I haven't experienced this problem on Windows, probably since I use Parallels, but other Windows users have reported the IDs are officially too big to work with the filesystem.

The current SAMY hash output is 512 bits. (SAMY is an XOR of the outputs of WHRLPOOL and SHA-512, which are both 512 bits == 64 bytes.)

Each byte stores from 0000 0000 to 1111 1111, which is 0 to 255. To represent on the screen, I cannot use decimal, unless I want to use 3 spaces on the screen for each byte.

In hex: 0x00 to 0xFF takes up 2 spaces on the screen for each byte. That's 128 bytes per ID.
(Some Windows machines are having trouble with this.)

Looks like I'm going to need to start using Base62...

Get user feedback: Lua in contracts...

I realized that Lua code can be added inside the contracts, based on a standard interface, with access to certain standard objects (read-only or whatever). When those parts of the contracts are activated, the appropriate data objects can be passed into the Lua code. Certainly custom rules can be added to contracts by this mechanism (especially those that return true/false.) There is a whole level of business intelligence that can be added at this layer, without changing any of the code inside OT itself.

I need to get user feedback on how they would use this feature, so that I can define the interface clearly. (So that Lua functions implementing that standard interface can be added to the contracts.)

Store a Total for each asset type

Whenever any account is debited or credited, the system should also debit or credit a global running total of digital assets outstanding for each asset type that has been issued on the server.
(Disregarding issuer accounts, which go negative and would result in a 0 overall amount for all currencies.)

This number should be compared to the issuer's negative balance (they should be the same, other than the difference in sign.) Put another way, the two added together should equal zero.

If they do NOT, it signals a huge error: somehow there are more digital assets of that type in circulation than were ever issued!! This should never happen.

The server could be programmed to check for this situation before every transaction, and to automatically put a halt on any transactions that would otherwise occur for the affected asset type.

Any user should be able to query the server for a specific asset type and see these two numbers (the issuer's balance versus the balance of all the account credits.)

They should also be able to query the issuer (on a separate server), IMO, referencing the transaction server ID, and verify from the issuer himself the same number.

Of course issuers will still need bonds and audits, and server operators will still need bonds and code audits, and fingerprints, and reputation, etc. You still trust these entities and are vulnerable to them (though Open Transactions endeavors to distribute the risk). But these numbers help the users to stay on top of the server operator, as well as help the issuer to stay on top of him as well.

SECURITY NOTES

For certain critical factors, such as serialization, any data could be compromised and the server needs to be able to handle it gracefully. Therefore need to heavily test sending crappy data to the server to make sure everything is validated properly.

Serialization is mainly found in two methods: UpdateContents, and ProcessXMLNode. If we ever switch to another XML library, ProcessXMLNode is where any changes will be made.

serial numbered bars of gold

It's possible for items to be identical, yet still have a serial number. For example, a vault full of gold bars, all of them with a different serial number. It would be cool to add an instrument to provide this functionality digitally.

re-occurring billing

Merchant should be able to send a standing order to the customer. Customer signs the order, and it goes into effect. (The order goes into the customer's outbox, as well as the merchant's inbox AND the server's tracking object, where it is then processed regularly according to its rules.)

Need this information to process it regularly:

  1. Initial payment date. (X number of days from purchase date.)
  2. Initial payment amount.
  3. Re-occurring payments start date. (Y number of days from purchase date.)
  4. Re-occurring payment amount.
  5. Re-occurring period. (Z number of days between payments.)

compilation problem on Ubuntu x64

get this when I compile java api ( make java ):

/usr/bin/ld: ../xmlrpcpp//libXmlRpc.a(XmlRpcClient.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC

Server-to-Server Contracts

Thinking about the low trust servers that I saw Fellow Traveler post on the bitcoin forum, I have come up with a second proposal-- Server-to-Server Contracts.

I remembered the diagram of the federation of servers so I believe programming in server contract replication between contracted server would allow the low trust behavior. If a server goes offline that has contracts with other server owner(s) then the server owner(s) would be able to process the transactions in place of that server.

To create this scenario a server would need to replicate its server transactions after each complete transaction.

Keep track of server's money

Need to make a class that keeps track of all the server money. Specifically, it should
keep track of all the account IDs that are owned by the server. Secondly, it should keep
track of all expired cash funds and moved them to server operating accounts. Thirdly,
it should keep track of all voucher cash accounts and vouchers, and move expired
voucher funds to server operating accounts. Fourth, it should regularly process the inbox
of all voucher accounts so they don't grow infinitely in size as vouchers are cashed.

Throttling on # of API calls; Usage Fees and Credits

Need to add throttling of API calls, based on:

  1. Number of API calls per second(s). Have a Map in the main loop that stores this across 2 or 3 heartbeats for all NymIDs.

  2. Number of API calls per day. Use a map storing a count indexed by NymID.

  3. Usage credits!! (Transaction fees!!!) Also need option for unlimited usage credits (for internal server accounts, for example.)

Need new Messages:
-- Set-Usage-Credits-on-Nym. This message must be signed by an Admin NymID that will be listed in the server's config file.
-- Get-Usage-Credits-on-Nym. This message must be signed by the Admin NymID from the server's config file, OR it can also be signed by the NYM IN QUESTION. (So he can look up his own usage credits.)
-- Should also be an "Add To Usage Credits" function. That's more practical.

ONCE Usage Credits can be set, and once the throttling can be set to decrement Usage Credits with each API call, the transaction servers can now collect fees! The throttling will be configured in their config file, and then they can just sell usage credits for Bitcoins, or other OT currencies -- however they want to do it! Very easy!

Also note that Usage Credits are NOT a normal OT currency inside the server -- they are not transferrable, only the server operator can manipulate the value. They are also not convertible not markets into any other OT currency types. They are also not necessarily refundable. They are not meant to be used as a store of value, but only as a method for paying the transaction server. They may also be subject to various terms of the server operator's whim. They may expire, etc.

-- I need to put the exact prices (credits per API call) into the server contract itself, along with the location for purchasing said credits! Instead of the config file. Or in addition to.

-- I need to do some metrics and find out the average number of API calls for the various transactions, when Moneychanger is running. This way I can determine how many Usage Credits a person would need in a typical day or month.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.