THE LAW by Frederic Bastiat

There is no reason why any of these security problems had to happen.

http://forum.bitcoin.org/index.php?topic=20377.msg278729#msg278729


Someday, enough money will be stolen that the Bitcoin community will consider using public key cryptography that was invented back in the 70s.

As long as everyone is still storing passwords on the server, they deserve what they get.

-- NO passwords stored on server or client side.

-- ALL transaction requests must be client-signed. (Any password is entered on the client side, and is not stored anywhere. Server verifies signature before processing transaction.) This prevents hackers from accessing your account funds unless they have a copy of your private key AND your passphrase.

-- All transaction receipts must be server-signed (and must contain a copy of the original client-signed request.) This prevents the server from forging any of your transactions.

-- Receipt should prove current balance, with the newest receipt is always the winner in any dispute. (Meaning the receipt IS the account.) This prevents the server from changing your balance without permission.

-- Receipt should also prove which instruments are valid and which transactions have cleared. (Meaning the receipt IS the transaction history.)

-- All recurring transactions (such as trades processing over time from a specific market offer) should result in a receipt in the user's inbox.

-- All market trades should contain a copy of the user's original signed offer, as well as details on how many trades have processed from the offer.

-- Users should have to sign a new receipt every time they clear their inbox. (The server can never change your balance without your sign-off.)

-- All server requests must contain a request number that increments with each message. This prevents attackers from intercepting messages and sending them again.

-- All server requests must contain the server ID that the message is intended for. This prevents attackers from intercepting messages and sending them to other servers.

-- All transactions must contain a transaction number that was previously issued (and signed for). These numbers must be listed on every receipt until signed as closed. (Server can prove entire transaction history without having to store it.)

-- All transactions must contain a signed balance agreement. All receipts must be verifiable against the current inbox and the last signed balance agreement.

-- All Bitcoins must be bailed into a system such that individual servers cannot steal bitcoins from their own users. (Or be hacked and have hackers steal bitcoins from their users.)

-- All currencies issued on the server, including Bitcoins, must have reserves that are publicly auditable.

-- Users should sign all transactions on a crypto-card.

-- An additional layer should be provided via crypto-tokens with passwords that change every 90 seconds.

-- Accounts and transactions should be possible that require multiple signers.


OT already does nearly all of these.  The last 5 are "coming soon".

https://github.com/FellowTraveler/Open-Transactions/wiki

OT supports these.  They're called "payment plans".

It's actually a contract between two parties, must be signed by both of them, and it describes the initial payment, as well as the regular payments, with delays, amounts, account IDs, etc.

Transfers occur regularly according to the terms in the contract, and receipts are automatically delivered into both parties' inboxes after each payment.

-FT

Even if that is the case, there should still be a separate "gold road" on Tor, based on the same code.  

Otherwise it's just too easy for the-powers-that-be to propagandize the link between the two. "Gold" becomes comparable to "drugs" and "guns".

There is already enough of a push in the mainstream media to label gold as "contraband", we should not give those people ammunition.

Think about this: If the site ONLY sells gold and silver, then it becomes much more difficult to demonize those people. Any effort to do so would be interpreted as an attack on justice.



 

It should do reputation as well, like eBay or Amazon.

I mean a place that lists buyers and sellers, and has escrow, and has prices posted, and allows people to convert both directions.

Someone should put up a version of Silk Road that does NOT deal in drugs, guns, etc.

Basically it would be identical to the existing Silk Road, except people would deal only in gold and silver coins (for Bitcoin.)

I'm actually sad that the Silk Road guys did drugs first, since all it did was bring a bunch of heat down.

IMO the Bitcoin community needs:

--- Anonymity. This will drive new businesses that were not possible before, and thus enlarge the Bitcoin economy. (Such as darknet hosting...)
--- Instant finality of settlement. (Necessary for e-commerce.)
--- Security. Wallets and Exchange Accounts should not continually be hacked.

