I am curious how Multisig was implemented at Hansa. One thing that caught me by surprise when I published my scripts for signing transactions was that the same bitcoin public key for buyer and vendor are used and re-used at Hansa. I leanred this randomly in a discussion with another person here. This is how I realized that transactions at Hansa in bulk are easily signed and at Sourcery I needed to write these scripts. The way we built it is to use the electrum BIP wallet to cycle through keys. We did this for an increase in privacy. But it makes signing in bulk difficult. But we felt cycling through keys was safer and afforded more privacy for past transactions.
- Question: Did the signing key from Hansa change each time? I would hope at least that one would rotate. Otherwise if buyer and vendor do business again and the same key from Hansa is used, the multisig address generated would be the same - so it wouldn't change. So I assume at least Hansa's signing key rotated?
Seeing that LE basically swapped keys out and everyone deposited to a multisig address owned by the Dutch Authorities, it tells me that buyers probably don't understand the nuances of how to determine whether the multisig address is genuine or a swap. The problem with not checking the multisig is exactly this - the market can swap out the vendor and market signing addresses with ones they control, the buyer doesn't know any better and just deposits.
This is where the redeem script comes in. People, when you do multisig, check the redeem script on a third party site? Like run Coinbin offline. Check the signing addresses. One address should be yours. One address is the vendors, and the other the market. Now, one problem - how do you know that the vendor's signing address is actually one the vendor controls? This is a weak point I believe unless you have gotten a bonafid confirmation from the vendor that he indeed controls the address in the redeem script. One "workaround" we did was put up scripts for "bulk signing" bitcoin addresses by the vendor. The script is run by the vendor (offline of course) and is just a series of electrum calls. It gets the list of addresses in the wallet, then the vendor signs each with his PGP key that should be "well known". If the vendor does this, the buyer can see the signed address on his contract, then pull it down, verify the sig and be better assured that the vendor does indeed control the address. B/c at the end of the day, if you don't do something like this, a buyer has no clue if the multisig address is actually using the right keys for the multisig!
Obvioulsy with people depositing into a multisig with a balance in it - was this normally how it was??? I could sort of see it if NONE of the signing keys are cycled (including the market) and the buyer and vendor had done business before. The same address will always be generated for the same keys. But I can't imagine this is the case. So a buyer should expect that the multisig address be empty and never used. I guess buyers never check this independently.
If you want to do multisig, learn how to use the Redeem Script. Have a method for knowing for sure (you can't trust the market to say it is) that the vendor's bitcoin addy used in the multisig actually belongs to them and they control it. Otherwise a market can just swap in any address they control and have complete control over the wallet.
I am not familar with Hansa's actual procedure for multisig (specially 2 of 3). It difered from ours. We did things a little bit harder by cycling keys each time you participate in a transaction b/c its guaranteed to generate a unique address. Plus we felt that the number of combinations would be insane to generate if you had to match up a ton of addresses in each of the wallets. however, if the buyer and vendor only have one key that they keep reusing, I'm not going to do the math, but I can venture that the number of combinations is exponentially reduced - making it possible for LE to potentially try to crack the combinations, generate multisig addresses, see if they had been used and then follow a transaction that has been completed in the past - even without actual data from a database.
I'm really curious if Hansa at least rotated the market signing key in transaction. If not, that's really not good.
EDIT:
Follow up question: On Hansa, did you have to deposit to a Hansa controlled wallet? If so, that's not good and this is why (and honestly, multisig is irrelevant at this point). At Sourcery, a buyer deposits straight from his own wallet right into the multisig. This is the safest. So you know what, I forgot that Hansa made you deposit into their own wallet first before it got pushed to multisig. This negates security of your coin. A market should not do this. At Sourcery, a buyer deposits into the multisig directly and then sends a second transaction to Sourcery to pay transaction fees to the market. And before depositing, they should use the redeem script to validate. The problem with Hansa was their IMPLEMENTATION. If you pushed coin to a hansa wallet and trusted them to push it to the multisig address you are exposed to a vulnerarability.
This is super informative, thanks.