-
Notifications
You must be signed in to change notification settings - Fork 0
UNTRACEABLE DIGITAL CASH? … FOR REAL?
> Is this the real stuff? With blinded tokens? As in, invented by David Chaum?
Yes, Open Transactions provides a full and working implementation of Chaumian blinded tokens. Specifically, the Wagner variant as implemented by Ben Laurie in his Lucre Project
Here’s an intro article on digital cash
EXPLAIN THE DIFFERENCE BETWEEN “NUMBERED ACCOUNTS” and “UNTRACEABLE” and “ANONYMOUS”
A user account is numbered (it consists of a PGP key), so in this respect, it is pseudonymous (meaning, transactions can be tied to each other, but not to your real-life identity, presuming you use I2P or Tor.) The benefits of pseudo-anonymity are that your online Pseudonym (or “Nym”) has the potential to gain reputation over time, and also, that many more instruments become possible when using accounts: Cheques, transfers, payment plans, markets with trades, etc. (See the diagram)
Whether you use an account or not, The digital cash instrument itself is always untraceable, either way. Meaning, the server can see that account# 38272 exchanged a token, but it doesn’t know what withdrawal the token originally came from, and it won’t know where and when it will eventually be spent. (Because tokens are blinded when the server signs them, and the server only sees a token’s ID after it has been redeemed.)
In fact, the server doesn’t even know if you’re just exchanging the same token over and over again because you’re bored. (To learn more about the mathematics, google about “Chaumian blinding”.)
Then by adding an HTTPS cash-only interface (for token exchange), you gain full anonymity (as long as the user connects over I2P). But of course, in this case the user cannot use accounts, cheques, transfers, or cashier’s cheques, since he is now operating “cash-only”.
By full anonymity, I mean that all token exchanges, while already untraceable between the parties, are now additionally mixed with all of the other users’ token exchanges (which are also being performed at the same cash-only interface), since the same user account is used for all of them (a dummy server Nym). There is also no record of any account balance changing, since no asset account is needed to exchange a token… and your real-life identity is hidden when connecting over an anonymous network. Here’s a diagram of the fully-anonymous operation of OT.
If the OT server itself is running on a network such as I2P, then the server may also choose to hide its identity and physical location, if it so chooses. Issuers may do the same. (Of course, this does not solve issues of trust.)
WHY DO YOU USE THE WORD “CASH” — ISN’T THAT CONFUSING?
Cash is the most accurate analogy.
When you withdraw cash from the bank, and then later someone else deposits it, the bank has a record of a withdrawal and a deposit, but they don’t know that it’s the SAME cash, and they don’t know who had it in between, or how many hands it passed through along the way. They simply can’t trace it. These traits are also true of digital cash.
The other digital financial instruments are much the same as their paper equivalents:
- account transfer (a PGP-signed message, given directly to the bank, transferring funds to some other account),
- digital cheque (a signed message, given to the recipient, authorizing bank to transfer funds when presented),
- digital vouchers (like a cashier’s cheque. Funds are transferred to bank, who then issues a cheque. Bank becomes payer.),
- digital cash (Like a real cash withdrawal. Funds are transferred to bank, who then issues blinded, untraceable, bearer certificates),
New: 2-way trades and re-occurring billing are also now functional!
Remember, physical cash is not the actual value, it is only a transfer mechanism. YOU have to trust your government that your physical cash is backed with real value. (Whether that is gold, or silver, or “their full faith and credit” or whatever they claim that their currency is backed with.)
Digital cash is ALSO NOT actual value, it is ONLY a transfer mechanism. YOU have to trust the issuer of that cash, and the contract he used to issue it, and decide whether you trust that it is backed with real value. There is no escaping this basic fact (of electronic trading of any good) — someone has to store the actual gold, or whatever it is, that supplies the actual backing value to the currency.
And that is why Open Transactions is designed as best possible to distribute risk across multiple issuers (through basket currencies) as well as distributing risk in other ways (across a federation of transaction servers, across a diversity of jurisdictions, etc)
In Open Transactions, anyone can issue a currency. But the users still decide what they want to trade and who they want to trust.
So I can just give myself 1000000000000 Weaselbucks and then I can pay you in weaselbucks?
Maybe I just don’t get it.
Most users will not issue any currency — they will merely trade in established currencies, or baskets of those currencies. But anyone could issue a currency if he wanted to — and the market ultimately decides which currencies actually get used. Most likely the currency people will choose to trade in will be some sort of Pecunix or other digital gold currency, not “weaselbucks.”
In Open Transactions, you can issue a currency onto multiple transaction servers (as many as you want.) A single currency can also have multiple issuers (via using basket currencies.) Users may choose to distribute their funds across a multiplicity of servers in a diversity of locations. A user’s wallet software could even be written to have a list of servers, and do this distribution automatically.
Imagine an eco-system with various different entities…
Open Transactions is the software for the transaction server.
Anyone choosing to act as an issuer could connect to such a transaction server and issue a currency. (Or even operate his own server.)
MOREOVER, there will be a multiplicity of issuers and transaction servers, all operating in a diversity of jurisdictions. This is like the concept of “Federated Software” such as that proposed by the Diaspora project.
There are other entities in this eco-system as well. The exchange companies in the local markets perform the work of exchanging digital currencies for the local “coin of the realm.” The exchanger, for you, might be your local coin shop. (Exchangers always pop up wherever there are multiple currencies. You could even buy chinese video game money right now, if you wanted to.)
Digital currencies such as Pecunix, E-Gold (or Bitcoin) could all be used as backing for currencies issued on Open Transactions. It’s all up to the issuer, who may or may not also be one of those entities. Users will take advantage of baskets in order to distribute risk across their favorite issuers.
HOW DOES THE CASH WORK?
If you Google about “untraceable digital cash” you will find plenty of articles explaining it, including a good article from Wired.
In Open Transactions, when the client software withdraws cash, it constructs blinded prototokens and sends them to the server. The server debits the asset account, signs the prototokens, and then sends those tokens back to the client, who unblinds them. (Now they are now ready to spend.)
If you are an anonymous user connecting over Tor, then this step will occur through one of the server’s exchange accounts, over an HTTPS interface specially set up for cash exchanges. (Meaning, you don’t even need to have an account.)
Later, when the token is spent, the payee deposits it into his own account at the server. (Or exchanges it.) When he does, the server sees the Token ID for the first time; it has no way of tracing it back to the withdrawal. The server then stores the token ID into a spent token database, in order to prevent double-spending of the token.
You can see the full progression of the blinding code if you look here:
1) WITHDRAW (CREATE) PROTOTOKENS
OTClient.cpp:
else if (OTClient::notarizeWithdrawal == requestedCommand) // NOTARIZE WITHDRAWAL
2) SIGN PROTOTOKENS
OTServer.cpp:
void OTServer::NotarizeWithdrawal(OTPseudonym & theNym,
OTAccount theAccount, OTTransaction & tranIn, OTTransaction & tranOut)
3) UNBLIND TOKENS
OTClient.cpp:
void OTClient::ProcessWithdrawalResponse(OTTransaction & theTransaction,
OTServerConnection & theConnection, OTMessage & theReply)
[The tokens are ready to spend now, and untraceable. Later, the client
spends some tokens, by passing them to another wallet user. That payee
deposits the tokens to verify them (perhaps immediately withdrawing
again, if he just wants to exchange them for new ones.) The server has
no way of knowing where the tokens came from, since they were blinded
when they were issued. The server also has no way of knowing if the
tokens represent a new payment to me from someone else, or if I am
just exchanging and re-exchanging tokens that I already had, perhaps
to fix an approaching expiration date. Below this point, that payee is
now the client, since he now has the tokens…]
4) DEPOSIT TOKENS (IN PURSE)
OTClient.cpp:
else if (OTClient::notarizePurse == requestedCommand) // NOTARIZE PURSE (deposit)
5) VERIFY TOKENS
OTServer.cpp:
void OTServer::NotarizeDeposit(OTPseudonym & theNym, OTAccount & theAccount,
OTTransaction & tranIn, OTTransaction & tranOut)
Also I suggest reading the OTToken and OTMint classes to see the actual
Lucre calls being made.
Update: The Spent Token Database is now operational as well!
HOW DOES THIS COMPARE TO BITCOIN?
Bitcoin cannot be used for issuing commodity-backed currencies. On Open Transactions, anyone can issue a new currency by drawing up the currency contract and signing it. Any asset type can be issued in such a contract.
A transaction server like Open Transactions also makes possible various different instruments, such as cheques, vouchers, markets, and especially untraceable digital cash.
Bitcoin is more properly termed a commodity than a currency. Bitcoin could actually be used as backing for a currency issued on an Open Transactions server. In many ways Bitcoin would be ideal for this purpose, since it is fully decentralized and distributed, cannot be counterfeited, and since Bitcoin reserves are publicly-auditable.
OT clients will end up as p2p software, since they derive benefits from comparing notes on the servers. An OT client could be written that is simultaneously a Bitcoin node, and even also a Ripple node as well. In fact, over the long time I think it will also merge with anonymous networks. I think there is a lot of potential for development on the client/wallet/anonymous-node side where all these sorts of technologies will start to be tied together.
I would like to see the server side of OT become completely distributed as well. However, I expect that in the near future this picture will more closely resemble a federated system such as that proposed by Diaspora. Remember that even Tor has directory servers, as well as special bridge nodes and relay nodes. An Open Transactions server would be a similar service, and could run hidden on an anonymous network, and could even profit while doing so, since OT makes anonymous profits possible. More importantly, this means that digital cash software like OT can help solve problems of resource allocation on anonymous networks.
Bitcoin is curiously similar to gold — perfectly fungible, stores value in some esoteric way (so far), can’t be counterfeited, can’t be printed en masse by national governments…
Disadvantages of Bitcoin:
- More traceable (then again not EVERY instrument has to be untraceable)
- No choice of backing
With Bitcoin you can’t choose to issue a currency based on gold, or based on silver, or based on a basket of dollars, bitcoins, and gold. You are restricted to one backing: computing power. This is all well and good, and in fact I think it’s a really cool idea, but it also means that there will still be a demand for software that allows people to issue specific currency contracts and trade in them—especially if they have the option to do so untraceably.
One user from the Bitcoin forum had this idea:
Blinded cash issuers (using for example this system) and the bitcoin system could make a pretty good combination. It could be similar to how private banks kept gold reserves and issued bank notes:
- Use bitcoin or a modified bitcoin/RPOW/bitgold like system to create a securely auditable, unforgeable, public, non-anonymous “high power money” analogous to gold.
- Issuers (or “banks”) of securely anonymous (blinded) bank notes keep bitcoins as reserves. By analyzing their public bitcoin chains, any customer can audit the reserves of any of these issuers.
Those who don’t care about their privacy or who want to be issuers with trustworthy reserves can use bitcoins directly, while cash customers who like their privacy can use the securely anonymous blinded cash. That forms a two-tier system, analogous to the old privately issued money system that involved mining and storing gold (bitcoins) and issuing bank notes backed by gold (anonymous cash backed by bitcoin reserves).
The whole system could be far more secure than the old gold-reserve + banknote system, because the “gold” is more difficult to steal but far easier to securely audit, and the “bank notes” far harder to counterfeit and (especially against modern investigation techniques) more difficult to trace/identify users. The “gold window” for these banks could be far more secure from various threats than in the old private bank note issuers. And it’s all conveniently online.
So my take is to take advantage of the public and basically non-anonymous nature of bitcoin/RPOW type systems to securely audit people who claim to own X of them (such as currency issuers), while using blinded digital cash for transactions where privacy is more important than public audit.
HOW DOES THIS COMPARE TO E-GOLD OR PECUNIX?
The first big difference is that E-Gold and Pecunix are actual companies, whereas Open Transactions is merely a piece of software, that could be downloaded and used by anyone.
As far as I know, e-gold and other outfits like it specialize primarily in one specific instrument: account transfer. Not cheques or cash — only account transfer. (This means that none of them offer untraceable cash.)
Open Transactions supports account transfer, and digital cheques, and digital cash.
An outfit like Pecunix (btw, they are no relation to this project) could potentially use this software to issue cash backed in their gold. Also, there is nothing to prevent other, 3rd-party entities from issuing Pecunix or E-Gold backed currencies on an Open Transaction server. In that case, the issuer is merely a third party whose currency contract promises to be backed with [name your favorite digital gold currency].
In that case, people could simply connect to the server and trade those currencies, even without the direct involvement of entities such as E-Gold or Pecunix. It’s now between the trader, the server operator, and the issuer (and the exchanger.) Pecunix, in this scenario, would serve as the backing for the currency, but would have no direct involvement with the operation of the transaction server itself (or, even, with the issuer, since the two could deal through the various exchangers in the various local jurisdictions.)
HOW DOES OPEN TRANSACTIONS COMPARE TO LOOM?
Loom was what inspired me that the issuers could be a separate entity from the server operator. The issuer, on Loom, is just another user, who has decided to issue a new currency. There might be hundreds of different currencies issued on Loom. This separation of powers is also used in Open Transactions. Congratulations to Patrick Chkoreff for his excellent work in developing Loom
HOW DOES OPEN TRANSACTIONS COMPARE TO RIPPLE?
Ripple is a great idea from Ryan Fugger. The concept is that users can be socially networked
and issue credit to each other. This makes it possible for funds to “flow” through users so that two otherwise unrelated
parties, using two otherwise unrelated payment systems, can still send payments to each other, via a “six degrees of
separation” through a social network of mutual friends. (Sort of like Hawala.)
I believe that Ripple, or something like it, will be built into a future version of the client software for Open Transactions
(or something like it.) It’s just obviously on the horizon, as far as I can tell. This will allows users all over to send funds
into different payment systems without having to involve a central authority or do a wire transfer. Instead, the transfer
will just flow through other users and cut out any “banking system transfer” entirely.
With users incorporating such software, it will no longer even be necessary to add “server transfer” features to Open
Transactions. Users will do their own transfers using Ripple. I can’t wait to see the first really cool client software that
incorporates all of these ideas.
HOW DOES OPEN TRANSACTIONS COMPARE TO TRULEDGER (formerly TRUBANC)?
The Open Transactions protocol for account-to-account transfers is like the one in Truledger. Bill St. Clair made a big contribution with his work on Truledger
When using the ACCOUNT TRANSFER instrument (instead of cheques, or cash) these are the signatures that are received by all parties:
ALICE
- Alice gets the server’s signature on her transfer request (whether it is accepted or rejected, she still gets a signed receipt.)
- She gets Bob’s signature (in her inbox) accepting her transfer when he processes his own inbox.
- She also gets the server’s signature on that.
- She’ll also get the server’s signature on an agreement of balance at the same time.
BOB
- Bob gets Alice’s signature sending the original transfer, which appears in his inbox.
- He also has the server’s signature on that.
- Then, when he accepts her transfer, he will get a signed receipt from the server when his balance is updated.
- He will also have a signed balance agreement from the server at this time.
THE SERVER
- The server gets Alice’s signature on the transfer request.
- The server gets Bob’s signature accepting Alice’s transfer.
- The server gets Alice’s signature acknowledging Bob’s acceptance (when she removes his accept notice from her inbox.)
- The server will also have Alice AND Bob’s agreement on both of their balances, allowing the server to destroy any other records.
Not to complicate things, but on each of the above (on each balance agreement), there is also:
– a list of transaction numbers still outstanding (signed out by the Nym).
– a list of pending transactions, and signed receipts, awaiting approval in the inbox.
– …and a similar list of pending outgoings (in the outbox.)
You can see why we call it “TRIPLE SIGNED RECEIPTS” for account transfer!
For more info, check out Bill St. Clair’s document: http://truledger.com:8080/doc/plain-english.html
HOW DOES OPEN TRANSACTIONS COMPARE TO RICARDO BY SYSTEMICS?
Ian Grigg has commented that Open Transactions is along the same lines as Ricardo.
Open Transactions has definitely adopted the Ricardian Contract form, which is one of his innovations.
HOW DOES OPEN TRANSACTIONS COMPARE TO eCache?
eCache is an actual, anonymous internet bank, whereas Open Transactions is the sort of software that such a bank might run. (As a library, OT has many more uses than this, but this is a pretty good description for the OT server software.)
As far as I know, eCache supports a “Tor / HTTPS, Cash-Only Interface” like the one described in this FAQ, and their users exchange bearer tokens through it, backed in gold and other precious metals.
(What actual software they use over at eCache, and their math implementation, I have no idea — I haven’t seen their code.)
WHAT IF I WANT TO EXCHANGE TOKENS, BUT WITHOUT CREATING AN ACCOUNT?
This is easy: the server operator just provides an HTTPS interface where people can paste
their tokens and receive new ones. This way the super-paranoid people can still exchange
tokens all they want without creating an “account”. (Notice that it must be the server operator
who provides this interface, otherwise you now have to trust the interface provider.)
Keep in mind, that an “account” on an Open Transactions server is not like an account at
a bank. It’s just a communication key. It consists of ONLY a PGP public key — and its primary
purpose is so the server can encrypt your replies before sending them back to you. You can
open as many “accounts” as you wish, and each of these can open as many asset accounts
as you wish, and you can connect to them over Tor, and…
Here is the most critical part: even if you use an account, which you don’t have to do, digital
cash is STILL UNTRACEABLE. The blinded tokens can be withdrawn and deposited at will,
(in fact that’s all an exchange is) and the server cannot trace where they came from or who
you will spend them to. Cash is like this whether you use an account or not.
In fact, even if you exchange a thousand tokens, the server doesn’t even know whether
you are just exchanging the same token over and over again a thousand times or whether
it is actually a new token each time. And it has no idea where it came from.
IS OT “DISTRIBUTED” or “FEDERATED” or “P2P” or “CLIENT/SERVER” …OR WHAT?
OT, at a basic level, is client/server. (There must be a signer in order to have untraceable cash.) Contrast this with fully distributed digital commodities, like Bitcoin, which rely on block chains and therefore cannot be untraceable.
However, OT will end up with P2P Clients and Federated Servers. Here’s why:
On the server side, my vision for OT is of FEDERATED servers, similar to DIASPORA or the FREEDOM BOX. That is, many servers, operated by separate entities, forming a single eco-system for all, but with no central point of failure. Just like Diaspora. (And those servers could run on anonymous networks. In the past, anonymous servers had no way of receiving payment, and thus remained the realm of enthusiasts and hobbyists—but OT solves this.)
This is already becoming the case. For example, Loom is operational, and we know it will not be the only transaction server in the world. Thus the same issuers will undoubtably issue the same digital assets on Loom AND other transaction servers simultaneously. Therefore we can already see that there will be multiple issuers, and multiple transaction servers, and that these separate entities will operate in a diversity of jurisdictions, and indeed this is already what is happening.
Because the SAME digital asset types, from the SAME issuer, will be available on MORE THAN ONE server, this means that transfers from server to server can be directly negotiated by the issuers directly, as well as by the users (via a Ripple-like protocol.) In other words, cutting the transaction servers themselves out of the loop.
For example, if I wanted to move some FT-Gold from Server A to Server B, then I don’t have to involve Server A or B directly. Instead, I just make the request to FT-Gold, and THEY do the transfer, since they already exist at both ends.
Similarly, wallet users themselves can perform this function. They can even devise lists and rules about WHICH asset types they accept, and WHICH servers they trust, and how much of a cut they charge for exchange… allowing funds to “flow” p2p from user to user, even changing currency types along the way. (This is the whole idea behind Ryan Fugger’s Ripple system.) So if I have dollars, and I want to pay someone who only accepts gold, then the Ripple just finds a “6 degrees of separation” between us through our friends, and converts the currency as it ripples.
I think that servers can also directly negotiate transfers to other servers. (Since they both have signed receipts from the same issuer, they can potentially negotiate the transfer between each other, from server to server, and drop the receipts into the issuer’s accounts on both sides. This might require the issuer to run a server of his own for the transfer protocol to work, I have to think about it.)
This, btw, does NOT mean that the cash tokens from one server would be redeemable at another server. They would not: When a SPECIFIC TOKEN has been issued by a SPECIFIC SERVER, then that token must be REDEEMED at the SAME SERVER. This is because only that server knows for sure if the tokens are still good. But the funds can nevertheless flow rather easily between servers, as described above, once they have been redeemed.
ON THE CLIENT SIDE, the wallets ALSO NEED TO BE P2P!!!! This is because the wallets need to COMPARE NOTES with each other on the various servers, TO KEEP THE SERVERS HONEST.
For example, if a server gave you a different public mint file than it gave to the other users, then your cash — which you thought was untraceable — suddenly becomes fully traceable. Therefore your wallet has a strong incentive to compare its copy of the public mint file (or a hash of that file) with the same data of other wallets on the p2p network.
The wallets will also need to be p2p due to the “Ripple” possibilities outlined above. Users will automatically earn percentage cuts for money flows through their wallets, and centralized sources will no longer be necessary for “wire transfers” as they were in the 20th Century.
EVERY TRANSACTION must be accompanied by a signed receipt containing a balance agreement. This means that in the event of a dispute, or if any specific transaction server goes down, ALL OF THE USERS should be able to present their LATEST SIGNED RECEIPTS to the issuer, and recreate their accounts.
Since the cash is untraceable, it becomes possible for transaction servers to run, AT A PROFIT, anonymously and untraceably, on an anonymous network such as I2P. (Meaning, even though a server is NECESSARY, and I can’t currently get around that, it CAN BE HIDDEN, AND FEDERATED, and PAID FOR. Think of it like a Tor Directory Server or something.)
Just as the issuer on Loom does not actually operate the Loom server, so will the issuers who use various OT servers be able to operate independently of the server operation itself. Even unauthorized 3rd parties could issue their own “pecunix-backed” currency on an OT server(s) somewhere, if they wanted to—and it is up to the market to DECIDE WHO THEY TRUST.
A single currency can also be distributed across multiple issuers (using basket currencies.) A user might feel unsafe putting his currency in 100% pecunix. Perhaps he prefers 33% pecunix, 33% goldmoney, and 33% c-gold. That’s fine! Users can define baskets and trade them on markets, etc, and distribute a single currency across multiple issuers. Even a hundred or a thousand issuers! And the basket currencies do not take any additional system resources, they are just another asset type ID the same as any normal asset type.
Another example of risk distribution: A nice wallet software can be designed to automatically distribute funds across MULTIPLE SERVERS. The little “pile of gold” that I see on the screen might actually be distributed across 10 accounts on 10 different servers. But this is seamless for me (LIKE DIASPORA) since transfers are possible between the servers, since the same issuers are available on multiple servers.
For the user it’s as easy as making a list of the servers he trusts, and the asset types that he trusts, and the wallet can be programmed to DO THE REST AUTOMATICALLY.
So FYI, OT is NOT fully-distributed/p2p, and in fact cannot be so currently (the cash instrument needs a server somewhere in order to be untraceable), but it still has a vision for the DISTRIBUTION OF RISK and for solving THE NAPSTER PROBLEM (single point of failure.)
AN INVOICE IS JUST A NEGATIVE CHEQUE? PLEASE EXPLAIN.
If I write you a cheque for $50, and then you present it at the OT Server, (at that time selecting a specific account to deposit it to) then the server will take $50 out of my account (the one the cheque is drawn on), and put $50 into your selected account.
Whereas if I write you a cheque for -$50 (NEGATIVE 50!), and then you present it at the server (at that time selecting a specific account to pay it from), then the server will take $50 out of your selected account, and put it into my account (the one the invoice is drawn on.)
So it is the exact thing happening either way. The only difference is, when you use a negative amount, the functionality mirrors that of an invoice, so I decided to allow negative amounts on a cheque (the wallet software should know to display such instruments as invoices, as opposed to regular cheques, since it can see the amount.)
Negative transfers do not occur with any other instrument, such as payment plans, markets, cash, and account transfer. They are only allowed with cheques, because the functionality is so useful on both sides (and requires voluntary signing and submission on both sides in order to be processed, in any case…)
THE TRANSPORT LAYER…
— The Open Transactions library itself is entirely agnostic to transport! All messages serialize to a string and you can transport them however you wish.
— The Server, API, and Test Client currently support two different modes of transport:
(OTMessage→Xml-Rpc→HTTP), the preferred mode, and (OTMessage→TCP→SSL) which is the default mode.
— So yes, Open Transactions is available as a Web Service, and the library does all the heavy lifting of generating and processing the OTMessages.
— In most cases, the developers will make easy calls to the API, which abstracts away the lower-level HTTP calls (that are being made behind the scenes to transfer the messages.) Instead the developer uses higher-level functions like “Withdraw Cash” or “Write Cheque.”
WHAT DATABASE DOES OPEN TRANSACTIONS USE?
- Internally, the software uses signed XML contracts for all messages and all files,
so these contracts could be stored anywhere… distributed database, regular database,
filesystem… the server is agnostic to storage.
- All of the classes serialize to a STRING, which is currently stored to a FILE.
- There are folders for purse, nyms, certs, mints, accounts, etc. The filename is the ID (hash of the contract).
- This same folder/ID combination could also be used as the database key, with the same, signed-XML contents as the value.
(So “nyms/a6b123874ef2v1cc3.nym” could be the key in a table instead of a name on a filesystem.)
The current implementation of Open Transactions uses the file system.
- I assume this will eventually move towards some distributed db / data haven in the cloud.
(I would like to integrate with such a project. This is another great opportunity IMO —
integrating digital cash with distributed data stores and anonymous networks.)
- CouchDB seems like a great fit (field / value pairs). But I want this decision to be made
based on security considerations. Though it should be safe since everything is signed
and/or encrypted.
WHAT ABOUT CHAUM’S TRICK FOR IDENTIFYING THE DOUBLE-SPENDER?
> FellowTraveler, does your blinded digital money work like Chaum’s, in that a double-spend
> reveals the identity of the double-spender (in as much as a public key is an identity…)
The answer is NO. Let’s examine both the depositor, and the perpetrator.
Right now, Open Transactions does not store the User ID of the depositor. (Even if it did, this couldn’t prove who or where he got it from. Maybe he is just exchanging an old token before it expires. Maybe he is exchanging the same token over and over again for fun. Maybe he is exchanging a token for a friend. Etc.) If the token is good, the exchange will be successful and the user will be issued a new token, which only he knows the token ID of. At this point no one else can spend it but him.
But…if the user receives a token from someone, and tries to exchange it, and the server refuses it (because it was found in the spent token database — it had already been spent…) in THIS case, you clearly see the victim (at least, the PGP key that he uses to connect, if he’s not using the cash-only HTTPS interface, and maybe you can see his IP address, if he’s not using Tor.) But you cannot see the perpetrator who originally withdrew it. This is untraceable.
So what could be done?
What the server could do is leave a message in the inbox of the victims, warning them that a certain piece of cash they ALL tried to process was double-spent and fraudulent, and via this, try to find out the common source of the cash in real life, (if that was the server policy to do such a thing.)
Although this would likely lead to the perpetrator in real life, it will probably not ever be necessary.
In practice, this will not be a problem:
No one will ever accept cash in the first place without exchanging the tokens first to validate and secure them. In other words, if you are standing in front of me, or if I am selling to you online, I will obviously not accept your cash (or your purchase) if the cash doesn’t validate with the server. Instead, I’ll simply refuse the transaction.
Similarly, if you are somewhere else on the internet, then we are probably communicating through a “cash streaming protocol.” As soon as the little pieces of digital postage stop verifying, then I will stop serving you the high-speed anonymous download that you were doing through my computer’s anonymous network node.
HIGH LEVEL INTERFACE?
Open Transactions now supports a high-level interface. Here’s the breakdown of everything…
OTLib
The OTLib folder contains the core library, libOTLib.a, which includes most of the classes (but no transport code.)
You can link to this static library, but most will not. (OTLib is the “low level interface.”) If you do, just include whatever headers you need from the OTLib folder.
C API
On top of that, the testwallet folder can be built either as a command-line test client (testwallet.exe), OR as
ANOTHER library: libOTAPI.a, which includes the above lib PLUS the transport code and the C/C++ APIs.
Whenever you link to this static lib, include OTAPI.h for the C functions, and OpenTransactions.h for the C++ class.
SWIG wrappers in various languages…
You can also build the testwallet folder for other languages, like this:
make -f Makefile.API LANGUAGE=perl5 TRANSPORT=XmlRpc
make -f Makefile.API LANGUAGE=php5 TRANSPORT=XmlRpc
make -f Makefile.API LANGUAGE=java TRANSPORT=XmlRpc
make -f Makefile.API LANGUAGE=lisp TRANSPORT=XmlRpc
Etc.
There are also TOP-LEVEL build options:
cd Open-Transactions && make clean && make java
cd Open-Transactions && make clean && make perl5
cd Open-Transactions && make clean && make php5
cd Open-Transactions && make clean && make python
cd Open-Transactions && make clean && make ruby
Etc.
The appropriate dynamic library will be built into the testwallet folder. There are usually helper classes. For example, to use the libotapi.so in java, you will probably use the testwallet/otapi.java file.
For all the languages, see the API instructions available here:
https://github.com/FellowTraveler/Open-Transactions/blob/master/testwallet/API-README.txt
I will be very responsive to developer needs on this high-level interface.
LINUX?
GOOD NEWS: Open Transactions is now available for Linux! Make sure you download the latest version of the code.
FreeBSD?
GOOD NEWS: Open Transactions is now available for FreeBSD!
WINDOWS?
GOOD NEWS: Open Transactions is now available for Windows!
ANDROID?
GOOD NEWS: Open Transactions is now available for Android!
All supported platforms come with easy makefiles, project files, and instructions.
RUBY / PYTHON / PHP / Java ?
Open Transactions now comes with Native APIs for:
Java, Ruby, Python, Perl, PHP, C, C++, Obj-C, C#, Tcl, and Lisp.
Open Transactions was written in C++ because Lucre itself is written in C++ and Java, and Open Transactions was originally conceived as a usable wrapper for Lucre. (Lucre is what does the actual math for the untraceable properties of the digital cash.)
How about portability?
The software now builds and runs on Mac OS X, FreeBSD, Linux, Android, and Windows.
It also comes with Native APIs for many languages (see above.)
HOW DO I USE IT WITH A RUBY PROJECT, OR PYTHON, OR JAVA?
See the API instructions available here:
https://github.com/FellowTraveler/Open-Transactions/blob/master/testwallet/API-README.txt
NOTE: I will be very responsive to developer requests regarding the API.
CAN YOU CONVERT THE LIBRARY TO C ?
> You deserve praise for Open-Transaction, a most valuable piece of
> work. Unfortunately however, for various software engineering reasons,
> (integration, portability, reliability, ease of verification…) it
> should have been a C (not C++) library. (If it was, I would probably
> start right now implementing something ‘operational’ based on it).
>
> My questions are:
> 1) would you consider turning main components of it into C?
> 2) would you assist someone attempting to do the same?
Thank you for your kind words.
I don’t think I could spend the time rewriting it in C unless there
was some money in it for me. (I just can’t afford to burn another 2
months of my life.)
However, it shouldn’t be too difficult to convert…
1) The library doesn’t use any exception handling — it’s all return values.
2) I would convert the class members to a struct.
3) I would convert the class methods to normal functions, with an
additional “this” pointer passed in (for the struct)
4) Have to make sure to call the constructor / destructor by hand
whenever a struct is created or deleted.
5) Is there anything else? Historically, C++ was processed into C code
before compilation, so it seems to me that you should actually be able
to download a TOOL that will convert the code FOR you. That would
probably be the fastest/easiest and would enable to keep the two
versions current with each other.
I see this software more as a standard than as an implementation; I’d
love to see different versions of it released in different languages,
I just can’t afford to write them all myself.
One more thing: I mainly wrote this code in order to make Lucre (the
blinded token portion) available for actual use (instead of just being
a demonstration of the math.) And the Lucre library (by Ben Laurie) is
also written in C++ (and Java.)
So Lucre itself would also need to be converted, whether by hand or using a tool.
NOTE: There is now a C function API that comes with Open Transactions.
WHAT ABOUT CHAUM’S CUT-AND-CHOOSE PROTOCOL?
The OTToken class was originally designed for cut-and-choose, because
I mistakenly thought it would be necessary with Lucre. You can read more
about that here.
Basically, Open Transactions does not need cut-and-choose in order to still
have effective blinding and thus, still be untraceable. However, the library DOES
support cut-and-choose, since it was originally designed under the assumption
that it would be necessary.
WHAT ABOUT BRANDS’ PROTOCOL? WHAT ABOUT XYZ PROTOCOL?
I would like to incorporate as many different digital cash protocols as possible
into this software. If you have some good code in C or C++, I would love to
check it out. I would like to see the community eventually add whatever new
protocols they wish to the software over time, so that it supports all the top
algorithms and protocols.
HOW DO I VIEW THE BASE64-ENCODED DATA THAT APPEARS IN THE FILES AND MESSAGES?
The data is always either encrypted, or just base64-encoded.
If the data is only base64-encoded, then type “decode” and paste the data.
Now hit enter and you will see the decoded contents.
But if the data is encrypted, it will probably start with 3 A’s (“AAA”).
Type “decrypt” on the command-line (testwallet).
Now paste the data and hit enter. The decrypted data will be displayed on your screen.
This will only work if the nym is loaded (as long as you have typed “load” you’ll be fine.)
HOW CAN THE SERVER OPERATOR MAKE MONEY?
- Transaction fees can easily be added, since transactions consist already of multiple items in a list.
- He can also make money from expired vouchers and expired cash, which both revert to the bank.
- He could issue a fractional reserve contract and make money from investments…
- UPDATE: See the Business Cases page for more on this…
I THINK THE GNU LICENSE IS TOO RESTRICTIVE…
I didn’t understand the GNU license very well until I started researching the best license to use for this software. Now that I have researched the issue, I’m a big fan of Stallman and the whole Free Software Movement. Here is the basic meaning of the Open Transactions license:
1) This software was written by me and therefore I start out owning all the rights to it.
2) I release it open source, so that YOU can use it too, for FREE.
3) You can download it, and read it, and run it, and modify it, and redistribute it, and have your own users, and even run your own commercial business based on it, and make MONEY off of it — and even keep all the money to yourself!
4) …But only under the condition that the code YOU write, using mine, is ALSO open source!
5) In this way, others may benefit from YOUR open source, just as you will benefit from THIS open source.
6) This GNU license is optional. If you don’t like it, you can always contact the developer and arrange for a different license.
7) The OT software is intended for an audience of users who may choose to run it in an anonymous and untraceable manner. Due to this, obviously, it won’t always be possible to enforce the license.
8) Also, if you develop software that uses Open Transactions, but your users download the two separately, then you are not bound by any of the license terms at all (only your users are.) For example, users of FireGPG must download GPG itself separately, and install that first, before they can download and install FireGPG. In this way, FireGPG is able to be offered under the Mozilla License, even though GPG itself is offered under the GNU license. This is because the FireGPG developer was not bound by the terms of the GPL, since users download the two separately.
Makes sense?
Everyone has their favorite license, just like everyone has their favorite language. I think GNU AGPL one is pretty fair and unrestrictive, and it’s supportive of any efforts to run OT servers. It also supports the free software movement while protecting the developer in cases where proprietary, closed-source outfits need to arrange a commercial license.
IMPORTANT SECURITY NOTE ON THE LICENSE: The GPL license is also an important security precaution, because it requires people to release their source code for any project that includes the Open Transactions library. Under other open-source licenses, anyone could download OT and incorporate it into closed-source projects, making it possible to skim or perform other skullduggery, on users’ computers where the open-source community could not audit and verify the quality of the code.
Imagine a fancy new anonymous p2p wallet and file-sharing software that you get for free, not realizing that it skims 1% of the resource allocation from your wallet and sends it back to the software developer. These things can happen when source is closed… And where OT is concerned, we’re talking about software that’s designed to transfer value securely and untraceably. People will have trouble trusting the name “Open Transactions” if they associate it with one scandal after another. The best solution is to force developers to open their code — just like GPG.