Multisig question.

[Clockwork7777]

 Hello,

I am a long time lurker here, and this is the first time I joined to make a post here. So here goes

Assume you wanted to create a site (shop, market, w/e) that were to use multisig transactions between peers to ensure optimum safety. (Alice, Bob, Shop cannot scam each other or run with the money)

What are the drawbacks on this, excluding user friendliness? I understand the question is quite broad, so there is no need to be exact to the detail on the answers here, but I just want to know, in general, what other problems would one face while solving the whole trust issue  with multisig addresses. (For example, it depends more on txid, would transac malleability problem hurt things etc.)

Appreciate any input.

Thanks

[jcrubino]

txid is only a problem if you use zero confirmations

multisig drawbacks are that few people understand or are aware of the contracts available in the vanilla bitcoin protocol.
The intuitive UX for the average user and optionally auditable for the expert users are the key to getting the contracts into the mainstream of bitcoin users.

[Clockwork7777]

Yes but, assuming one was building a site and wanted to implement it there, what else could go wrong beside alienating the average user or user screw-ups? (assuming everything is coded in well enough) 

I am sorry if this has been asked before, I am just trying to understand things better.

Thanks

[yakov]

The users might cheat you out of your commission. The buyer and seller have an incentive to agree to sign a transaction that sends all the money to the seller, nothing to your site.

However all transactions are public on the blockchain so you could see them doing this and take action, such as banning them.

It's unlikely because I guess your commission will be small (bitmit had 1%) and people would generally recognise how useful your site it and won't be so nasty. I know there is a drug marketplace called The Marketplace which uses 2-of-3 multisig. I wonder what they've done if anything against buyer and seller collusion.

Or you could have a model where commission is only collected if there is a dispute, or where the seller pays a small fee for the advert, or where buyer and seller have entry fees, etc etc.

[fbueller]

I'm working on adding multisignature transactions to Bitwasp at the moment. Alienating some users is a concern, but I'm hoping tools like https://coinb.in/multisig will help make it easier, and not expose them to their clients console interface.

I am handling the event where users might try cheating the site by expecting any inputs associated with the multisig address to be spent in a transaction where the hash of [{address,amount}...] matches what we expect, from when we generated the unsigned transaction. If the hash matches what we had stored, then the transaction is legit. Otherwise they scammed the site.

[waxwing]

Interesting point you raise yakov. Effectively such colluding counterparties would be using your site only for peer discovery and not for arbitration service. Perhaps the fee structure can take account of that - a small membership fee which is paying for the information, and an arbitration fee in the multisig which could be defaulted on by signing transfers in a side channel. I guess if you had the former (a membership fee), you could also enforce the latter, as you say, by banning or similar, but you might not need to ..?

In a way, the economic incentives align quite well; as an arbitrator, what actually costs me is when I have to actually do any real arbitration (i.e. the cases where both sides agree cost me no work or time), so it kind of makes sense that I should only be able to extract an arbitration fee when I actually need to do some work.

[yakov]

A membership fee might be counterproductive, especially since this kind of stuff benefits from the network effect. Information wants to be free, it's hard to get people to pay for it.

People use craigslist for free peer discovery. But it makes its money by selling special ads that rise to the top of search listings. That covers craigslist's server costs.


I've checked and it seems on The Marketplace almost all trades are ended by arbitrator and seller together signing a transaction, the buyer is merely expected to click Finalize on the page after receiving their drugs. The commission-on-every-trade model is easy to enforce then if the buyers are not technically competent or interested, but I wonder what happens after easy-to-use multisig wallets are released.

What we need: a graph showing the number of transactions to and from 2-of-3 multisig addresses plotted against time.

[Clockwork7777]

Hello

Thank you for your inputs. They are greatly appreciated. 

How hard would it be to enforce the commission? Illegal marketplaces can do whatever they want afaik, but is there any better way to implement the fees other than doing it as side transaction and just refunding them on every "failed" purchase?

Regards

[yakov]

How hard would it be to enforce the commission? Illegal marketplaces can do whatever they want afaik, but is there any better way to implement the fees other than doing it as side transaction and just refunding them on every "failed" purchase?

You seem new to bitcoin. Refunding on every failed purchase is not a thing that happens.

Transactions can have multiple outputs. The marketplace simply provides a raw transaction with most money going to the seller but some going as fees to the marketplace.

So I found this example of a likely multisig payment in a recent block.
https://blockchain.info/tx/9637a88575f472f4290daebb3db6e41f179038acc2b020b36b6bc7d2fd198cdf
92% of the money goes to one address and 8% goes to another, so it's probably a 2-of-3 arbitration with a fee. Doesn't have to be anything illegal, http://bitrated.com/ is pretty popular too.

[Clockwork7777]

