Topic: [Idea] A proposal for a blockchain based *meta* reputational system (Read 929 times)

A couple of refinements - although I guess it's looking a lot like I'm talking to myself now.

By using the second decimal to indicate both a rating "area" and whether to rate positively or negatively (and putting the negatives after the positives in order to make it more expensive to rate negatively) then the CRC modulus can be extended to 6 digits (so now only 1 in a million chance of a "birthday" clash).


Although this could be useful over Bitcoin itself I am now beginning to think some sort of alt-chain might actually be preferable to accomplish this idea as then far more information could be stored with each tx.

Actually after some more thought perhaps this could also include sending a CRC32 or similar of the GPG proof letter (which would be published on the WoT website so others could copy and verify it).

Does anyone else see any potential value in keeping WoT information in the blockchain (or perhaps this would be viewed as creating more bloat)?

Hopefully this hasn't already been brought up in the similar named thread already but I thought it might be worthwhile to start a new thread to discuss the merits of designing a meta-reputation protocol that works via tx's in the blockchain itself rather than discussing a specific WoT solution.

The following are some basic principles:

1) Each WoT system would have its own specific Bitcoin address.

e.g. 1SampleWoT

2) Each member joining the WoT system provides a single address that will be used for that system (and which most likely would also be the same address used for all other such systems).

e.g. 1SampleMember

3) In order to activate a new "account" a member sends (from their specifically chosen address) a small amount to the particular WoT address.

1SampleMember -> 0.09 -> 1SampleWoT

4) If the user provides sufficient proof to the WoT owner (such as GPG sig with signed copy of the user address) then a tx containing a very specific amount is then sent from the WoT to the user's account address to indicate it has been activated.

e.g. 1SampleWoT -> 0.00000011 -> 1SampleMember (where the last digit is either 0 or 1 to say added or removed and previous digits are reserved to identify the "type" of proof).

If say some other kind of relevant item/document was accepted by the WoT then this would have another specific amount:
1SampleWoT -> 0.00000021 -> 1SampleMember

and if this proof was later to be rescinded then:
1SampleWoT -> 0.00000020 -> 1SampleMember

5) Once the member has met the minimum requirements to use the WoT they would be able to create a "rating" record for another member (which they could locate either via the other user's specific address or by say their email address using the actual WoT application).

In order for the rating record to be accepted the member would next send a very specific amount from their address to the WoT address (where presumably this amount would be copied and pasted from the WoT application). One possible way for this amount to be determined is as follows:

Take the CRC32 of the member being rated's address as a decimal value then take mod 100,000 and divide by 10,000,000 and add a rating multiplier and min. fee.

if the allowed "multiplier" values were:
.00000001=-8
.00000002=-4
.00000003-=2
.00000004=-1
.00000005=+1
.00000006=+2
.00000007=+4
.00000008=+8

then you might end up with an amount looking something like:

1SampleMember -> 0.05123455 -> 1SampleWoT

(with 0.05 being the min. fee required to send a rating, 12345 being the modulus of a CRC-32 of the destination address and 5 meaning +1)

Assuming that the details are correct then the WoT would then create a tx to the destination members address as follows:

1SampleWoT -> 0.00000005 --> 1OtherMember

The big advantage of this idea is that all WoT actions are audit-able through the blockchain itself allowing different software implementations to be written that can perform all their calculations (in very different ways if desired) without having to rely upon any 3rd party DB.