-
Notifications
You must be signed in to change notification settings - Fork 84
CENTRALIZED
The vision is not of a central server you must trust.
Rather, the vision is of federated servers you don’t have to trust.
My goal with Open-Transactions is for the servers to be able to run on anonymous networks. For this to work, that means the users must be able to trust the system, even if they do not trust the servers.
We must have LOW-TRUST SERVERS—and that is what I have been working towards. The combination of low-trust technology with untraceable cash is what will make it possible to run OT servers on anonymous networks, at a profit.
There are some big differences between Open-Transactions and the “typical centralized system”…
1) — A typical centralized system is fully-traceable. You are always under the watchful gaze of the “all-seeing eye”.
But on OPEN-TRANSACTIONS, blind signatures are employed, providing untraceable digital cash.
2) — The typical centralized system stores a simple number as your “account balance.”
The server could change your balance simply by changing that number, and you must trust the server not to change your balance, or steal your money. (Ironically, this is the case on all the Bitcoin-related exchange sites today.)
But an OPEN-TRANSACTIONS server cannot forge any transaction, nor can it change your balance without your signature. Even a malicious server cannot do these things!
How is this possible? Because your “account balance” on OT is whatever appears on your last receipt. And an OT server cannot sign any receipt unless you have first signed the initial request, since a full copy of that request must appear inside the receipt. Thus the server cannot falsify any receipt because the server cannot forge your signature on the request.
Therefore the OT server can never sign any balance, or transaction, that you have not signed first!
3) — A typical centralized system would have the ability to abscond with your Bitcoins or gold.
But an OPEN-TRANSACTIONS server cannot disappear with the reserves!
Why not? Because it doesn’t have any. (For Bitcoin, this will be done using voting pools on the blockchain, a feature which has not yet been coded. Scroll to the bottom of this page for a description of how it will work.)
OT follows a philosophy of “separation of powers”. Meaning, the issuer and the transaction server are separate entities. If, for example, your currency is backed in gold, then it is the gold issuer you must trust, not the OT transaction server. Even if an OT transaction server disappears into the night, you still have your account (i.e. the last receipt) and you can still redeem it at your issuer or have it re-issued onto a new transaction server.
The same will soon be true with Bitcoin: I have been cooperating with certain Bitcoin developers on a new mechanism to allow users to bail their Bitcoins in-and-out of OT servers, without having to trust the server itself. That is, even if the server tried to disappear with your Bitcoin, it would not be able to. The next generation of Bitcoin and OT will have this capability. (The new BTC protocol hasn’t been added to OT yet but is coming soon.) Woe to anyone building a Bitcoin site that doesn’t have this capability! …Because soon your OT-enabled competitors will eat your lunch.
More on separation of powers:
— A single currency (such as “Pecunix gold grams” or “Liberty Reserve dollars”) might be issued on a dozen different transaction servers in different jurisdictions, with the same currency contract being used for all of them. One currency—many servers.
— Transaction servers can prove which currencies have been issued there, by producing the issuer’s last receipt. (And the currency contract.)
— Issuers and transaction servers can both prove the total amount that has been issued, also by producing the last receipt.
— The same currency might be distributed across a dozen different issuers, using basket currencies. (Basket currencies allow users to distribute the risk of a single currency across multiple trusted issuers.)
— The contents of a single “asset account” might be distributed across a dozen different transaction servers. (If this abstraction is coded into your client GUI, then what appears as a single account is actually spread across X number of servers.)
4) — Let’s concede that while OT can’t forge receipts against individual users, a malicious server could still use a dummy account to inflate the currency itself, without having to forge any of the individual users’ receipts, and without having to forge the issuer’s receipt.
This is true, but it would not escape the upcoming OT Audit Protocol!
Why not? Because counterfeit funds cannot be spent without flowing from an illicit account into the other accounts of the general population, where the total amount will show up on an audit and be compared against the amount on the issuer’s last receipt.
As long as there is real-time auditing, OR as long as receipts are stored between audits (which could be daily) then the users, as above, can simply dump the untrusted server and redeem their receipts at the issuer. (This can all be automated.) Transaction servers, of course, would have a huge incentive not to pull this, since they already can’t get away with it, and since they would instantly lose their daily revenues from transaction fees.
A similar solution is planned for Bitcoin-based accounts on OT, using the same new mechanism described in answer (3). (It also doesn’t hurt that Bitcoins are publicly-auditable, but our plans go beyond that.)
FYI, the OT Audit protocol is designed but not yet coded.
5) — A typical centralized system is very vulnerable to hackers, who make use of all manner of cross-site-scripting and SQL injection in order to gain access to your server account and do transactions you never authorized.
But on OPEN-TRANSACTIONS, hacking a user would entail gaining access to his private key—which is not stored on the server—as well as installing a keylogger on the user’s machine (in order to get his passphrase.) Furthermore, the hacker would have to do this for each individual user. (The ultimate solution goes even further: store your private key on a crypto-card. People will actually start doing this once enough of them have been hacked.)
By comparison, MtGox recently had hackers sell-off all of the users’ balances for pennies. This also had the effect of crashing the Bitcoin market and damaging the “bulletproof” reputation of Bitcoin.
6) — A typical centralized system is vulnerable to hackers obtaining a copy of their database, and subsequently distributing the users’ email addresses, hashed passwords, account balances, and usernames all over the Internet.
These same users are then subjected to an aftermath consisting of hacks on their Tradehill, Facebook, etc accounts, as well as the imposition of frustrating account-validation and password-changing procedures at all of those sites.
But on OPEN-TRANSACTIONS, no passwords are stored on the server OR client side. Instead, public-key cryptography is used, and the server only responds to signed requests. Users will never have to go and change their Gmail password because of using OT-based systems.
7) — A typical centralized system must store all of its receipts, forever. This is because it cannot prove which instruments are authorized, or which transactions have cleared, without storing them all (in an ever-growing database.) That’s the only way it can prove its case in the event of any dispute. (If parties cannot “prove their case” in a dispute, then the system breaks down.)
But OPEN-TRANSACTIONS uses Triple-Signed-Receipts: Parties can prove which transactions have cleared, and which instruments are authorized, simply by keeping their last signed receipt.
8) — A typical centralized server (such as e-gold) can be pressured to produce transaction data, and made legally responsible to report it. Such data is also vulnerable to hackers (such as happened to MtGox.)
But on OPEN-TRANSACTIONS, users and transaction servers both have the choice to operate in “cash-only” mode, which is completely anonymous. The server cannot be pressured or hacked to reveal your account, if you don’t have one!
The issuer is similarly safe, due to OT’s philosophy of “separation of powers.” Since he has outsourced the transaction processing to the transaction server, the issuer cannot be forced to produce any transaction data—he doesn’t have any!
Note: the more often the issuer performs an audit, the more transaction data he has access to. Clearly in a real-time audit he DOES have access to all transaction data. Therefore the length of the auditing period will be shaped partially by legal considerations. In the case of Bitcoin, on the other hand, real-time auditing will usually be preferable. (Of course when those transactions involve cash, they are untraceable either way.)
9) — A typical centralized server requires a bailment process to exchange funds onto the server, and back off again.
Open-Transactions servers don’t require any bailment process, since they don’t store any reserves. Instead, the issuer chooses when to issue new units of any currency, and any bailment happens through the issuer directly. (Just like on Loom.)
A similar, yet more p2p solution is coming soon for Bitcoin-backed currencies—this is the same new mechanism mentioned in (3).
Additional options also coming soon:
A user will soon be able to transfer to another user in return for a similar reciprocal transfer on an entirely different system (via Ripple), and even into a completely different currency, with the exchange being negotiated p2p by the Ripple protocol.
In effect, this allows users to bail out of specific servers without having to “bail out” at all — instead merely sending an internal transfer to another user, who then pays them in a separate account via Ripple.
Ripple client capabilities are being built into Moneychanger (OT Java client.) Since Moneychanger users will likely list different currency types in their wallets, it only makes sense to connect them all via Ripple. Especially since OT clients will be P2P anyway (they need to compare notes on public mint files for various OT servers.)
This is where I see the true value of Ripple: Eliminating any need for server-to-server transfer, by allowing currency flows directly through the users.
Open-Transactions also allows for users to transfer from one server to another through the issuer, since he already exists at both ends. (Therefore the user doesn’t have to “bail out” in-between.)
Open-Transactions will also make use of Bitcoin as a “glue”, or “universal medium”, between OT servers. OT will always use a crypto-currency in this regard (whether Bitcoin or whatever else) since it is a unique solution to this problem.
10) — A typical centralized server only supports two financial instruments: account transfer, and sometimes market trades.
But OPEN-TRANSACTIONS currently supports cheques, invoices, vouchers, account transfer, receipts, market trades, payment plans, and untraceable digital cash.
Many more instruments are coming soon to OT, including those with scriptable custom behaviors.
11) — A typical centralized system does not have contracts.
OPEN-TRANSACTIONS allows users to create Ricardian-style contracts. These can be used to issue currencies, or to make agreements between other users—and these contracts can be enforced by the server.
OT also uses server contracts, meaning that each OT transaction server is identified by a contract, which contains its connection details for various networks, as well as its public key.
In OT, contracts have become the building block of the entire library. These contracts are self-verifying, and if applied to the domain name problem, they have the potential to entirely decentralize the DNS system.
Coming soon: “Smart contracts” (scriptable clauses.)
The Bitcoin economy, as well as the DGCs (digital gold currencies) will need more financial instruments in order to grow. Instruments such as Escrow, Real Bills, Stocks, Bonds, etc. There will always be the need for a system that enables that next financial instrument. I propose to make those available through scripts, so that new custom code is not necessary inside OT itself for most new contract types.
VOTING POOLS:
(FOR SAFE, DECENTRALIZED BAILMENT OF BITCOINS ONTO OPEN-TRANSACTIONS SERVERS)
This post originally posted here: http://forum.bitcoin.org/index.php?topic=28565.msg363945#msg363945
Benefits (to Bitcoin) of using an OT layer:
1) Untraceable transactions
2) Easy convertibility to other currencies on the OT market.
3) Instant finality of settlement
4) The server cannot forge transactions, or change balances without the user’s signature.
5) All parties need only to store the last signed receipt, and they can prove their current balance, as well as prove which instruments are valid and which transactions are open or closed.
6) No worries about running out of space on the block chain.
===> YOU MIGHT ASK: But what if I don’t want to TRUST the OT server with my Bitcoins? What if it steals them, or disappears, or gets hacked?
===> Based on conversations with Bitcoin developers, I believe I have found the solution to this. I’ve got the protocol figured out, but I haven’t coded everything yet…
===> I’ve hinted at this before, but I’ve got a bit more free time now, so here it is:
THE GIST: LOW-TRUST SERVERS (For Bitcoin on OT. The protocol is different with non-crypto-currencies.)
1) Basically, instead of bailing the BTC into a single server, you bail it into a VOTING POOL of maybe 50 different servers (or however many.) These will operate like a secure escrow in the blockchain. Many of you already have discussed this concept.
2) In my own protocol, the wallet signs the bail-in request, including the amount, the relevant IDs, etc, then the server countersigns it and sends you the receipt. (All the server is doing here is verifying everything in your request, and then signing it, too.)
3) Then your client GUI sends that receipt to the voting pool AND sends the Bitcoins to the pool. (There is no single recipient on the blockchain, but a pool of recipients at once.)
4) This same process happens in reverse when bailing back out. But this time, after the pool members verify that both parties have signed the bail-out request, they then vote on the blockchain to transfer BTC out to the recipient on that request, with a 3/4ths vote (or whatever) which is what actually effects the BTC transfer back to you. Rules can also be enforced here, involving inbox notification, time delays, maximum daily transfers, or whatever we decide.
5) The “vote” between the pool members occurs on the blockchain itself, using the built-in Bitcoin script language. Normally all votes will always be 100% in the same direction, since they will always agree on the truth. So we set it to 3/4ths or 9/10ths, whatever, so that it really takes a supermajority to do any bailment out, yet still leaves enough wiggle-room for the pool to prevent the loss of any BTC, and return it to the rightful owner, even if a server disappears or fails an audit.
6) If a receipt is ever submitted to the pool that’s NOT properly signed, then the pool members simply vote to reject the receipt. (And probably to distrust the bad actor who submitted it.)
7) In the event that an OT server disappears, your BTC is still safe in the pool, and it’s still possible to send a signed recovery request to the pool members, get your 3/4ths vote, and have your BTC transferred back to you.
There’s more to it than that, and it involves the OT audit protocol as well, which is slightly different for issuer-based digital assets than it is for BTC-based digital assets (on OT.)
…But you get the general idea.
I’ve already got all the code I need on the Bitcoin side, I think, and I’ve got the new protocol figured out on the OT side (not coded yet).
I think I can swing this with the existing Bitcoin codebase (no changes to Bitcoin itself), and with the existing mining groups, though I’ll have to include some Bitcoin code into OT for everything to work. I hope to be able to demonstrate this protocol soon. (Frankly I’m shocked no one else has done this yet.)
A NOTE ON ROLLBACKS!
For example, if there is real-time auditing between the server and the issuer (or the server and the voting pool, in the case of Bitcoin) then it becomes impossible for the transaction server to counterfeit, though you must trust the issuer (or server pool) with a copy of all receipts, (as you would normally trust only a single OT server with those same receipts.) In this example of real-time auditing, rollbacks are never necessary.
If, on the other hand, there is once-per-day auditing, then bailments OUT of the system (to get your Bitcoins out of the pool and back into your Bitcoin wallet again) must also have a 24-hour delay, since there is always the potential for a rollback to the last audit, in the event that a server is caught counterfeiting.
We already knew that servers could not forge transactions or screw you on your balance, but it is this last piece, the auditing, that entirely prevents counterfeiting as well, and thus brings us truly into the realm of low-trust servers.