At Bitalo, we use MePIN. It's like Google Authenticator on steroids. First, its safer than Google's solution, because the secret key never travels through user's computer, so the process is safe even if the computer is compromised during 2FA setup. Second, it's even more convenient, because you receive a push notification to your mobile and only need to press "OK" to accept the request, instead of typing digits into a form.

We use them a lot on Bitalo, multisig addresses are at the core of the wallet service we are providing. Since it's fairly easy to use that way our users are doing quite a lot of transactions between them. One example: https://blockchain.info/address/3EvUWjBKzhPFRJd7ffjciqij8R7qrgndde

It is a real risk, as it was demostraded on February that someone changed few thousand transactions for no particular reason.

You would need to ask them to know for sure, but that's one way to do it. They could also use HD wallets for that purpose.


PR speak for a hot wallet that the operators think is fairly secure .

Yep. Every miner decides for himself whether he will include your transaction in the block or not. And since its priority rises over time (see https://en.bitcoin.it/wiki/Transaction_fees#Technical_info), and your transaction is considered "standard", over time it's more and more probable for it to be included in a block.


Not until some time has passed and nodes drop it out from their memory pools. Otherwise they won't accept another transaction that spends the same outputs and they will not relay it further. You can of course try until it succeeds.


Nope. If you pay a less than recommended fee, it is generally considered by miners as if you would pay no fee at all.

As I mentioned above - CoinKite uses something in between with their HSMs. Other than that I don't see another solution for an exchange. (well, in the past exchanges used only "hot" wallets without any safeguards if you want to count that as an solution )

There are some plain wallet services that don't utilize multisig addresses and don't store unencrypted private keys on the server. Instead, they encrypt everything in the browser and then just send it to the server for storing. This is more or less ok, but doesn't let them to provide an exchange service.

Let me address some of your points:


That's more or less true. You don't have to store the whole blockchain on your "cold wallet" though. The cold wallet is just a place to store private keys. The best approach would be to create a transaction "draft" (with inputs unsigned) on an online computer, then move it on a USB stick to the offline computer with cold storage, and then use a piece of software that lets you sign this transaction with private keys. Then you move out the resulting signed transaction back to online computer and send it to the network.


Yes, hot/cold wallet scheme has many problems, and you are right on almost all those points (besides the last one, maybe).


Yes, it's currently the most (over-)used approach in the industry. Is it recommendable? No. For the afermentioned reasons.


Wrong. Multi-sig addresses are implemented in the protocol for a long time. Last year some services started to pop out using this beautiful feature of Bitcoin. One of them is Bitalo.com, which is an exchange that utilizes this technology to make user funds safe even during the trading, but, what's even more important, when they only want to store their coins on us. By "safe", I mean safe even in case of hacker attack on Bitalo servers, or even safe from the administrators themselves.

Bitalo is not the only service that implements that (but AFAIK is the only *exchange* service). Other e-Wallets that implement multisignature include: GreenAddress.it, BitGo.com and Trustedcoin.com.


You never should send Bitcoins back to the address they came from without owners consent. This is exactly because there are many Bitcoin services which use hot/cold wallets and mixup Bitcoin addresses. So the address you deposit to is different than the address you're sending from while withdrawing. So if a service would send you back Bitcoins you sent from this kind of service, it could end up on other users wallet!
One service that doesn't work that way is Coinkite - they run a full-reserve service by utilizing Hardware Security Modules, which means that they have only one wallet instead of Hot and Cold, and so they can tie addresses to specific users.

I had experience from the administrator side with both types of exchanges (both hot/cold storage one and a multisig one) so if you have any more questions, feel free to ask .

As others said, check the order of your keys. It matters - different order will output a different address.

As gmaxwell pointed out, multi-sig protocol has a big advantage over what you're proposing because it doesn't need you to transmit all keys into one place to create a signature. Also, writing your own cryptographic functions/protocols is considered a bad practice, because there are many subtle details you have to know, and having only one of them wrong can defeat your whole system.

There is one service I'm aware of that lets you create, sign and verify multi-sig transactions without command line: https://coinb.in/multisig/ . I personally didn't check it, so use it at your own risk.

Also, creating multisig transactions in command line is relatively easy when you know what you're doing. You need bitcoind or other Bitcoin software for that, but I guess there's no point in running from dependencies when they do their job correctly.

That's correct, transactions with lock time set in the future are considered non-standard and won't be relayed. This is to prevent possible DOS attacks where you could spam the network with such transactions.


You can check that the transaction is valid yourself:
- you can decode it to see if all parameters are ok - all outputs are pointing where they should be, and the nLockTime is properly set
- you can pick signatures from inputs and check them yourself using the same algorithms that Bitcoin software uses

That said, I have a feeling that we misunderstood ourselves regarding the use of some terminology. When I'm referring to "transaction malleability", I'm not talking about ability for the author of the transaction to submit a new version of it based on lock time parameter. I'm talking about someone else (let's call her Eve) being able to tweak certain tx parameters in a way that the signature is still valid, but the TXID is different. This can happen without Eve knowing Bob or Alice - she can set up a node that will catch transactions as they propagate in the network and re-submit them with tweaked parameters. She won't gain anything by doing this, but she can mess up with software and protocols that expect that TXID's don't change, effectively pulling of a DOS attack on those.