IMO my own OT software goes a long way towards solving the above issues.

Additionally needed are:
--- "iPhone-easy" user interface. My own client Moneychanger is meant as a reference implementation using the OT-API; it is not meant as the best possible interface. I'll predict right now that whichever one of you writes the slickest wallet software is going to clean up. This software still does not exist in the Bitcoin community and it is sorely needed.
--- An easy e-commerce API that can be consistent across merchants. Such a system could be built on top of the OT-API. (OT does transfers, cheques, cash, and receipts. YOU have to use those tools to build your e-commerce.)
--- I think there is also a big opportunity for such an ecommerce app to provide more safety and reversibility, similar to services the credit card companies provide, except as a voluntary system. For example, escrow. (Although escrow will eventually be added to OT itself.)

Remember that Gold has value as a commodity, and it also has value as a money. Let's consider these separately...


1) Value is not intrinsic to gold. Rather, men value gold because of its unique properties. (Its beauty, weight, and rarity, its longevity over time, and chemical and electrical properties, among other things.)

2) Gold eventually ended up being used as MONEY also due to its unique properties...
    -- Gold is valued (see 1). But notice, water is also valued, yet it is not used for money. This is because gold "stores" more "value" in a much smaller space, than water does.
    -- Gold is also evenly divisible. But so is water. Therefore while divisibility is necessary as a property for a currency, it is not the only necessary property.
    -- Gold is also fungible. (Any unit of gold is basically the same as any other unit.) This is not true for, say, land, even though land is valuable.
    -- Gold also "stores" value consistently over TIME. This is unlike other valuable things, such as food.

Therefore, due to the above properties, gold naturally has become selected by the market, time and time again, and all over the world, as money.

There was never some committee of men who decided upon the "irrational belief" that gold is money. Rather, the invisible hand of the market decided it, and always has.

You might say, "But wait, everyone uses fiat money now, so hasn't the market chosen it as superior to gold?"  The answer is no: coercion is employed to interfere with the market. And those employing that coercion are the ones guarding the gold and using it behind the scenes for currency reserves and for international settlement. Therefore even today, gold is money, according to the very people who try so desperately to convince us that it is not.

Due to the above reasons, people have naturally learned to psychologically value gold as a universal money. It's true that this psychological belief is part of gold's value, since you can add it to the list of "valuable properties". But it is not irrational -- it is based upon history and market economics.

The only reason Bitcoin may turn out to be of value is also due to its unique properties, which are analogous to gold, and thus any belief in Bitcoin's value must necessarily also acknowledge gold's value.

After all, we all agree that Bitcoin is not valued "irrationally" but due to its unique properties, yes?  Gold is the same way.

On OT, your Pseudonym is just your public key, and its fingerprint (ID.)

If I allowed people to put a "web site" metatag with their key, THEY COULD LIE IN THAT TAG (they could put "www.coke.com" even though they are not related to Coke in any way.)

But in the current system, there is nothing stopping Coke from putting their public key, and its fingerprint, on their website so that users know this really is "Coke's key."

Therefore the current system probably accomplishes what you meant, in a safer way than actually adding identifying info to the public key.

Yes. For any contract-based currency, including commodity-based, you must trust the issuer that he is actually upholding his end of the contract, i.e. holding the appropriate assets in a legally-acceptable fashion.

Therefore you must trust his governance: his auditing procedures, his standing in his local jurisdiction, his use of separation of powers, his bonding (eCache uses bonds)...

Those are all governance issues (meaning there is no technical solution, since these are issues of governance.)

This is one area where I think Bitcoin is actually superior to physical commodities (such as gold), since technical solutions are possible with Bitcoin.


This is absolutely true. If the issuer himself is a bad actor, then his digital currencies are suspect. My goal with OT is to eliminate this risk at a technical level (the transaction server), but obviously a piece of software can never fix governance issues such as an issuer's need to audit and insure his warehouse full of gold.

