Topic: Reputations (Read 1010 times)

If I'm correct and being thorough, BitCoin has the following (dis)advantages (feel free to tell about possible corrections/additions):

• Anonymous
  Pros : essentially hides you for whatever reason you want
  Cons: you have no idea who you're dealing with
• Secure
  Pros : transaction is secure, irreversible
  Cons: no chargebacks/refunds, wallet file is lifeline
• Beneficial
  Pros : free currency from deflation/mining
  Cons: early adopters/mass miners (not a major issue)
• Open-source/Independent
  Pros : easy to find out what goes on and keep everything clean
  Cons: no backbone to keep everything going (countered by the fact that people value BTC, if only because they own some)
• Independent
  Pros : self-sufficient, no reliance on central organization
  Cons: no central organization to rely on

Most of the issues I listed either deal with not knowing what you're getting into or are countered by various built-in mechanisms (coded or psychological). Anonymity of the receiver is bad in some cases. Face-to-face deals may end badly, and 100% online services might require escrow services, which face the same problems (trustworthiness, or, conversely, central authority). The irreversibility and lack of insurance makes bad deals permanent. The lack of central organization in general might cause a lack of trust in those who one deals with or the system itself.

The only real solution is a recorded reputation system. (Yes, I am aware that it has been previously suggested, and I can't say I've read every single post on the matter) It would have to have the following features (some in common with the BC protocol):

• Distributed/Anonymous
• Irreversible/Inherently Restricted
• Fast/Convenient
• Reliable/Trustworthy

To be effective, a rep system would have to work within a BC client or added to the protocol (preferably the latter). This ensures both distribution and anonymity. Assumably, one's BC address identifies a user who reps and the user whose record it goes on. This could be propagated in some fashion similar to BTCs. Restrictions must also be placed to ensure security and spam prevention. There must be restrictions on amount of reps that can be given by any one person at any time, as well as security mechanisms which verify the uniqueness and validity of reps. For convenience and speed, reps must be qualitative and quantitative (from a previous thread, I know). Numbers might be easy to transmit and use, but often a textual description of one's experience with any BC address might be necessary. A simple limitation of the character set and length would allow for 1000s of reps to be recorded and transmitted fairly quickly. If the need arose, perhaps a full Unicode charset and far higher length limit could be compressed, given a minimum length restriction higher than the small message maximum. As for reliability, the issue comes from the unknown factors involving giving rep and receiving it. Spammed reps and inaccurate reps are an issue. An easy resolution to both is to have requirements and mechanisms in place to evaluate whether any given user's feedback is trustworthy (such as formulas involving overall rep, small BTC fees, etc.) and ways to respond to the feedback. The best way to validate feedback, is, of course, to attach each rep to a transaction (and require this be done) and factor in the transaction size. (In this case, only the sender can provide feedback, since transactions forward are irreversible and so favor the receiver)

It may also be prudent for the sender to specify type of transaction (purchase or donation) since it makes no sense to provide reps based on rewardless donation, as well as time alotted for product/service receival (with a maximum of something like 3 months), in order to ensure that there aren't a mass of forgotten customers who come back to blackmail with mass negative-repping.


Maths:
Reps are on a scale of -100 to 100, and only consist of one number.

Reputation Value (Constantly changes, but only by date, which is consistent) :
((RGO + 100)*(TransactionSize)*(RepScore))/((RepAgeWeeks + 1) * 200 * (UnknownConstant))

The RepGiversOverall is merely an average of the total values of all reps received, and 100 is added so that a negative scoring does not become positive if the giver of rep has a negative overall rep. Division by 200 limits this RGO+100 to between 0 and 1. (1 assuming a perfect 100 RGO, and 0 assuming a -100 RGO) Transaction size is multiplied in, and an "UnknownConstant" is divided by to keep this factor reasonable. Note that the overall affect of transaction size should be limited within certain sizes (perhaps .5 and 1.5) even given extra division, for exceptionally small/large transactions. Also, it should be clarified again that reps cannot exceed 100 nor fall under -100. RepAgeWeeks means the rep's age in weeks, which should make extremely old reps insignificant enough to be deleted eventually, and keep overall reputations current. (After about a year, even 100s or -100s only amount to about a 2 in total worth) The +1 merely prevents division by 0 if the age is less than one week old.

If it actually needed explaining, the RepScore refers to the rep giver's opinion (i.e. the score that they felt the receiver deserved).

Since the reputation value formula can account for age of rep, transaction size, and the giver's trustworthiness, the overall reputation of any person can simply be the average of all received reps' total values (after formula). Of course, it is easily possible and preferable if the number of reps recorded for a BC address is also displayed along with the average.

Give me constructive criticism, flames, "TL;DR", whatever you can come up with. I'm a newbie, so I'm OK with it. (Also, maybe you can tell, but I have way too much free time and am addicted to the Internet)