There is an important part of the multisig puzzle missing in the article: the need for an out of band protocol to communicate copayers for joining a wallet and spending bitcoins. This is something that Copay (https://copay.io) does but there is no standard way to do this.
I haven't read how the wallets are implementing multisig but what is this out-of-band protocol you are talking about?
If I want to spend coins from a multisig address, I create a transaction, sign it with my key and send it to the other party who can sign it and relay it or send it back to me and I can relay it. It's a very simple protocol.
The way you send it to another party is not standarized. Think in your grandpa, he would want to just create a transaction while everything else happens behind the scene. Sending an email is a manual process and you need to recheck if the other party received it.
Beyond this, there is a bigger reason: if you want a risk service like Sig3 or CryptoCorp you should adapt the system to every multisig wallet while if you have an standarized way to communicate you wrote an standard system.
You can send an email(messaging) behind the scene, need not be manual nor is a task that require standardization.
Sig3 is more secure theoretically but its an overkill & non-requirement nevertheless. Why not have Sig4? Sig100 would be theoretically even more secure!
> You can send an email(messaging) behind the scene
So... how Coinbase handles it, what is the format? Coinkite? Copay? The nth popular wallet? You can easily see that you need a standarization, it doesn't matter if its by email, morse, or slack.
Now, Sig3 is the name of a service, with Sig3 you can use any n-m wallet.
Former employee at BitPay (maker of Copay) here. There were indeed discussions about standardizing the out-of-band protocol, and I hope something comes of it soon. It'd be huge for the ecosystem.
Two cents from an apps developer: few months ago I've implemented multisig on top of BitcoinJ(generic signing code providing a signature dependless on current state of a partially signed transaction). The experience was truly horrible. Bitcoin documentation is a mess, BitcoinJ documentation is also outdated, so finally I investigated BitcoinJ source code pretty deeply to go forward.
BitcoinJ is no frills and unfortunately doesn't have much development manpower despite its popularity. I'm actually in the midst of trying to debug an edge case issue I'm hitting within BitcoinJ itself.
13 comments
[ 6.1 ms ] story [ 37.0 ms ] threadThere are other issues. For example, Coinbase doesn't support it fully. See this thread for more info: https://twitter.com/coinfabrik/status/661992065841123328 but other wallet services like Coinkite does: http://blog.coinfabrik.com/independently-generating-your-pri...
If I want to spend coins from a multisig address, I create a transaction, sign it with my key and send it to the other party who can sign it and relay it or send it back to me and I can relay it. It's a very simple protocol.
Probably that part.
Beyond this, there is a bigger reason: if you want a risk service like Sig3 or CryptoCorp you should adapt the system to every multisig wallet while if you have an standarized way to communicate you wrote an standard system.
Sig3 is more secure theoretically but its an overkill & non-requirement nevertheless. Why not have Sig4? Sig100 would be theoretically even more secure!
So... how Coinbase handles it, what is the format? Coinkite? Copay? The nth popular wallet? You can easily see that you need a standarization, it doesn't matter if its by email, morse, or slack.
Now, Sig3 is the name of a service, with Sig3 you can use any n-m wallet.