@KM "most of these wallet services seem to use a 12 word mnemonic password, which means about a 8 - 14 character password"
Is it 12 words, or 8-14 characters? That's a big difference.
It's 8 - 14 characters. The software doesn't care about the words, and those are only there to help human memorization. If you end up inputting the words, they just get translated back into that 8 - 14 char password, and that's the only part the software cares about.
" a) the company password / seed which will be sitting in their database somewhere" Not using a company provided multi sig service would solve this. There is no need to use a company. Thus bitgo is not a good option.
Guys like BitGo are fine, and there's nothing overtly wrong with them. Just don't buy into the hype that they're oh-so-secure, and don't put more than you're willing to lose into them. I can almost guarantee over the next 12 months we will see some major thefts from these oh-so-secure multisig wallets.
Matt, any ideas on something better than muti sig? It isn't perfect but it is a lot better than anything else we have right now.
That's the million dollar question, and many developers of higher caliber than me still don't know the answer. I personally like my new implementation, but the one downside is it isn't trustless, or well, can't be marketed as trustless. The software is developed to NOT store the private keys, but your users don't know that, and will have to trust you're not storing them.
On the flip side though, these multisig wallets aren't trustless either, even though they're marketed as such. If the site owner is nefarious, it takes nothing to add a few lines of Javascript to fire off AJAX requests, and steal all user's seeds. I am going to offer the whole multisig + client side encryption thing as an option in my implementation, so site admin will be able to choose between the two. However, I'm going to put a stern warning regarding the client side encryption one.
Then my implementation is a little less user friendly as well. When conducting a send, they have to input both, their chosen wallet password and upload 1 of 2 QR code images they get upon registration that look like:
Then obviously the standard 2FA, IP restrictions, SMS verification, etc... plus optional delayed sends, geographic restrictions (eg. only sends from Chicago allowed), amount restrictions (eg. flag anything over 2 BTC for additional authorization), etc. Then both, mandatory and optional multisig transactions. The mandatory part is so every send is signed by the software, so if someone gets your private key, they can't create & broadcast a raw transaction to the blockchain.
Then for optional multisig, you'll be able to define a friends list, and rules. For example, enter 5 of your friends, then define rules like "anything over 0.5 BTC requires 2 friends to authorize", "anything over 2 BTC requires 3 friends to authorize", etc. For each friend, you will define a security question and answer. If the friend does NOT have an account in the software, it will also generate a bitcoin address + private key for them, and you'll have to send them the private key, as it won't be stored anywhere in the db.
Then when you conduct a send, it's going to e-mail all your friends, and say "LiamLennon is conducting a send you need to authorize". If they have an account in the software, they can just login, and there will be a menu allowing them to authorize the send. If they don't have an account, they click a link, answer the security question, and enter the private key. Once enough friends have signed the transaction, it gets committed and broadcast to the blockchain.
And a bunch of other shit. I'll e-mail you here shortly with details and a demo. If you wanted to use it, free of charge for you obviously.