Hacker News Reader

It doesn't help me to know that an anonymous person had tipped an anonymous vendor. That doesn't add much value.

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.

Perfect application for a cryptographic one way accumulator.

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

> It's not important for me to know that an anonymous person tipped an anonymous vendor. That doesn't add much value.

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.

Maybe. But, doesn't it make sense for a vendor to spend 100 BTC in fees to build a reputation so that they may scam 1,000 people in 1 BTC transactions?

Yes, it does. Which is why you have to have the trust factor incorporate the transaction volume for each vendor (calculated based on how much they've paid in fees).

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.

You can use proof-of-sacrifice to give reviews a cost. Look up OP_RETURN in relation to bitcoin.

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.

Might also help if the burn amount could be denoted as positive or negative. If zero is the worst, it might just mean "didn't care." If someone spends a significant sum on a negative rating, you know he was pissed.

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

The burn amount shouldn't be proportional to the rating.

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 seller who sells their product is able to review a buyer. It costs them.

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.

Yes, it is too simple. If a vendor wants to pose as a buyer and post fakes reviews if there is no cost to the transaction itself then there is no cost for the vendor to post a fake review.

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

When has this ever worked in the real world? I mean, in theory parts of it are nice, but conflating it with the spam problem is probably not accurate; merchants will just pay for positive reviews for themselves and negative ones for competitors. I ask honestly: are there examples where this has worked?

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.

> When has this ever worked in the real world? I mean, in theory parts of it are nice, but conflating it with the spam problem is probably not accurate; merchants will just pay for positive reviews for themselves and negative ones for competitors. I ask honestly: are there examples where this has worked?

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

Sorry I didn't see this before.

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...

Reviews could be to the marketplace as exchanges are to Bitcoin: intentionally not part of the architecture.

What about creating some sort of token which allows a user to review a seller? The token itself can only be generated by a successful and verified transaction. One transaction would equal one token which would allow only one review to only that specific seller.

Yeah that makes sense. But I'm not sure the token should only be generated upon a successful transaction. This would make vendors not want to issue the token if something goes wrong.

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.

This is true, but how do you charge reviewers for reviewing? What we realy need is a review system that can't be gamed by those being reviewed.