Multisig Tutorial / Explanation

I've spoken to a ton of Hansa customers/vendors over the past few days and its apparent that Hansa didn't explain how multisig truly works. They taught the basic mechanics of it on how to send coin, but many people failed to understand the importance of a few things, such as the Redeem Script and how to use it. I want to help demystify multisig and teach what to look out for - not just how to send coins to an address - which we all know how to do.

A Multisig Address Composition

A multisig address, in a 2 of 3, is comprised of 3 bitcoin addresses/public keys and obviously requires 2 signatures to make a withdrawal. Sourcery requires an electrum wallet (use a brand new one, not used for anything else) from both vendor and buyer. Hansa did this differently - they required just one address from buyer and vendor. We cycle through. We do this for safety reasons. When you use the same 3 addresses, the exact same multisig address and redeem script is created. We felt by reusing 2 of the 3 addresses was an opsec risk. If someone compromised the market, assuming that market rotated the address even, it would not be many combinations to reconstruct multisig accounts, check the history and know that a buyer and vendor did business together and what amount. B/c we use 3 electrum wallets, all rotating, the number of combinations of 3 skyrockets. This is what makes Sourcery's more complicated in some sense - each transaction will use a different bitcoin address and hence a different key.

To illustrate, Hansa just required the vendor and buyer to each specify a SINGLE address used in transactions. So if buyer1 and vendor1 did a transaction they'd have a multisig like:

buyer1-addy, vendor1-addy, market-addy

Even assuming that market-addy rotated, it wouldn't be too much work to build a script that takes all the buyer's addresses, all the vendor's addresses, and then runs combinations on them, reconstructing multisig addresses. If the market's address didn't rotate, then the combinations are fairly trivial and LE would have time to do it. If it did rotate, it'd make it more complicated, but probably still within reason with enough power and distributed computing. They'd just try all the combinations, check the history of the recreated multisig, see if a transaction happened, if so, they know that BuyerN and VendorN did business on Hansa and would have the bitcoin chain - even if the data was wiped diligently.

We rotate each buyer, vendor and the market. Now the combinations are pretty high and probably too many to recreate. Esp if the buyer and vendors end up changing wallets periodically.

Redeem Script

When you are given a multisig address, you are also given a redeem script. SAVE THE REDEEM SCRIPT!!! You will need it if you want to make a transaction off the multisig address. Also, verify the redeem script. You can decode with electrum via the command line.

electrum deserialize [redeem script]

or use a local copy of Coinb.in. When you decode, you will see the 3 BTC addresses. You should do this step to ensure that a malicious actor (a market or some man in the middle). When you decode the redeem script, you will see the three BTC addresses that compose it. One should be yours. Check electrum wallet you gave Sourcery and ensure that address is somewhere in your wallet. You won't know with certainty about the market's address and that's okay. The third address should be the vendors. We have a feature called "Address Signing" which lets a vendor sign a batch of BTC addresses with their PGP key and is presented on the site. The buyer can verify the sig to verify that the address belongs to the vendor. This is where Hansa fucked people. They changed the addresses up and nobody knew how to verify this. Multisig is secure. BUT, it requires some due diligence on both buyer and vendor.

Once you verify at least 2 of the addresses (one being the buyers and one the vendors), and you verify the multisig address from decoding the redeem script matches what the market gives you, you can be assured that its a good multisig with the right keys.

Finalizing

In a normal scenario, when you finalize with Sourcery, Sourcery will create a withdrawal using the redeem script to put in the vendor's deposit address. We will then sign the transaction with our key. We then send this to the vendor. The vendor takes it, signs it, and can broadcast it on his own OR send back to Sourcery for broadcasting. That's it.

When The Market Can't Sign

So the market goes down, is unavailable, etc - you need to be able to complete the transaction. You need that Redeem Script mentioned earlier! Either party can then create a withdrawal - using the Redeem Script - and sign the transaction. Then they send to the other party who takes the transaction, signs it, and broadcasts it. And done.

Hansa didn't properly explain the underlying mechanics of multisig from what it seems and buyers and vendors didn't truly appreciate the Redeem Script or know what they needed to do if Hansa went down. Also, it appears that Hansa/LE used their own addresses for at least 2 of the keys, thus edging out the vendor and maintaining full control of the multisig towards the end. At this point, multisig is useless to the vendor and buyer.

This is just a rough draft of trying to high level explain how multisig works and what you need to do.

TL;DR

  1. Copy the Redeem Script and save locally!
  2. Decode it, verify that at least your address is in the multisig signers. If Vendor has signed their key with Sourcery's signing function, verify the signature and verify that address is present.
  3. Keep Redeem Script in a safe place.


Comments


[1 Points] YarrIBeAPirate:

Yeah, or people with just use the market that makes this feature the easiest and most automatic.

people are lazy.


[1 Points] ice_cream4breakfast:

Here is the problem I see with this approach. I the case of hansa the Feds changed the buyer public key to their public key. So the Feds had 2 of the 3 keys. A vendor doesn't now the buyers public key to compare it to, so the vendor is none the wiser. We need to have that buyer pgp sign their public key and the vendor pgp sign their public key. That way the market can not change the keys and rig the multi sig in their favor. You could rotate addresses it would be time consuming to sign these public keys. But signing and verifying the public keys for multi sig transactions need to be done from this point on.


[1 Points] dankgrilled:

When would you guys start using monero? I have kept my eyes own your site for a while now but still would like to see monero. I think most people would be very hesitant to use your site without monero now.