Why not give the option to use BIP32 extended keys? Not supporting them because of perceived lack of support from other tools just propagates the problem of no support. I use a BIP32 chain for
getting payments, even though it means that my 'wallet' is mainly a bunch of shell scripts. Because you only need to get the private key when crafting spend tx, private key management is simple because you can just store one encrypted file with your extended private key, and ask for it when needed.

Also, there is support for using bip32 to do multi-signature work in my new program, pymultisigtools -- https://github.com/Zah6ooheew/pymultisigtools -- which will see a new release shortly after I figure out a user interface for signing multiple transactions at once.

Are we talking about markets for buying goods or exchanges from/to fiat?

If you are talking about a market for items, this setup is bizarre. Why would you have a server generate your keys, ever? Key generation is not something you trust to anybody.

The correct way to do this is to use 2 of 3. Each purchase needs three keys: buyer provides a public key, vendor provides a public key, market provides a public key. This is then used to create an address for payment for each sale.

Market gets hacked? They only have one signature. You get hacked? Only one signature. Vendor hacked? Only one signature.

Normal transaction? Market signs tx to pay vendor, vendor completes tx with their signature.
Cancelled order? Market signs tx to refund buyer, buyer completes tx with their signature.
Disputed transaction? Market signs tx, gives to buyer or vendor to complete depending on situation.
Market obliterated by aliens? Tx is signed by buyer and vendor, in whichever order works best.

Main problem: people tend to lose their keys. Don't ask me how they lose important stuff like that, but it is the main problem.

I will admit this idea had not occurred to me, due to my poor knowledge of BIP_32. Most end-users I don't think use two wallets as I have suggested several times -- and that is a serious security problem. In fact, most of them don't even take the simple precaution of backing up important info like their Electrum seed or their PGP keys or generating a separate revocation certificate in case of key compromise or loss.

One of the problems in trying to get new features into this is I am not the developer of the plugin that is being used. I knew virtually nothing about bitcoin before working on Electrum except that it used ECC and that the proof of work was used to do away with a central authority for processing transactions. I spent many hours trying to get my output from Electrum to match byte for byte bitcoind's output before I realized that ECDSA isn't always deterministic! My goal at the outset was simply to be able to sign a transaction so I could complete it as a user of the site without having to download the entire blockchain. Since the devs of the site turned it into a plugin, I have only supplied patches on their forums for problems users have had. If I had known about that javascript-based site, I would've likely never worked on this at all. Of course, if I knew what I know now I would've likely used pybtctools to accomplish my goal.

It won't work, with base electrum.

However, this patch applied to 1.9.5 will make it work, with the exact syntax as bitcoind -- you have to supply the private key yourself however. It won't look it up from the wallet.... at least I don't think it does. I never tested it that much as this code was turned into a plugin later on.

http://pastebin.com/B7x0fTQr

Since I have written the vast majority of the multi-sig part of that plug-in, I feel I need to respond to this.

The plugin works by generating new recieve addresses (beyond the gap limit), and then giving the public key to the user. This is passed into the web site, which creates the P2SH address to send the coin to as well as presenting them with the redeemScript (so that they could verify with the person they were purchasing from that the address was with their public key as well).

When you need to complete a transaction, you are provided with json that looks like

The plugin then signs the transaction and allows you to broadcast it or save it. If you used the plugin to create the public key it needs, it will be found automatically. If you created a public key somewhere else when you created the escrow address, then you are prompted to supply private key that will be used to sign the transaction.

The main problem with the implementation is it mixes up your keys for making p2sh wallets and the keys you use to handle your coin. I've suggested to all the users they create a seperate wallet that is only used for signing transactions that is kept offline. A full BIP_32 implementation would be a lot nicer, but the plugin is essentially a quick and dirty hack which allows people to use the site without having to use bitcoin-qt.