Topic: Proposal for safe blockchain storage pools (for exchanges, using multisig) (Read 1820 times)

With today's BitFloor hack, that realization is slowly getting there.

This does of course mean that someone who gets hold of your private key is for all intents and purposes you.

That is good if you actually do want more than one person to function as one and the same entitity, such as in the case of a "corporate entity. If however that is not your intent, guard your private key better than you guard your bitcoins (I say that because I know most people do not guard their bitcoins adequately...)

-MarkM-

--- The wallet signs the withdrawal request, sends it to the server, who countersigns it and returns it.

--- Then the wallet forwards it to all the pool members, who verify both signatures and then vote on the blockchain.

--- In order to get the pool members to vote falsely, you would have to forge both signatures (the user AND the server.)

A CFD service like Bitcoinica needs to be able to move money into and out of exchanges in order to hedge against the market. We want something like Bitcoinica to be as in-the-market as possible. Bitcoinica was far more bucket-shopy than it needed to be.

In other words, Bitcoinica did not hedge very well -- they could have been hedging far more. At least the inverse of the margin multiplier of a users funds should always be hedged, at the very least.

What you propose will prevent the exchange from being able to manage its funds effectively.

If the only object is to prevent a hack from being able to take exchange funds away, then a cold wallet can accomplish this effectively. Yes, a cold wallet means slight withdraw delays, but the scheme that you've proposed means even higher delays. Your OT servers cant automatically sign -- if they do, then a hacked exchange server could still withdraw coins, right? How do the OT servers verify that there has been no hack? The exchange itself is in the best position to determine that by manually observing the site logs before initiating withdrawals. Or better yet, waiting to allow users to receive text/email confirmation (or realize their email is compromised) for 24 hours before very large withdrawals are completed. Incidentally, this also has the benefit of making the exchange able to be more in-the-market by using user funds more effectively.

I love the idea of a transparent and community moderated exchange account, but multisig as you've proposed it doesn't quite solve the problem. Sorry

--- 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?