Interesting project. I believe solving the part about reputation is the hardest part. I posted my thoughts on this on a Hacker News thread regarding this, and I thought I'd share them here, on the list, as well:
As far as I can see, the essential problem with decentralized anonymous marketplaces is that reviews need to cost money. Plain and simple. Good reviews have great value, so they need to have a non-zero price. A vendor's review history is the indicator by which a potential customer will assess whether a vendor is trustworthy or not, and a vendor should have to pay to achieve a trustworthy reputation - if good reviews are free, and you can make money from good reviews, they would have little value. This is the reason spam emails are so frequent: you can make money from something that costs very little. If reviews were near-free, good reviews would be as plentiful as spam emails. Free reviews means vendors can make sock-puppet accounts, fake a transaction, and leave a five-star review to themselves. With Silk Road, they take x% of the value of each transaction (or if not, that's at least how it should be), so if a vendor seeks to inflate their review score, they will pay a price for it. In fact, a good overall review score for a vendor - as far as I can tell - is the sum of all the review "values" (1 to five stars) multiplied by the value of the transaction in question. So a vendor with 10 five-star reviews on 10 orders of a value of 1 BTC each, would have the same score as a vendor with a single five-star review on a single transaction with a value of 10 BTC. Both these vendors would have paid the same amount of money to get this, equal, review score. I've thought a bit about this, and I don't see how this can be solved in a decentralized market, with no middleman to tax transactions, and make sure that vendors can't get free reviews. ***After having written the above thoughts, user "hendzen" on Hacker News, suggested we use a form of proof-of-sacrifice to make sure reviews have a cost for vendors. This led to the following rough sketch of how such a system could look. Again, I haven't exactly thought about the next part for long, but I don't - on the top of my head - see why this can't work.*** (in reply to hendzen): Without having thought about it further, this might work: All we would need to do would be to "burn" a certain percentage of the transaction, eg. by sending it to an provably unspendable address (a hash160 of all zeros, for example). So the transaction from the customer to the vendor, paying for the goods, would be a 2-of-3 multi-signature transaction (of which the customer, the vendor and the escrow agent each hold a copy), with an output (let's call it output1) to the vendor (paying them for the product), and an OP_RETURN output which specifies a review value (for example, 1 to 5). output1 will then have to be redeemed in a new transaction (created by the vendor), and this transaction will include an output that burns x% of the amount redeemed from output1, and an OP_RETURN output that specifies the vendor's public key. To calculate the aforementioned total review score for a vendor, all you do is check every transaction that contains the vendor's public key in the OP_RETURN output, and take the sum of the review value multiplied by the amount of bitcoins burned for each of these transactions.
-- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
