The idea is that you can say create a fund with say 3 keys. One is given to the middle-manager, one is given to a senior manager, and one is given to a computer. The middle manager can go on and use up to 80% of the budget. He simply creates a transaction, signs it with his key, then sends it off. The computer sees it, and then does various fraud-type checks. It checks if the receiving address is a whitelisted partner address (e.g. a supplier) and if the amount falls within reason given payment history for example, and if the transaction doesn't use up more than 80% of the budget. It then co-signs it and the bitcoin is released.
For anything more, the computer simply won't sign it according to its programming. So the middle manager must go to the senior one to request permission to release earmarked funds.
It's just a simple example but you could move lots of the finance to a completely digital system, do immediate software-based accounting and program governance rules into the software, and spit out periodic transparency reports. Will be interesting to see when something like this gets integrated into existing ERP packages someday.
I get that multi-sig and bitcoin can be good, but as long as you already have the decision-making and power setup of a corporation, this is a marginal benefit. I would see this technology being more useful for trust-type situations where you might want to give a lawyer, a beneficiary, and a guardian a key. Or any sort of situation where power is actually split between multiple entities - seems like the boss still has all the power in the situation described.
Key hijack in 5... 4... 3...
Browser crypto isn't secure. One way to offset the risk is to use a browser plugin to perform the crypto operations, and even that isn't really a security guarantee.
When you combine an incentive to break crypto (money) with a straightforward route to breaking it (browser crypto), you get a pretty dangerous situation.
It is completely unheard of in the financial industry (and usually technically impossible before cryptocurrencies) to have a bank give away their "middle man" access of people's money and empowering their customers with complete control over their finances.
All the best luck for this product, though.
Our multisig vault relies on BitcoinJS, which we had audited by an external consulting firm. We also don't allow multisig vault creation on browsers which don't support crypto.getRandomValues()
Actually, that's pretty far from the standard arguments: http://matasano.com/articles/javascript-cryptography/
That's pretty much the seminal work of why browser crypto is insecure.
The issue isn't whether the primitives you're using are secure. It's that the security of your primitives can be hijacked by any third-party javscript you load into the page. Any attacker that can gain a foothold into your javascript execution environment can trivially subvert your security.
> COINBASE KEY: The only key that Coinbase stores.
> SHARED KEY: Encrypted with your password and stored
> both by you and Coinbase.
We have no ability to access multisig vault funds without the user passphrase, which never touches our server.
Good question!
Your local client and local wallet are fine, until your keys are stolen by malware. Multisig scheme also attempts to fix that flaw.
EDIT: multisig scheme with user's key on Trezor. This way you are also protected fully from viruses stealing your local key.