The issuer is in the business of trust; my hope with OT is that jurisdictional arbitrage will enable a global trust market, with all of the liabilities and risks of the transaction server itself removed from the equation (by OT).


1) The OT transaction server itself cannot forge transactions or change balances. So the "bad event" that happened, will not happen on OT. (OT cannot forge receipts.)

2) The OT transaction server itself technically could store all of its receipts, and thus roll back the system to any point based on the information in those receipts. (In practice the OT transaction server doesn't need to store any receipts except for the last one for each user.)

3) While the OT transaction server cannot forge receipts, it COULD use an illicit account to counterfeit (inflate) funds, and could do so without having to forge any issuer receipts. This is prevented using an audit protocol between the issuer and the transaction server. (Which could be performed daily.) OT normally allows parties to destroy all receipts except for the last one. However with an audit protocol in place, I recommend that parties store all receipts between audits.

4) This way, if a transaction server ever counterfeits, the issuer will catch it out, and yes, would have the ability to roll everyone back to the last audit, and re-issue their funds on a new transaction server.

This is described above in my long post. The transaction server has little incentive to pull this, since he wouldn't get away with it, he doesn't hold any of the gold, and he would immediately lose his daily revenues from transaction fees.

An even better solution is possible using Bitcoin (coming soon) which I have hinted at recently. Using Bitcoin, unlike any other commodity, it's possible to accomplish these things without even having to trust an issuer. (No one is doing it yet, but they will soon.)


This is one intention of mine, yes.

It is possible in OT, using baskets, to distribute the risk of a single currency across multiple issuers.

If one issuer ever disappears, the loss could then be made up through insurance, paid for through transaction fees from using the basket.

I'm sure there are other creative solutions but that's one I had in mind.


I agree that funds are likely to flow more to trusted parties than to untrusted parties.

Due to this, it creates a profit incentive to innovate in trust solutions, which I believe entities will do (and some will succeed, some will fail.) That is why there are markets.

There are also other incentives for users to choose one issuer over another, such as bailment policies, jurisdiction, etc.


Because OT is, first and foremost, a financial crypto library.  The OT server and OT API are just examples of what can be built using that library.

It makes sense to me that such a library should be technically capable of implementing various instruments, even if they are "complicated" or "not suitable for retail investors".

The thing with a library is, you don't know all the ways that people might end up using it.

OT's infrastructure is such that, while CDOs may seem complicated, they are rather easy to implement using the same mechanisms used in basket currencies.

I don't know when I will actually get around to CDOs, and perhaps they will be implementable using script clauses, I don't know. I tend to prioritize so I doubt you will see CDOS before stocks, for example.

-FT