Phil Dann Ward: There is one flaw in your protocol regarding lately discussed transaction malleability issue. You cannot be sure about a TXID of transaction until it is included in the blockchain (and even then, there could be a reorg later, but let's assume that's highly unlikely). And yet, this protocol relies on an assumption that a lock time transaction will be able to spend the funds using a specific TXID as an input. If in the mean time the TXID gets changed (someone manages to insert a modified version of the transaction in the blockchain), this will fail.

This problem (which is a problem for many Contract-style protocols) will gradually fade away as Bitcoin devs address the malleability issue somehow.

@jubalix: When setting up two-factor, you usually have an option to remember some kind of recovery code, that you can use later should you ever lose your phone. Even if you don't have it, we would get you through the user verification procedure again to make sure it's not a hacker who tries to access your account, and if everything's fine we would disable 2-factor temporarily so you could sign in and set it up again.

Didn't you already post this idea in another thread?

It's not too obscure anymore . I've already explained that in another post - give it a read and tell me what you think.

Not sure if you're being serious or trolling

Any self-respecting insurance company wouldn't give you any product without you having sufficient security in the first place. There's a reason why insurance companies ask you whether you have a spiral staircase in your home, a trampoline, and other "dangerous stuff". They will not risk paying for your lack of caution. The same applies to insurance for bigger institutions.

We have to think about security in the first place. Only then we can start thinking about adding things like insurance on top of that.

Well, an exchange like this already exists: https://bitalo.com/why_bitalo/


First off: All Bitalo wallets are P2SH 2-of-2 multisignature wallets. One key belongs to the user (we never see it), the other one belongs to Bitalo (user never sees it). Now to tackle the problems above:

1) Bitalo, its employees or even server providers cannot move Bitcoins, because they only have one of two keys required for signing a spending transaction
2) A backup "lock time" transaction is signed after every wallet action, so even if Bitalo loses the keys, after "lock time" expires you can claim your Bitcoins (note that this is a feature that we're testing and not deployed yet, but will do very soon)
3) See no. 1. Attacker can only steal one of two private keys required to sign a transaction. To successfully steal Bitcoin an attacker would need to compromise *both* our servers and user's computer to steal both keys. Even then he can only steal from this one specific user, not all of them.

So what you end up is a wallet which you can inspect personally at any given time to see that you Bitcoins are still intact. You can just fire your favorite blockchain explorer, or even a watch-only desktop client and check it!

Oh, and you don't have to take my word for it. Just go to the site and inspect the code. Or ask someone to do so if you don't have the knowledge. The javascript code that creates and signs transactions is open, uncompressed, ready to be inspected.

And if that doesn't sound any trustworthy, you can actually look-up "Bitalo Aktiengesellschaft" to see that we are a real company registered in Germany as AG (like Inc. in the US) with 75.000 EUR founding capital, so we're definately won't risk doing anything stupid.

I know it's hard to understand because systems like Mt. Gox created a mindset in people that you are totally blind regarding your Bitcoins. That's not the case with multisignature-based services though!

Problem: People STILL don't know what happened to Mt.Gox coins. Whose hands they are now, when exactly they were transfered, what addresses the cold storage was on, etc., etc.
Solution: In a multisig service you can monitor your wallet in real time on the blockchain. If we somehow stole coins from you, you would know that immediately. We would have no excuse.

Problem: When a centralized service fails, often all users lose money. That was the case for Mt. Gox, inputs.io, Flexcoin and others.
Solution: You cannot steal from all users in a multisig service, unless Bitcoin itself has some fatal flaw (in which case we're all doomed). It could be possible to plant malicious javascript to the website, but that would be detected quite quickly and only a handful of users that were using the site at that specific time could be harmed. The "reward" is much, MUCH lower for a thief, so there's less incentive to risk a criminal act.

Sample scenario: let's say that at some point we have 10,000 BTC in our wallet (hint: we have *much* less at this moment). Most users only store few BTCs in their wallet, and only 5% of Bitcoins is in active usage at any given moment. So if we're lucky, we're get 500 BTC out before people find out. Is ~250,000 EUR worth risking jail time? For an individual, maybe. For a trade registered AG company with 75,000 EUR founding capital, not so much I think.

A solution for checking balance of a multisig address exists in the very thread you linked: https://bitcointalk.org/index.php?topic=287063.msg3435441#msg3435441

The good thing about our approach is that you don't have to take my word for it. All of the code that handles Bitcoin is in uncompressed Javascript for everyone to inspect. You can also check network requests to see exactly what's happening. Of course you need to have some knowledge to perform this kind of audit, but if you don't, someone else will. We couldn't possibly try to do anything fishy here that would go undetected.

Actually, there is a way to calculate the length of the transaction before sending it:


Where I is the number of inputs, O is the number of outputs in the transaction. This assumes that all inputs are spending normal "pay to address" outputs, and all the outputs are normal "pay to address" outputs as well.