c475f46de2
(since everyone has a browser, text is obsolete) modified: docs/libraries.md deleted: docs/libraries/pandoc_templates/style.css modified: docs/merkle_patricia_dag.md modified: docs/mkdocs.sh renamed: LICENSE.md -> docs/rootDocs/LICENSE.md renamed: NOTICE.md -> docs/rootDocs/NOTICE.md renamed: README.md -> docs/rootDocs/README.md renamed: RELEASE_NOTES.md -> docs/rootDocs/RELEASE_NOTES.md new file: docs/scalable_reputation_management.md modified: docs/scale_clients_trust.md modified: docs/set_up_build_environments.md modified: docs/writing_and_editing_documentation.md deleted: pandoc_templates/style.css
45 lines
5.9 KiB
Markdown
45 lines
5.9 KiB
Markdown
---
|
||
lang: en
|
||
title: Scalable Reputation Management
|
||
---
|
||
|
||
# Scalable Reputation Management
|
||
|
||
The hardest part of the cypherpunk plan is scalable reputation management.
|
||
|
||
We plan to have a global store of named rhocoins, thereby squaring Zooko’s
|
||
triangle. Associated with each name will be a nameserver, which tells you how
|
||
to contact that individual, his websites, etc, which have public keys signed by
|
||
the rhocoin private key. You start out assuming that he and all his associated
|
||
data are on that nameserver, and it gives you a permanent or temporary redirect,
|
||
signed by a public key authorized by his rhocoin private key to give such
|
||
redirects, which key contains a limit for that key and all the redirects.
|
||
|
||
He has a collection of positive reviews, that chain to spent coins in the blockchain, via his offer or payment request, and also to a recent global hash. But what about negative reviews?.
|
||
|
||
For that, we need reputation managers, two or three, that hold a replicated collection of negative reviews.
|
||
|
||
The payment request chains to a name being monitored by the reputation monitors, but the person making the payment is generally anonymous. So he could manufacture positive reviews in unlimited number by sending payments to himself. So the reputation monitoring entities need to monitor spam, much as google has a problem with link farms. If the same entity gives reviews to entities that do not spam, or is unreasonably prone to giving frivolous negative reviews. One way around this is to give reviewers reputation points on the basis of the money they have paid to entities with good reputation. Paying one ro to a hundred entities gives you more reputation than paying money one hundred ro to one hundred entities..
|
||
|
||
We really want to subdivide reviews into good, grey, and possible spam. which, suggests a logistic curve over the sum of a bunch of logistic curves.
|
||
|
||
ln {B+∑ ln(P~i~+1)}
|
||
|
||
This means it is not enough to connect the review to the rocoins. Needs to be connected to a cheap but permanent identity. So, the transaction chains to the payers through a Merkle-patricia tree, which links to each payment request, which links to the durable named identity of the wallet receiving it, and the durable but possibly nameless wallet paying it. This part of the chain is not on global canonical blockchain, but in the private blockchains of the receiving and paying wallet, which can be visible, if the payer or the payee make parts of it public. Any conversations about the payment before the transaction are directly rendered immutable by the global blockchain, so we know the that Ann, the party that controls the wallet posting a review made the payment, but, without Bob’s cooperation, cannot know that parts of the conversation that Ann claims were seen by Bob after the transaction actually were seen by Bob. We can, however, if either Ann or Bob makes the payment request public, know that Bob requested payment for such and such, and Ann paid. If someone is telling fibs about what happened after the transaction, we can know from the global shared blockchain that Ann is not fibbing about what Ann paid and Bob promised to deliver.
|
||
|
||
The transaction is on the global shared canonical blockchain, and links through a Merkle dac, which is not on the global shared canonical blockchain, to immutable information about who made the payment, who received the payment, and why. Subsequent conversations about the transaction are mutable, unless, of course, they result in another payment. If there is a continuing relationship, and continuing transactions between Ann and Bob, then the entire conversation up to the most recent payment is immutable.
|
||
|
||
The problem is sybil attack. A transaction creates reputation for buyer and seller, creating an incentive to create a network of dummy transaction, to generate positive reputation for scammers, and to attack the reputation of good actors.
|
||
|
||
But, we assume that there are a small number of big centralized reputation brokers, with big machines and custom algorithms that they continually tweek.
|
||
|
||
One solution is to have sixty four different reputation colors, each represented by eight byte number. Known entities, that we have external information indicating that supply real goods and services, get a mix of colors reflecting the source and content of that external information. Unknown actors randomly and automatically get a color from a different palette. A transaction causes the parties get more of the same color as the entity that they transact with.
|
||
|
||
Known link farms get colors from the bad palette.
|
||
|
||
So, the main network of legitimate actors will tend to get all the same color mix, because every legitimate customer buys from lots of legitimate sellers, and every legitimate seller sells to lots of legitimate buyers.
|
||
|
||
Networks of fakes will get their own distinct color, because the reputation circulates inside that network. The big giveaway will not so much be bad colors versus good colors, but the failure of colors to homogenize. All the good actors will tend to develop rather similar colors, each link farm will have its own distinct color. Every transaction inside your own little group will tend to result in more of your group color, and less of the general mix.
|
||
|
||
With forty colors, we have a trillion different composite colors, so we randomly assign each seller entity that collects reviews an initial pool of distinct color, and they get additional color from feedback on each transaction of the entity transacted with. If feedback from a wallet never seen before, it has no color, so they get more of their own color, and it gets a pool of the color of the entity they gave feedback to proportional to the amount paid. Every completely unknown seller entity gets one hundred units of various randomly chosen colors. External reputational indications result in additions of color reflecting that external information.which will get mixed in with throughout the network of real actors and real feedback.
|