Show Posts
31
Silk Road Discussion / Re: How Multi-signature transactions could screw us over
« on: April 28, 2014, 06:53:04 pm »
Scenario 1:
Market decides to changes vendor passwords
In this instance, the marketplace admins could start changing vendor passwords and signing keys. This does not "steal" the vendor's funds, as there is no balance to steal. All escrowed transactions by the vendor are protected under the protocol, and the vendor holds their balance. This exploit allows for the marketplace admins (or, really, ANY hacker/phisher et cetera) to pose as the vendor and receive transactions at their modified bitcoin address. If it were a simple hacker, this wouldn't really accomplish much, as they wouldn't be shipping out the same product and fulfilling orders. However, it is the marketplace admins with one of the three signing keys, and if they were to infiltrate a vendor account and pose as said vendor, they could receive transactions and release the funds to themselves -- regardless of whether or not the product was shipped.
This exploit exists currently under the traditional escrow model as well, under the means of collusion. Support accesses a vendor's account, locks them out, and instead of emptying their wallet balance and escrow, in the multisig model they can only generate and sign new transactions on behalf of the vendor's said reputation.
This kind of scam wouldn't last long at all, but is worth mentioning nonetheless. It also allows for the market to claim "hack" and offload responsibility onto some anonymous "hacker" entity, should they decide to do so.
Credit for the above speculation is from Reddit: https://pay.reddit.com/r/DarkNetMarkets/comments/23l2h6/torescrow_is_a_scam/cgy1jv3 (clearnet)
We could also technically change everyone's passwords both now and following multi-sig implementation, release the keys, abscond with the BTC, and join the "Market admins steal everyone's money" club. Your argument boils down to "They could rob us, ya know?". Not an original idea and one we have proven we are above.
Quote
Scenario 2:
Market admins posing as a false buyer
This scenario works on the idea that the market admins would create buyer accounts, place orders from vendors, and claim no-shows, ensuring 100% that a refund would be received because they control 2 of 3 keys in this situation as well, posing as both a buyer and retaining their original arbitration key.
For this to work, the admins would have to be receiving product at their own/drop address, which, as we saw with chronicpain on SR1 (although under different circumstances with LE involved) is indeed a very shitty idea. Any smart administrator of a darknet market should not be receiving shipments from vendors of any kind at any address close to them, but I suppose it's their decision if they want to (see: Ross ordering fake IDs from King of Clubs to his own address).
Again, this exploit is possible with traditional escrow as well, as support can collude.
This is no different than your first scenario as it comes to down the same cause. If you are going to rattle off different ways we could scam you, best add a scenario where we just shut down the market and blah blah blah...How about a vulnerability that does not involve us basically being cunts? Thanks.
Quote
Scenario 2.5
This is called scenario 2.5 because I see it as an extension to scenario 2. It works in a very similar way, with admins creating buyer accounts and ordering product, with the extension that they open their own vendor account. I detailed this to vendor Checkpoint in the following post:Quote1. Admins make fake buyer account
2. Admins own a seller account, recieves an order.
3. Initiate transaction with you (Checkpoint, in this frame of reference)
4. Admins forward their own order's address to you (order quantity would be identical)
5. You ship (unknowingly) to admin's seller account's buyer.
6. Admin's buyer (from seller account) receives, releases funds to admin. (Or, admin signs transaction to their seller account, stealing funds, but buyer receives pack anyways since they can't realistically be sending to their own address as that would be the worst OPSEC I've ever seen)
7. Admin's buyer account (your buyer) claims no-show, refunds the transaction and signing using the two keys they control.
Even at a 50% refund rate, this potential exists, and it's sad because this could drive a good vendor's reputation straight into the ground, all from one malicious entity.
....sigh. The thing about scenarios is that they generally need to be different.
Quote
That said, this problem exists now, with any vendor, under the same traditional escrow model. I could make a new seller account and say I ship from NL, forwarding all my buyer's info to Checkpoint and turning around and claiming a no-show on my end. I pocket my buyer's funds, and subsequently 50% of Checkpoint's funds are lost at his refund rate (he receives 50% of the price of his product per his rate), leaving him without product and double-dipped on a scam.
-------
Multi-sig is effective at removing the most common hack we see (or rather that admins claim) of a hacker coming in and draining escrow and deposit balances. Why any hacker with access to hot storage wouldn't change passwords of administrator accounts and keep the market is beyond me, which again brings up the question of legitimacy whenever these supposed hacks roll around. I suppose that's what PGP signing is handy for, but that can be manipulated as well (admin goes hey! I've been hacked! Here's a signed message! (while controlling the market the whole time))
The true way that SR must implement multi-sig is with the inclusion of some form of trustless arbitration. This means, without SR controlling really ANY keys. Maybe a portion of SR's commission can be diverted to a volunteering third party at random (any SR user) who would receive a small thank-you for arbitrating the transaction. This eliminates the attack vectors I've mentioned above to a very considerable degree, and makes it even harder for funds to run off as missing.
The implementation I've outlined above is especially good because it has the potential to stimulate the SR economy with third-party arbitration, as a user could directly turn those funds around and spend them for goods. And, guess what -- they've effectively got no connection to the arbitrator by means of IRL procuration. While I don't believe a third party arbitrator is going to make a commission enough to furnish their entire family tree with "free" drugs, it does in part stimulate the economy of SR by putting the funds right where they need to be to be re-introduced into SR's ecosystem.
TL;DR Multi sig is a step in the right direction, but we should be hitting the ground running with trustless arbitration and remove responsiblity for SR, while allowing them to receive commission for running the site and establishing connections.
If any of you have been reading Joshua Dratel's motion of defense for Ross, specifically about simply hosting a site where he does not take part in transactions, this further works to this advantage. Dratel notes this as the "landlord scenario" where a landlord provides a home (in this instance, a website) for drug transactions to take place, and by way of this receives drug money for rent, yet is never held responsible (at least under US law) for allowing the transactions to occur, even knowingly. If you all haven't read this document, you should -- it is extremely compelling and speaks volumes that Dratel is a damned good lawyer.
Thoughts on this, anybody? Are there other current implementations of which I am not aware that address the above scenarios as I've outlined?
Yes there are actually current implementations that address your concern, being that you seem to think the market itself needs to be taken out of the equation. They are called street-level drug dealing. Care to list possible scenarios for that turning out badly or shall I just direct you to Google so you can look up "drug deals resulting in violence"?
Apologies if my post is blunt, but you didn't actually come up with anything that doesn't involve the admins finding various clever ways to scam people. These are not flaws in multi-signature transactions. These are just scenarios where we decide to be assholes. Our actions of late prove otherwise.
unlucky item 67 days