However, it would be sufficient if I could somehow determine that someone that I knew had tipped the vendor.

Of course, I don't want my friends to see that I had tipped someone, or all of those of whom I have tipped. I just want it to be possible that they can see my tip, within an aggregate poll, only if and when dealing with that vendor.

See section 5.2 of http://www.cs.stevens.edu/~mdemare/pubs/owa.pdf

Allow me to disagree (with the last sentence). If you can see that a certain vendor has spent a total of, say, 100 BTC on fees, to build up a reputation, then it doesn't make financial sense for that person to try to scam you in a 1 BTC transaction.

Scamming 1,000 people for 1 BTC would require having 1,000 open orders for 1 BTC each at the same time. If a vendor who has paid 100 BTC in fees has over one hundred 1 BTC pending orders, you'd probably be wise to stay away. And the software can guide you in making this decision.

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.

There have been some behavioral economics experiments showing that people are quite willing to make sacrifices to punish offenders.

I realize now the system described above is faulty, as the vendor must not be able to hide transactions with a low rating. Also, of course the review value shouldn't be specified by the buyer before he has received the goods. But I'm pretty confident this can be worked around with the right protocol.

Every buyer who buys something from a seller can review them. It's part of the cost of the goods.

Escrow - same deal.

Edits - this does seem too simple. Is it just naive? Perhaps it doesn't exclude circular transactions and gaming it.

In Silk Road the cost of producing fake reviews was the commission cost of the sale.

I feel like the much better system is to increase the available information about transaction and/or review volumes associated with a particular account -- that makes it much easier to filter out bullshit, and mimics the way fakes are detected on the rest of the internet.

eBay works this way [1], and I believe this is how Silk Road operated as well, although I'm not sure.

Merchants who pay for positive reviews for themselves and negative reviews for others have greater expenses than merchants who refrain from this, and, consequently, are less competitive.

Imagine a market place with hundreds or thousands of vendors (which is the size an established market place will grow to, if not much larger). Let's say the average total sale volume per merchant is $10k (I think that's a low figure). To nudge all your competitors' total review score 10% in the wrong direction you'd have to buy 1,000 * $10,000 * 10% = $1M USD worth of items from them, and leave all of them a 1 star feedback. Does this sound like an economically viable business approach?

Paying for positive reviews for yourself is cheaper than that, but you're still less competitive than the merchants who actually satisfy clients, and don't have to spend funds to increase their own rating score.

I'm not saying you can't combine this approach with something else, that might very well be the best solution. But I do think the best solution will require paying for reviews, in some way or another.

> I feel like the much better system is to increase the available information about transaction and/or review volumes associated with a particular account -- that makes it much easier to filter out bullshit, and mimics the way fakes are detected on the rest of the internet.

I think I would need more details on this approach to understand what you're suggesting. How would you achieve this in a distributed system? And how do you get around the problem of vendors being able to increase their review score for free?

[1] http://pages.ebay.com/help/sell/fees.html#how

a) ebay does NOT work like this. you leave reviews of merchants when you've done business with them, not for pay.

b) silk road does not work like this.

c) you're now imposing a tax on the market which costs everyone more, disproportionately benefits the wealthiest, and generates confusion. great job.

d) how is this not clear? if you add a gold star to someone's review when they have actually purchased from a merchant through your system, that gold star can be evaluated in any number of ways and help weight reviews properly. like, numerically weighting authenticated reviews more heavily. or whatever. there's obviously a downside, which is that unlike yelp, nobody is using their real personality, and there's some benefit to changing ones' personality if one is worried about the legal consequences of ones' actions. but on silk road this doesn't appear to be a significant barrier -- there are enough persistent personalities that it's pretty easy to discern the credible from the questionable.

e) you didn't positively answer the original question: has this ever worked? it seems nice based on one single argument (tax on lying) but not based on all the ancillary problems...

When the buyer creates the unsigned multisig transaction, he could request the token from the vendor, so the buyer gets a token in exchange for the unsigned transaction. The token could simply be a unique, random number signed with the vendor's public key.

Upon completion of the transaction (multisig transaction is signed by two parties and published to the network), the buyer could publish a special transaction (the "review transaction"), referencing the vendor's ID (his public key), the token, and the review score/value, along with an optional comment.