The critical elements needed are:
1 - a trusted escrow agent and escrow scheme
2 - a way to pull the trigger (so there is a well-defined and irreversible moment when a deal transitions from not-having-occurred to occurred)
3 - recourse against those who do not fulfill their ends of deals.
I believe the answers to those are:
1 - tools I am providing (escrow tools based on EC multiplication)
2 - using the sending of bitcoins to a signed and published address as a sentinel that a transaction has been executed
3 - having all transactions executed by sending either the bitcoins (if it's a BTC-sell) or an earnest money deposit (if it's a BTC buy) to the escrow address, so the burden is always on the other party to send their fiat as promised or else lose their bitcoins.
Casascius (and others):
I've been thinking about this and some related issues for some time, and would be curious to get your thoughts on something.
<< And, full disclosure, my expertise really lies on the legal/regulatory/finance side of things: I'm not a coder and don't have a sophisticated understanding of how the Bitcoin Protocal works at the microscopic level (same is true for public-key cryptography, SSL, ECDSA, SHA256, deterministic wallets, multisignature transactions, etc.) -- although I think I broadly understand (and admire) the concepts underlying Bitcoin at a very-general conceptual level, and can at least throw around enough terms to pretend I understand more than I really do... >>
My specific question: At this point in time, would it be possible to set up an online trading exchange for [some virtual asset or assets], with prices denominated in BTC,
(A) which doesn't require a user to create an actual account with the exchange but instead allows him/her to simply "log on" by providing proof-of-ownership of a Bitcoin Address or Wallet (e.g., you initiate a "session" with the exchange by sending a brief introductory handshake-message signed with the Private Key associated with a Bitcoin Address, which the exchange's software verifies against the Public Key and confirms that the BTC-Address in question actually has a positive BTC balance), and
(B) which also -- by using multisignature transactions -- eliminates the need for the exchange itself to ever take possession of any BTC funds (thereby completely eliminating any risk that the exchange could have some portion of its BTC funds hacked or stolen (even if the exchange operators otherwise take prudent measures like keeping as much as possible in offline cold-storage wallet)), with the exchange literally just operating as a platform to bring together willing sellers and buyers and with "settlement" of the BTC funds actually taking place directly between the parties once a match is made?
I realize that's a mouthful, so to make it more concrete:
Let's imagine that someone sets up a new-and-improved "GLBSE Version 2.0," where users can once again trade "shares" in various listed "companies".
The exchange keeps account of (and makes available online) the definitive book-entry register of who owns what # of shares of each listed company. But, as far as defining such "who" -- the sole item of identifying information for each shareholder would be a Bitcoin Address (or alternatively perhaps the actual Public Key, or perhaps a Root Public Key for a deterministic wallet?).
The exchange also operates as an online order book, where users enter basic buy/sell limit orders, and which applies a basic matching algorithm to execute matched buy/sell orders.
EXAMPLE: Buyer, Bill, would like to acquire shares of Acme Enterprises. So, Bill goes to the website for the exchange and "logs in." On the exchange, however, there's no need for Bill to create an account or provide personally identifying information -- rather, his UserID is, in effect, his Bitcoin Address (let's call it "1BILLxyz..."); and a message signed with his private key is, in effect, his password. (I'm envisioning that this could all happen "under the hood," so that having downloaded a simple piece of client-side software, all Bill actually does is click a button saying "begin a trading session" to get on -- but behind the scenes that begins the process of originating a secure connection via HTTPS, and then transmitting the bitcoin address/public key that Bill wants to trade with, along with the message signed with the private key to prove he controls that address).
So Bill hops onto the website, and establishes a new session using his Bitcoin address 1BILLxyz... with the click of a button. Now he wants to enter an order to buy 10 shares of Acme Enterprises at 5BTC per share. We want to make sure that he's good for the 50BTC if/when a willing Seller lifts his bid -- but is there an efficient way for him to provide that certainty, other than simply forking over the 50BTC to the exchange?
[HOW IT'S DONE TODAY: i.e., today, the "conventional" way to do this would be for Bill to send some amount of BTC to an address controlled by the exchange, and (purely as a matter of internal accounting by the exchange operators) Bill would have a BTC-account which would be credited with his BTC balance. Bill could then enter orders so long as his BTC balance was large enough to cover all of his outstanding buy orders. (Cancelling an unmatched order would free up that portion of the balance.)
[But, operating this way exposes Bill to counterparty risk with the exchange itself (completely separate and distinct from whatever risk he is quite willingly looking to take in making an investment in the underlying share-issuing company): he has really sent his BTC funds to the exchange, and runs the risk that the exchange simply shuts down, keeps his money, and hops on the next charter flight to Pirateat40's private caribbean island getaway. Or, equally, he risks that the exchange is run by someone who is ethical but incompetent, and stores the hot wallet in an unencrypted file which someone hacks, and the BTCs are gone.]
So, instead: rather than sending 50 BTC to the exchange, I'm envisioning/wondering whether there's a way for Bill to originate and sign a multisignature transaction, or a series of multisignature transactions, which will in essence fund his account for the duration of his trading session, and which will have the following outcomes:
- if Bill terminates his session with the exchange without placing any buy orders, the exchange automatically signs the transaction sending the BTCs back to Bill.
- if Bill places an order, and the order isn't filled, the amount necessary to fund the order if/when matched just stays hanging around as a partially-signed multisig transaction; and if he terminates his trading session after placing an unfilled order which exceeds the amount of his initial funding transaction, he'll get the overage back immediately when he logs off. (EX: he logs on and transmits a multisig transaction sending 50BTC from his BTC address, places a buy order for 10 shares of ACME at 4BTC/share (for 40BTC total), which isn't yet matched, and leaves the order outstanding and logs off. In this situation, Bill should get 10BTC back, while the remaining 40BTC stays in partially-signed-transaction suspense as long as the order remains outstanding on the order book).
- if/when the order is filled by a Seller who owns shares of Acme (lets call her "Sally,"* identified to the exchange only by her BTC address 1SALLYabc...), then two things happen: (1) the exchange signs the multisignature transaction in such a way that the sales proceeds go to Sally's BTC address, and (2) the exchange updates the master ownership registry for Acme Enterprises, to reflect that Sally now owns 10 fewer shares than she used to and Bill owns 10 more shares than he used to, because Sally sold those 10 shares to Bill.
(*And note that, for Sally, looking to sell shares of Acme, the logon process was exactly the same as for Bill, except that if she only wants to sell and not buy then she didn't need to transmit a a partially-signed transaction to the network to fund anything; once she established herself as the real owner of address 1SALLYabc..., the exchange software can see that she owns (say) 35 shares of Acme Enterprises, so she will be permitted to enter sell order(s) for up to 35 shares into the order book.)
It's the above critical "decision-tree" piece which I'm fuzzy about, because I'm not sure whether this is doable with multisignature transactions. But if it can be done, then it seems to me that this could be huge: nation-states' central banks and securities regulators could jump up and down and scream and shout all they want about AML/KYC and securities fraud and unlicensed money transmission and whatever else they want to -- but other than the software and a data file showing ownership of shares by BTC address, there's nothing for them to go after or seize if they wanted to try to shut it down: there's not even so much as a pool of BTC funds (or any other form of assets, whether fiat money or otherwise) at the exchange, because the BTC funds are really literally traveling straight from share-buyers to share-sellers. And if they want to go after buyers and sellers of shares on the exchange, well, all they have to go on is a BTC address.
Seems like this might be a useful path forward...?