Topic: Best protocols for cold wallet, hot wallet. We are building an exchange. - page 2. (Read 2727 times)

To be clear, this is by no means a complete solution. I am just giving you some of our thoughts. You should still adopt a hot/cold wallet strategy and keep most of the funds completely offline.

I ran into some of these questions with the system I am building.

One tentative solution my coworker and I have come up with is to keep the wallet on a separate server than the one that is user-facing (i.e. the website). I will call the web server WS and the separate machine that is interfacing with the Bitcoin network the transaction server, or TS.

In our proposed architecture the WS does not connect directly to the TS. This way, if a hacker gets into your WS, they do not have access to your wallet, or even know where your wallet is running. The TS does not even need to be accessible from the internet (does not need a public IP).

Instead, all communication between the WS and the TS happens via a message queue. The message broker can run on the same machine as the WS or on a third server. Anytime the WS requires information from the wallet (such as funds received at an address) it pushes a message on the queue and waits for a reply.

The TS listens to the message queue and processes any requests. Sensitive requests, such as sending funds to an external address, can go through a separate authorization process. For example, if users want to withdraw funds from their account, a request is pushed to the queue, but the TS does not immediately process it. Instead, it waits for a human administrator to approve the request. The human can either contact the user (via phone, email, etc.) to authenticate the request, or decide based on other criteria if the transfer should be authorized. In the future we may automate this (for example by introducing a two-factor authentication process) but for now we want to keep it simple.

Apart from securing your wallet you will have other issues to deal with. There are not many Bitcoin clients designed to work in a server environment and to deal with concerns such as disaster recovery, load balancing, etc. The only one I’ve come across is https://bitsofproof.com, but I don’t know how good it is.

Some of the issues to think about:

• How to reliably and securely back up your wallet
• What happens to your system if you are servicing a large number of users simultaneously
• How to keep track of the balance in each user’s account

The latter is of particular concern for me. See this thread for more info:
https://bitcointalksearch.org/topic/bitcount-enterprise-grade-account-management-for-bitcoin-586013

- Don't use blockchain.info (or ideally any other third party) to process transactions. Blockchain.info has had periods of downtime sometimes lasting for several hours or more. Use your own bitcoin client instead.
- Keep the hot wallet on a separate machine, not on the webserver. This way you can close the wallet-machine almost completely from all traffic, only allowing very specific requests from the webserver machine.
- If you set up your hot<->cold transfer system properly, there will be no need for periodic backups. Set up the hot wallet in such a way that it only sends out outputs of a fixed size (say, 10 BTC) to the cold wallet address. If you then always send complete batches of 10 BTC back to refill the hot wallet, then there will be no need for change-addresses to be generated and your single cold wallet address is sufficient, which means you only need to backup the cold wallet at the start. Alternatively, configure your cold wallet software to send change back to the input address.

I'm not sure, This computer would never have seen the internet so I would say it is as cold as paper.

I am simply collating different methods from you guys that maybe the dev's have not thought of yet.

The team lead also stated that 3rd parties are not the way to go but I just wanted to throw ideas out there. Anything and everything.

I don't think Armory supports it, but there is no reason you can't have a 2 of 3 multi-sig watching only cold wallet.

They do support 2 of 3 backups for the root keys though.

You could give each directory a share of the root key and print it to a piece of paper.  Any 2 of them could recreate the root key.

Even more fancy would be to give each directory 3 shares each.  You could then require 5 of 9 shares to release the key.

This allows each director to store the shares is more than 1 location, which increases physical security.  If a share is stolen, then there is no loss.

If you do create a cold wallet, you should test the process with a small amount of money first. 

In addition, don't store all the funds in a single output.

If there is a bug in the program that causes unspendable outputs 1% of the time, then spreading the funds over 100 coins limits the risk.

If you do 20-30 small transfers, then the probability of the code failing is pretty low, but it still could have a hidden bug that is rare.

This is where using Armory has an advantage over your own code.  It has been tested, and if there are bugs they are (very) low probability ones.

Use bitgo http://www.youtube.com/watch?v=DuinfYuE8Ng One signature to you one to bitgo and one to the customer and two out of 3 spend the transaction usually you and the customer

By using a 3rd party, you can "gox" your customers if they go bust.

I think you are out of your depth from the questions you're asking.  Cold wallets should never be stored on a computer, so backing up twice daily isn't really a solution, and means you are creating a hot wallet.

If you have a good dev team, don't use a third party like block chain info.  They can get DOSSed, disappear.. what ever.

Creating addresses in code is easy.  Signing takes a bit of time but doable.

Hi good folks,

We are currently building an exchange but up until now have just been focusing on the logic of the trading engine.  I have been tasked with the goal of creating a bullet proof system of cold and hot storage for the exchange. I'm not a programer but have been assigned to just collate different technologies and options to that then the development team and management can go through and discuss each option.

The ratio of getting the convenience / Timeliness / security correct is the hard but the goal is security more than .

I wanted to get some ideas from everyone on the bast ways to go around this. I got massively stung by Gox and have made it my mission never to let a goxing happen to our customers.
But the hard thing is knowing all the tech out there. Because it is all growing so fast now.

I know that http://bitcore.io have some great tools.
so does https://api.trustedcoin.com/#/
So does blockchain.info
So does Armory


Anyway
What is the best way to do this?
We have a very talented development team so nothing is off the table.


So here is one basic idea

--------
HOT WALLET
Using the blockchain.ifo API to generate addresses for each user to deposit funds.

Pay out addresses get locked in on our system and can only be changed through re uploading ID for us to cross check or 2 factor Auth.
A maximum payout per 24h.

COLD WALLET (addresses will be publicly available for audited for proof of solvency)
The Cold wallet is stored on a computer that has never been online and is used to sign transactions using a USB stick. (Armory wallet) to then send funds to the hot wallet.
The cold wallet is backed up twice a day on multiple hard drives.

I would love this to need 2 out of 3 keys so that both directors need to sign transactions every day to minimise trust.  The 3rd is with our Lawyer.
--

Cons and pros

Cons:

• Utilising a 3rd party to handle the hot wallet opens us up to trusting their security. Blockchain.info has proven them selves to be very competent and trustworthy but mistakes on their end can and could happen
• Blockchain could go offline for technical reasons leaving our customers angry at us because they can not withdrawal funds until blockchain.info is back online.
• Cold wallet USB signing could leave us open to a virus that embeds itself in a USB stick to then infect our cold storage offline computer. (need a USB condom LOL)
• Having a hot wallet leaves us open to that getting stolen

Pros

• A hot wallet lets our customers have instant withdrawal to a certain amount
• Cold storage can transfer a % of funds to the hot wallet on a daily basis + any extra that where over flow from the previousness day withdrawal requests.
• If a director is sick, goes on holiday or dies then a 3rd key is available.