If you guys want to raise money to do various OT projects, that's cool, but if you ask me what I want: I want volunteers.  
Think about it: Which allows me to move more mountains? $30K in donations over the next year? Or 3 volunteer coders?
Android client, anyone?
Mac OS X client?
iPhone client also.
A real unix command line is important and needed. (This makes OT scriptable.)
Firefox plugin, a Chrome plugin... (These allow us to use a new "OTTP" URI format for links in HTML files. Read more about it here: https://github.com/FellowTraveler/Open-Transactions/wiki/OTTP-URI-Format )
I also need some C code that will import a PGP private key into OpenSSL format. (I've already got public keys.)
I also need a crypto expert to go over the crypto-specific parts of OT and audit them.
Also would like the same expert to update OT to support larger keys. (I'll get to that eventually if no one else does.)
In the unlikely event that a C expert actually pops up, it'd be cool if you can update OTMint and OTToken classes to use credlib (Chaum and Brands.) I will also do this eventually if no one else does.
I'd also love to see Java and D-language ports of OT.
I'd also love someone to write a subclass of OTStorage that goes to some kind of Tahoe or other cool DB (you only have do a few overrides.)
Also: the Market screen is incomplete on Moneychanger. I'd love for a Java expert to get in there and finish hooking it up to the OT Market API.
Also: The Basket screen as well.
Also: Currently Moneychanger uses the Bitcoin JSON-RPC interface. Obviously, this needs to be replaced immediately with internal code that encrypts the Wallet.dat before loading/saving.

Yes -- normally you will lose control over them, and the server will gain control over them.  But that is the state of things BEFORE my special new protocol gets involved. The new protocol I mentioned is what fixes this problem.


This depends on which instrument you are using for payment.

==> If the instrument is cash, then Alice sends the cash to Bob, who then deposits or exchanges it with the server. (See the notarizeDeposit function in the OT API.)
     (ALICE GETS NO RECEIPT FROM OT, OTHER THAN HER WITHDRAWAL RECEIPT. SHE MUST TRUST BOB TO GIVE HER A PURCHASE RECEIPT.)

==> If the instrument is a cheque or voucher, then Alice sends it to Bob, who then deposits it at the server (See notarizeDepositCheque.)
     (Bob gets a deposit receipt, which includes a copy of the cheque, and Alice gets a cheque receipt in her inbox, which also includes a copy of the cheque.)

==> If the instrument is "account transfer", then Alice initiates a transfer to Bob, who receives a notice in his inbox. (The funds by this point have already left her account.) Bob signs to accept it, and that's when the funds hit his account.
     (Alice gets one receipt when she initiates, and she gets a transfer receipt in her inbox when Bob accepts. Bob, meanwhile, gets the AcceptReceipt when he accepts.)

If, instead, markets were used, then Alice and Bob would both get an initial receipt when they placed their market offers, and they would also get Trade receipts in their inboxes whenever those offers are traded against other offers on the market.

Meatpile: Thank you for your PM. I agree on the usefulness of providing builds of OT :-)  I can post a DLL up there pretty soon, for Windows users of Moneychanger. I think I can build 64-bit Mac and 32-bit linux as well. By default I'd post up the Java API build, since that's what Moneychanger uses. (Moneychanger Jar file is already posted, so at least there's one build available.)

passerby: coming soon.

Batouzo: FYI, OT messages *are* signed contracts (everything in OT is a contract) so yes, they can be loaded up, signature verified, etc. And yes, everyone can verify the Issuer's last receipt (including the total amount issued) when the transaction server produces it, and the issuer can't lie about it, without being caught. (And vice-versa.) Because there's his signature on the receipt...
The auditing process will involve balances and account IDs (possibly scrambled from each other as well.) Audit data will be stored in a DHT and encrypted to Issuer's public key, so only the Issuer can see it (so he can verify no counterfeiting has occurred.) I don't expect the Issuer to dump the data to the Internet like the mtgox database did, but if that did happen, remember there aren't any passwords, usernames, or email addresses stored.  Just balances.
Specific to your question about markets: Yes, if someone places a market order, and saves his receipt, he can produce it later to prove what happened. The OT server also stores whatever receipts it needs to, to prove its story in the event of a dispute. (Usually this means only the last signed receipt, but in practice all parties will probably store all receipts between audits.

Man's life can only be sustained through his work (his liberty), as he creates new products (property), which he trades with other men. This is how man sustains his life.

Thus, property is the result of man's work, and is also the reason for his work. As every trade is voluntary, it can be assumed that each party to the trade has improved his circumstances, or he wouldn't have chosen to take part in the trade. As millions of trades go on every day, people's lives are improved millions of times over, resulting in the great improvement in the human condition that history shows to be consequential to free markets.

You might enslave a man by taking away his liberty, but you will also enslave a man by taking the fruits of his labor. In the first case, you choose how he will give you all of his production. In the second case, he chooses how he will give you all of his production. Either way, he is a slave.

If someone attacks you, you may have to use violent force if you wish to survive. This is the law of the jungle. Any jury would acquit you for using deadly force in such circumstances.

Similarly, if someone attempts to take your liberty (say, by binding your hands and feet, and throwing you into the trunk of a car) then you similarly may have to use violent force if you wish to survive. After all, if the attacker is willing to tie you up and throw you into the trunk of a car, how could any reasonable person not be expected to also fear for their life in such circumstances?

Similarly, if someone attempts to take your property, then you similarly may have to use violent force if you wish to survive. After all, clearly this person is willing to use violent force against you, since otherwise no one would normally part with the fruits of their own labor. And since he is willing to use violent force, and indeed is threatening you with it, then you are in a state of war the same as if he had threatened your life or liberty.

Clearly we can see that any man has a right to use force to defend his life, his liberty, and his property.

And if a single man has a right to use force to defend life, liberty, and property, then it stands to reason that a group of men likewise have the right to band together and provide a common defense of life, liberty and property.

Thus government, when used solely to protect our rights, actually has a moral right to function: the same moral right that you have to defend yourself individually against threats or attack.

But whenever government is used to violate our life, liberty, or property, then it does not have a moral right, any more than an individual person would have a moral right to do those things.

This is why the US Constitution was originally designed to limit the powers of government. Democratic processes were strictly limited to the political realm, not the moral realm: no democratic process ever has the right to vote regarding people's lives, liberties, or property, any more than a democratic process has the right to commit genocide. No crime is "right" just because a majority wills it. Once democratic processes become a tool for subverting human rights, then we devolve into a system where "everybody is enslaved to everybody" and where no one's rights are respected anymore, because people no longer have any understanding of their rights, or of the Western Tradition and Enlightenment that brought those rights to our awareness in the first place.

The Wiki is available here:
https://github.com/FellowTraveler/Open-Transactions/wiki

The FAQ is available here:
https://github.com/FellowTraveler/Open-Transactions/wiki/FAQ

The core account system, including destruction of account history, is comparable to this system:
http://truledger.com/doc/plain-english.html
All of the concepts are explained there.
The differences between that system and my own are described here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Triple-Signed-Receipts

I also recommend this article, since the above relies on these concepts:
http://iang.org/papers/triple_entry.html

The Chaumian blinding (untraceable cash) is implemented using this system:
http://anoncvs.aldigital.co.uk/lucre/
There is a paper there for you to read. I used the C++ version of Lucre, FYI.

Regarding the untraceable cash, I also recommend these articles from my Wiki:
https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Cash
https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Mint

The Ricardian contracts are described in my Wiki, with a sample provided:
https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Currency-Contract

Here is a chart of the instruments on OT:
https://github.com/FellowTraveler/Open-Transactions/wiki/Instruments

They are comparable to the Ricardo implementation of instruments described here:
http://www.systemics.com/docs/sox/overview.html

The source code is available here for review:
https://github.com/FellowTraveler/Open-Transactions

The API is here:
https://github.com/FellowTraveler/Open-Transactions/wiki/API

Instructions for using the API are here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases

A Java implementation of an OT Wallet, coded using the OT API, is here:
https://github.com/FellowTraveler/Moneychanger
Anyone who has any trouble figuring out the API can use Moneychanger as a reference.
(I am also, of course, available to answer questions.)

Some technical details about the Messaging is available on the wiki here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Messaging

Transaction-specific messages are described here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Transactions

New docs are always being written, usually to answer questions that come up. Sorry if it's not enough for you but more is coming I promise

If it helps, some people have understood the system better after listening to the Radio interview...
part 1: http://agoristradio.com/?p=234
part 2: http://agoristradio.com/?p=246

Here are some diagrams for you:
Overview: http://billstclair.com/ot/ot-diagram.jpg
Full-Anon (cash-only): http://billstclair.com/ot/OT-Anon-CashOnly.jpg
Pseudo-Anon (using accounts): http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg

Let me know if any other questions, I'm always glad to help.

-FT

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.

I recommend you start with my API:

https://github.com/FellowTraveler/Open-Transactions/wiki

The most Libertarian state is California.

Weed and gay marriage are both legal, and you can get an abortion on every streetcorner.