|
fellowtraveler (OP)
|
 |
June 21, 2011, 04:13:20 AM
Last edit: June 22, 2011, 02:58:14 PM by fellowtraveler |
|
There's been a lot of talk lately regarding Open-Transactions
as a "centralized system" (comparable to e-gold or MtGox.)
I wanted to clear up some of these misconceptions...
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.
--------------------------------------------------------
Recent events have stimulated a lot of talk about security issues in Bitcoin,
specifically due to the use of centralized servers by the Bitcoin community.
There are some big differences between Open-Transactions and the
“typical centralized system”…
1) — The 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 numerical entry 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 the 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 has 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.
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 when 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 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 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, it is useless to hack the server, since even a
malicious server cannot forge transactions on OT! Hacking a user would require
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 the users’
balances for pennies. This also had the effect of crashing the Bitcoin
market and damaging the “bulletproof” reputation of Bitcoin.
There simply shouldn't be any passwords stored, anywhere! Neither
should there be any transactions processed that haven't been signed
by the user's private key.
--------------------------------------------------------
6) — A typical centralized system is vulnerable to hackers
obtaining a copy of their database, and subsequently distributing the
users’ email addresses, salted 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 when 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 producing 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!
--------------------------------------------------------
9) — A typical centralized server requires a bailment process to
get new 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 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 are coming soon:
Via the Ripple protocol, a user will be able to transfer off of the OT
server simply by sending funds to another user on OT (who makes
a similar reciprocal transfer on an entirely different system (via
Ripple.)
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 many financial
instruments, including 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.
----------------------------------------------------------------------
WHAT IS “Open Transactions” ?
Open-Transactions is a software library, as well as a server application
and a client API (built on top of that library.) New: A Java client app
has also been added.
WHAT DOES IT DO?
Open-Transactions allows users to issue and manipulate digital assets.
Users may create many pseudonyms (public keys), each of which may own
asset accounts of various types. Users can transfer digital assets
securely between accounts (even a server cannot change balances or forge
transactions.) Users can also operate “cash-only” (without accounts) for
maximum anonymity.
Open-Transactions supports a range of financial instruments, such as
cheques, vouchers, and untraceable digital cash. These are all analogous
to the same financial instruments that we all use at normal banks today.
Everyone already has an intuitive understanding of these financial
instruments, because we use them regularly in our normal daily lives.
Open-Transactions also implements higher-level, contract-based
transactions such as payment plans and markets with trades.
The markets on Open-Transactions support market orders, limit orders,
fill-or-kill orders, day orders, stop orders, and stop limits, just like trading
on a real market. OT also supports basket currencies.
All of this is accomplished in such a way that all parties are able to
prove, at all times, which transactions have cleared and which
instruments are authorized, without having to store their entire
transaction history, but instead by merely keeping the last signed
receipt.
The real beauty of Open-Transactions is the as-yet-unwritten future of
new ideas that you can build with it, and the future liberty and
security of your children that you can help to protect by doing so—in a
very real and tangible way.
|
