The security of our APIs lies in the fact we don't store private keys - the user signs their own transaction.
If I understand it right then that is a lie.
In reality you ask the user to sign a transaction that you create for him.
This is extremely dangerous for the user (pretty close to signing a blank cheque) and I don't like how you try to downplay this flaw.
Your API is broken by design and puts anyone who is naive enough to use it at great risk. You should take it offline.
From their documentation it appears Catheryne's comment is accurate regarding the user signing their own transaction: "Sign the returned hex string and post it with the transaction to txs/send. The multisig address is now funded." I'd have to sign my own transaction in my own wallet to fund a third wallet that was multisig enabled.
Can you clarify why you think they are lying and why you think it is so dangerous that you think they should take down their site? That's a fairly big claim from someone and I think it requires a bit more explaining to do before you go all nuclear on them. It's justified if true, but that would need to be established.
Disclaimer: I know Catheryne via the Bitcoin meetup in SF, which I attend regularly.
I'm not even sure what benefit that is supposed to bring, but apparently they believe it is easier for developers to use a remote JSON API instead of a local bitcoin library[1] to generate transaction payloads.
The problem is that it is not trivial to inspect and verify the payload before signing it. It is an opaque hex-string. In order to verify that it contains what you want it to contain you need the same machinery that you'd use to create the transaction yourself in first place.
So if you choose to verify the transactions they make up for you before signing them then you could just as well generate the payload yourself.
If you don't verify the transactions they make up for you (which is what their documentation seems to expect) then you put your wallet at the mercy of whoever controls their servers. That is a very bad idea!
Meanwhile, creating and signing bitcoin transactions entirely in your own code, without talking to any remote party, isn't very hard to begin with. Mature libraries and toolkits exist.
Here's how to create a multisig transaction using the sx toolkit: http://sx.dyne.org/multisig.html
However, decoding and verifying a complex transaction takes about the same amount of work as generating it yourself to begin with...
Their documentation clearly expects you to blindly sign whatever tx they make up for you. There's not a word on verifying the transaction locally before signing it.
