|
July 29, 2012, 08:18:19 AM |
|
--- MULTISIG, as you all know, makes it possible to send coins to multiple BTC addresses simultaneously.
--- Once the BTC are stored in that pool, only a vote of those addresses can authorize to release the funds out to another BTC address.
(This is configurable in the bitcoin script language, directly on the bitcoin blockchain--as you already know.)
--- Although OT is uniquely positioned to take advantage of this, I believe our entire community needs to go in the multisig direction, regardless of what software your exchange or web wallet is running.
--- Ideally: a wallet software would send a BTC bailment request msg to the OT server, get it countersigned, and then forward the receipt (along with the BTC itself) to the pool members.
--- As soon as your OT server (which would be looking out for the blockchain transfer) sees it confirmed on the blockchain, it would issue the appropriate units to your BTC account on that server.
--- From this point on, the user can engage in wallet activities, or market trading, etc., on that transaction server -- without having to take the risk of that server being hacked, or being a malicious actor itself. (In fact, why wouldn't any server want to offer this safety and security to their users? Isn't it a competitive advantage?)
--- From this point on, the BTC units are being traded off-the-chain, and have access to all other benefits of doing so (micro-transactions, scaleability, blind mixes, financial instruments, smart contracts...)
--- The server would not be able to change balances or forge transactions internally, due to OT's signed receipts.
--- The server would not be able to inflate the currency due to an auditing protocol with the other pool members.
--- The server would not be able to transfer itself any bitcoins out of the pool. (Unless it secretly controlled a majority or more, of all the pool members.)
--- When a user wants to bail bitcoins out of his account and back onto the blockchain, the same bailment process happens in reverse: he creates a bail-out request, signs it, sends it to the OT server which countersigns it, and then both forward a copy to the other pool members (which would probably just be other OT servers) who would verify the signatures on the receipt and then vote on the blockchain to release the funds to the BTC address listed there.
--- A hacker would not be able to steal any BTC from a transaction server, even if he was able to gain full control over that transaction server.
--- Even if your transaction server abruptly disappears (such as MyBitcoin did), all of the coins would still be recoverable from the pool! The users, still holding their last signed receipt, would send a recovery request to the other pool members, and get a vote to have their BTC transferred back into their full control. (An attacker would have to control a majority of all of the transaction servers in the pool, in order to falsify a vote.)
To me this seems like such an obvious advantage that I feel like it is only a matter of time before everyone is doing it. (Until then, there's a sucker born every minute...)
In fact, would it be possible for one of you "Bitcoin experts" to send me the sample code for multisig (for sending, for verifying, and for voting to send back out.) My own software has reached a point now where such an integration would be feasible and could be a huge benefit to everyone in the community. I can hold up my side of this protocol. What is the best way to do this on your side, libbitcoin? Or what?
|