I am not new to bitcoin, I never meant to say that the transaction could be revoked, I just did not know you could put multiple outputs in a multi-sig transaction too.  Perhaps I phrased it wrong.


Thank you all though, you have been helpful

Regards

[fbueller]

What we need: a graph showing the number of transactions to and from 2-of-3 multisig addresses plotted against time.

I'm working on this at the moment. Parsing the blockchain is taking forever.. Took an hour to get to 83000. Then a further 19 hours to get to 128500.. I'm recording txid/vout/address/blocktime for all payments to scripthash addresses (version byte \x05).

Once I have this I should get a nice plot of payments to multisig addresses, and then rescan looking for vins spent from multisig addresses. There'll probably be a good deal of lost BTC sitting at these addresses.

[jcrubino]

What we need: a graph showing the number of transactions to and from 2-of-3 multisig addresses plotted against time.

I'm working on this at the moment. Parsing the blockchain is taking forever.. Took an hour to get to 83000. Then a further 19 hours to get to 128500.. I'm recording txid/vout/address/blocktime for all payments to scripthash addresses (version byte \x05).

Once I have this I should get a nice plot of payments to multisig addresses, and then rescan looking for vins spent from multisig addresses. There'll probably be a good deal of lost BTC sitting at these addresses.

You can list multiple addresses and spends in the output of a transaction.  

Make sure to add your own as the multisig raw transaction requires a change address.

The change address is the address an extra coins go to from the transactions.  

It was not explicitly covered in the multisig section of the wiki last time I looked and I lost all my coins as a result... all my testnet coins which are still a bother to get without a gpu rig.

donations for testnet coins mfZqJvCNgJPL2y84KgamRcxUw9SUMPmej9 if you find this helpful.

[yakov]

What we need: a graph showing the number of transactions to and from 2-of-3 multisig addresses plotted against time.

I'm working on this at the moment. Parsing the blockchain is taking forever.. Took an hour to get to 83000. Then a further 19 hours to get to 128500.. I'm recording txid/vout/address/blocktime for all payments to scripthash addresses (version byte \x05).

Once I have this I should get a nice plot of payments to multisig addresses, and then rescan looking for vins spent from multisig addresses. There'll probably be a good deal of lost BTC sitting at these addresses.

That's fantastic.
Multisigs are often used for trustless escrow, I guess many spends from them will be to two addresses. Another useful measure, if it's not too much trouble, could be to plot the proportion of multisig spends to exactly two addresses, and out of those, the % fee for arbitration. So in the tx I linked above the fee was 8%. Would be interesting to see the going rate.

You can list multiple addresses and spends in the output of a transaction. 

Make sure to add your own as the multisig raw transaction requires a change address.

The change address is the address an extra coins go to from the transactions. 

It was not explicitly covered in the multisig section of the wiki last time I looked and I lost all my coins as a result... all my testnet coins which are still a bother to get without a gpu rig.

donations for testnet coins mfZqJvCNgJPL2y84KgamRcxUw9SUMPmej9 if you find this helpful.

At least it was only testnet 
You can get them from this faucet https://tpfaucet.appspot.com/

That's true for every transaction by the way not just multisigs. Some unlucky people have lost serious money that way.

[fbueller]

That's fantastic.
Multisigs are often used for trustless escrow, I guess many spends from them will be to two addresses. Another useful measure, if it's not too much trouble, could be to plot the proportion of multisig spends to exactly two addresses, and out of those, the % fee for arbitration. So in the tx I linked above the fee was 8%. Would be interesting to see the going rate.

That would be interesting to learn! At the moment I'm logging payments TO multisig addresses: the address, txid, vout, block, time block was published.

My script died due to a typo at the first pay-to-script-hash address: this was actually in 170052. http://blockexplorer.com/block/0000000000000a3876ec1947700445b4d517d10dec868b9d4a53fcf25e59f188 I've just restarted my script, it'll take a while to finish. I'll run a second report on the finished data, to scan for inputs in multisig addresses which were spent, giving us a new: from_address, txid, vout, the redeemScript (encodes the public keys, and 'm of n'), and amount.

We should be able to learn:
 - was it a 1-of-2, 2-of-2, 2-of-3?
 - how long did the funds sit in the multisig address until they were paid?
 - how much the escrow fee was in a 2-of-3, if there are two outputs.
 - I think I should be able try identify payments from themarketplace.i2p, since out of (buyerPubKey, vendorPubKey, adminsPubKey), I heard that the buyer just clicks finalize and the admin signs. So, out of all payments leaving 2-of-3 addresses, how many were signed by the last two public keys?

Who actually has a site with multisig at the moment? We should be able to see a spike when anyone starts to play with them.

I'll try put up a site showing metrics on multisig addresses once I get a set of data to work with.