Author Topic: Tell me your thoughts about how reputation for KeyID should work  (Read 3321 times)

0 Members and 1 Guest are viewing this topic.

Offline toast

  • Moderator
  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
These are some of my early thoughts on a reputation system. I would ideally like to implement something similar to a credit score on the KeyID points system. The tricky part is reducing how much people can game the system. What I have come up with so far is a system where people can use their reputation score on one DAC (KeyID points on the DNS DAC for example) as collateral on loans on another DAC (a future Lending DAC).

You can burn money to raise your reputation points. One question to ask here is what is the the ratio between the amount of the asset burned to the increase in the reputation points? Also, how does it dynamically change over time? We could have a one-to-one peg between the shares of the DNS DAC and the reputation points. But then as the value of the DAC increases, the reputation of early adopters increases, which is not really what the reputation is supposed to measure. Perhaps it can instead be pegged to BitUSD once we have the BitAsset functionality enabled in the DNS DAC.

Burning money to lower reputation points does not make much sense to me. Obviously, the owner of the reputation points has no reason to do it, but how about other people? There is a free rider problem here. The public good is informing the public the true reputation of a particular user by lower the user's reputation after he does something bad or fails to do something expected of him. For example, if on some Lending DAC he defaults on the loan, the public would like to have his reputation lowered. But if it requires one person, or even a small group of people, to shoulder the entire burden of downburning for the benefit of the public, then very few people will bother doing it.

One possible way around this issue is to avoid the downburn mechanism on the DNS DAC entirely. We can take advantage of the Owner Key linking all accounts on different DAC together as one user, and require everyone who wants to evaluate a particular user to go through the blockchain of all relevant DACs to see what bad things the user has done. I imagine multiple centralized services can be built that do this, which will allow people to easily look up this information online.

But the services still need to be aware of all DACs in existence that the user could be participating on. For example, if there was some new Lending DAC that Bob was using to give a loan to Alice, Bob needs to make sure that the centralized reputation tracking services add this new DAC to their trackers or else Alice could choose to default on the loan without any reputation damage to her. It would be nice if one could cryptographically tie the activity on any DAC to the reputation points on the single DNS DAC, so that everyone has one central DAC to go to when trying to determine the reputation of a particular user. Also, this would have the additional benefit of not forcing all DAC activity onto a single chain that also managed reputation. For example, it should be possible to give out loans on a Lending DAC but still allow for defaulting on the loan to affect the reputation of the borrower on the DNS DAC.

The solution to this is to use the same concept behind atomic cross-chain trading. Users can create transactions with a hash of a password that can be spent only if the spender reveals the password. If this mechanism is used properly, it allows for fairly complicated communication between independent DACs that makes things somewhat like credit scores possible.

I can best explain this through a concrete example. Alice wants to borrow 20,000 BitUSD from Bob to buy a car. The loan is for 36 months with an APR of 5%. The contract of the loan requires Alice to pay Bob 600 BitUSD per month for 36 months. She does not have any collateral to back the loan, and, since the blockchain cannot seize a physical asset, Bob decides he cannot rely on seizing the car if Alice fails to pay the loan. Alice also currently has zero reputation points on the DNS DAC. However, Bob can check by cross-referencing with the Vote DAC that the account that Alice is using has been verified as a unique human being (this prevents Bob from being vulnerable to Sybil attacks). Bob decides to take a chance with Alice, but demands that Alice puts up some amount of her reputation points as collateral in order to act as a motivation for her to pay back the loan (reputation points can become negative).

First, all of the passwords are created and their hashes are exchanged. Alice creates passwordA and sends HASH(passwordA) to Bob. Bob creates passwordB, passwordC, and passwordD, and sends HASH(passwordB), HASH(passwordC), and HASH(passwordD) to Alice.

Then, Alice creates a new downvote collateral designated to Bob on the DNS DAC that will deduct 21,600 points (based on 36 months * 600 BitUSD/month payment * 1 point/BitUSD ratio) from her KeyID points if activated to stage 3. The downvote collateral starts at stage 0 and will automatically become void some specified time after being created unless it is activated to a higher stage before then. The downvote collateral can be activated to stage 1 by revealing passwordA. It can be activated to stage 2 if it is already in stage 1 and if passwordB is revealed. It can be activated to stage 3 if it has been 48 hours after it was activated to stage 2 and if passwordC is revealed. The downvote collateral could be made void anytime prior to reaching 3 if passwordD is revealed.  The deduction of points on the downvote collateral can be reduced at anytime with signed statements from Bob.

Then, Bob creates the loan on the Lending DAC. Bob sends 20,000 BitUSD into an escrow automatically managed by the loan. The loan contains the conditions that Alice must fulfill to pay off the loan (paying 600 BitUSD per month for 36 consecutive months). The loan is not activated until passwordA (the activation password) is revealed. The loan will automatically expire some specified time after being created unless someone reveals passwordA to activate it. If the loan expires, the contract becomes void and the 20,000 BitUSD in the escrow is returned back to Bob. However, once the loan is activated the 20,000 BitUSD held in escrow goes to Alice, and the loan contract is active. Any payments made by Alice to fulfill the loan are not directly sent to Bob, but rather held in an escrow automatically managed by the loan. To claim the escrow funds Bob has to publish a signed statement reducing the point deductions on Alice's downvote collateral by an amount proportional to the value of funds being claimed from the escrow. At anytime, the loan can be made void by revealing passwordB (called the void password) or passwordD (called the completion password). If the loan is made void after activation, any funds stored in the escrow are sent back to Alice (if it is made void before activation, the funds in escrow are sent to Bob). If Alice fails to make the payments as specified by the loan contract, she defaults on the loan. In the case of a loan default, any funds still remaining in the escrow are sent to Bob and the loan is void. If Alice successfully pays off the loan, the remaining funds held in escrow can only be claimed by Bob by revealing passwordD.

So, the course of events for creating the loan by two honest parties is as follows:
1. Alice and Bob come to an agreement on the terms of the loan.
2. Alice generates passwordA and shares HASH(passwordA) with Bob, while Bob generates passwordB, passwordC, and passwordD, and shares HASH(passwordB), HASH(passwordC), HASH(passwordD) with Alice.
3. Alice creates the downvote collateral designated to Bob with an expiration time of 72 hours on the DNS DAC using the stage 1 hash HASH(passwordA), stage 2 hash HASH(passwordB), stage 3 hash HASH(passwordC), void hash HASH(passwordD), and a deduction of 21,600 points.
4. Bob inspects the downvote collateral Alice created and verifies all the values are good.
5. Bob creates and funds the loan with an expiration time of 24 hours on the Lending DAC using the activation hash HASH(passwordA), void hash HASH(passwordB), completion hash HASH(passwordD), and the conditions of the loan. This is done no later than 24 hours after step 3, otherwise Bob doesn't create the loan, Alice lets the the downvote collateral expire, and they start over from step 1.
6. Alice inspects the loan Bob created and verifies all the values and conditions are good.
7. Alice activates the loan by revealing passwordA on the Lending DAC.
8. Bob takes the revealed passwordA and uses it to activate Alice's downvote collateral to stage 1 on the DNS DAC before 72 hours after step 3 to prevent the downvote collateral from automatically becoming void. He has at least 24 hours after step 7 to do this critical step.

After step 7, the 20,000 BitUSD is sent from the escrow to Alice and she is locked in the contract. She can use this money to buy the car. After step 8, Alice is locked in the contract in which if she defaults on the loan she will lose reputation points (or have her reputation points go negative). She needs to pay 600 BitUSD every month for 36 months to pay off her loan:

9. If Alice is able to make the current month's payment, she sends her 600 BitUSD into the loan escrow as fulfillment of her loan contract. If she is unable to make the payment, she defaults on the loan (goto step D10). Or, if Alice and Bob agree to renegotiate the loan, goto step R10.
10. Bob claims the 600 BitUSD in the escrow by signing a statement that lowers the point reduction in Alice's downvote collateral by 600 points.
11. Alice takes Bob's signed statement and broadcasts it in the DNS DAC to lower the point reduction in her downvote collateral.
12. Wait until next month. If this is the last payment, goto step 13. Otherwise, goto step 9.
13. Alice makes her last payment of 600 BitUSD into the loan escrow. At this point if her downvote collateral were activated she would only lose 600 point.
14. Bob reveals passwordD to get the remaining 600 BitUSD out of the escrow.
15. Alice uses passwordD to make her downvote collateral void.

On the other hand if Alice fails to pay off her loan:
D10. Any funds remaining in the escrow are automatically sent to Bob.
D11. Bob activates Alice's downvote collateral to stage 2 by revealing passwordB on the BitShares DNS DAC.
D12. After waiting 48 hours, Bob activates the downvote collateral to stage 3 by revealing passwordC, which deducts points from Alice's reputation.

Once any stage 3 activated downvote collaterals exist on an account, the account owner cannot buy reputation points in the regular manner (burning the money for points). The owner must first make all stage 3 activated downvote collaterals void by paying the person marked designated on the downvote collateral. For example, after defaulting, Alice might have -21,600 points on her reputation in the DNS DAC. If she wants to raise it to 1,000 points, she needs to spend 22,600 BitUSD. But the first 21,600 BitUSD needs to be sent to Bob via the downvote collateral (since he was designated on the downvote collateral) in order to make the downvote collateral void (making her reputation points equal to 0). Then she can burn an additional 1,000 BitUSD to raise her reputation points from 0 to 1,000.

Alice and Bob can renegotiating the loan at any time:
R10. Alice and Bob come to an agreement on the terms of the renegotiated loan.
R11. Bob generates passwordE and passwordF, and shares HASH(passwordE) and HASH(passwordF) with Alice.
R12. Bob creates and funds the new loan (likely with zero new funds) with an expiration time of 48 hours on the Lending DAC using activation hash HASH(passwordD), void hash HASH(passwordE), completion hash HASH(passwordB), and the conditions of the new loan.
R13. Alice inspects the loan Bob created and verifies all the values and conditions are good.
R14. Alice creates the new downvote collateral designated to Bob with an expiration time of 24 hours on the DNS DAC using stage 1 hash HASH(passwordD), stage 2 hash HASH(passwordE), stage 3 hash HASH(passwordF), void hash HASH(passwordB), and the new point deduction they agreed on. This is done no later than 24 hours after step R12, otherwise Alice doesn't create the new downvote collateral, Bob lets the the new loan expire, and they start over from step R10.
R15. Bob inspects the new downvote collateral Alice created and verifies all the values are good.
R16. Bob activates the new downvote collateral by revealing passwordD on the DNS DAC.
R17. Alice takes the revealed passwordD and uses it to make her old downvote collateral and old loan both void. (The order of R17 and R18 can be swapped.)
R18. Bob activates the new loan using passwordD on the Lending DAC. (The order of R17 and R18 can be swapped.)

From this point the steps are similar to steps 9 to 15 except using the new loan and new downvote collateral.

Attacks that will not work:
1. After step 3, Bob cannot activate the downvote collateral to stage 3 because he does not know passwordA yet and therefore cannot even activate it to stage 1.
2. After step 4, if the values on the downvote collateral are not what Bob agreed to, he can refuse to create the loan. Alice would then have to wait 24 hours for the downvote collateral to become void.
3. After step 5, if Alice disappears, Bob has to just wait 24 hours and the loan will expire and he will get his money back.
4. After step 6, if the values and conditions of the loan are not what Alice agreed to, she can refuse to activate the loan. Bob will eventually get his money back after the loan expires, and Alice's downvote collateral will eventually become void without Bob having any chance to activate it.
5. After step 7, Alice cannot make her downvote collateral void to create a collateral-less loan, because she does not know passwordD. Bob has plenty of time (24 hours or more) to complete step 8 before the downvote collateral expires and becomes void.
6. Anytime after step 7 but before step 14, if Bob for some reason activates the downvote collateral to stage 2 even though Alice has not violated the loan conditions, she can take the revealed passwordB and use it make the loan void. Bob will likely later activate the downvote collateral to stage 3 causing Alice to lose some reputation points. However, since the loan is now void and the downvote collateral has already been activate, Alice has no reason to keep paying the monthly payments. She can instead direct those monthly payments into paying Bob via the downvote collateral to get rid of the downvotes. The reason this is not a really an attack is because Bob doesn't gain a financial advantage in doing this. If he let Alice continue paying the loan he had a good chance of getting back his principal and interest. However, if he activates the downvote collateral he might eventually get back the principal and interest, or he might not. Also, Alice could take her time paying Bob to increase her reputation points. Instead of Bob receiving the 21,600 BitUSD over 36 months, he may only get it back after 10 years (or never). That is a huge opportunity cost for Bob. The only rational move for Bob is to not activate the downvote collateral unless that is his last option, meaning Alice defaulted on the loan.
7. After step 14 but before 15, if Bob activates the downvote collateral to stage 2 even though Alice fulfilled the contracts of the loan, Alice has 48 hours to reveal passwordD on the DNS DAC to make the downvote collateral void. Once the downvote collateral is void, Bob can no longer activate the downvote collateral to stage 3 with passwordC.
8. After step D11, Alice cannot use passwordB to make the loan void since she already defaulted on it and any funds in the escrow have already been sent to Bob. She also cannot make her downvote collateral void because Bob has not revealed passwordD.
9. After step R12, if Alice refuses to continue, Bob has to just wait 48 hours and the new loan will expire. He still has his old loan backed by Alice's old downvote collateral active.
10. After step R14, if Bob wants to try to simultaneously activate the old and new downvote collaterals to stage 3, he will fail and end up with the old loan conditions or the new loan conditions. If Bob activates the old downvote collateral to stage 2, he is forced to reveal passwordB, which is the void password to the new downvote collateral and the completion password to the new loan (which can be used to make the new loan void). If he activates the new downvote collateral to stage 1 and then stage 2, he is forced to reveal passwordD (void password to the old downvote collateral) and then passwordE (void password to the new loan), respectively. Whichever downvote collateral he activates first, he is forced to wait at least 48 after the first activation before he can complete the attack by activating both to stage 3. During this 48 hour period after the first activation, Alice either has access to passwordB or access to passwordD and maybe passwordE (or she may have all of the passwords). Let's say Bob's plan is to reveal passwordB, wait 48 hours, then activate the old collateral to stage 3, then reveal passwordD followed  by passwordE, wait 48 hours, then activate the new collateral to stage 3. When Bob reveals passwordB, Alice has 48 hours to make the new downvote collateral and the new loan both void (ruining Bob's plan). This forces Bob back into a condition that is as if the renegotiation on the loan never happened. Bob will eventually activate the old collateral to stage 3, causing Alice to lose some reputation points, but this reverts back to the same attack as attack 6 (with the same economic reasons why the attack does not make financial sense for Bob). Instead, let's say Bob goes with the following plan: reveal passwordD and then passwordE, wait 48 hours, then activate the new collateral to stage 3, then reveal passwordB, wait 48 hours, then activate the old collateral to stage 3. When Bob reveals passwordD, Alice has 48 hours to make the old downvote collateral void using passwordD (ruining Bob's plan) as well as to make the old loan void. If she has passwordE as well, she can activate the new loan with passwordD to get any money that may be in the escrow and then make it void immediately after with passwordE. Bob is forced to recover from the damage as best as he can by first making the new loan void if it hasn't already been activated, and then activating the new downvote collateral to stage 3. Although this will cause Alice to lose some reputations points, it is no worse than her losing reputation points from activating the old downvote collateral to stage 3 (which is not financially beneficial to Bob as discussed already), because otherwise she wouldn't have agreed to the renegotiated terms of the loan. Finally, doing the operations concurrently or in different orders only makes the problem worse for Bob.

Also, this concept could be extended to tie assets on other DACs as collateral for a loan on the lending DAC. For example, imagine instead of a downvote collateral that reduced your reputation points by a certain amount, we had a lien contract that instead transferred ownership of a .p2p domain to the lender (and also prevented the borrower from transferring ownership of the asset to anyone until either the lien was made void or after 72 hours beyond the expected date that the loan should be paid off). This could introduce some economic attacks however. For example, if the value of the underlying collateral goes up high enough, the lender might decide to just activate the lien at the cost of not receiving his loan payments just because the collateral value makes it worth it. One way to get around this would be to mark the maximum amount of value the lender can get from the collateral on the lien contract and reduce this value with every payment of the loan the same way the reputation point deduction value was reduced. Then, if the lien is activated it causes the underlying collateral to go on an open market auction instead. The proceeds from the auction are first used to pay the maximum value the lender is owed, and any remaining funds would be returned back to the borrower. There is still the economic attack that if the lender estimates that the value of the collateral in an open auction is very likely to be higher than the amount the lender will eventually be paid, the lender may wish to just activate the lien to get paid immediately instead of eventually being paid over the duration of the loan. One way of working around this would be a time-based multisig. The lien could be setup so that after the time the loan is expected to be paid off, only the stage 1 to 3 passwords are needed to activate the lien. But before that time, signatures would also be needed in addition to the passwords. It could be an M of N multisig, with keys held by arbiters who decide whether or not the borrower has actually defaulted on the loan.

I am interested in getting feedback from the community on this idea. What are some possible attacks or economic flaws in this system? Also, to further the similarities to credit scores, are there ways of increasing one's reputation points without having to just buy it? I think it would be really cool if successfully paying off a loan could allow the borrower to not only make the downvote collateral void, but also increase her reputation points by an amount proportional to the original point deduction value on the downvote collateral. The problem with this is that any implementation I've been able to think of can easily be gamed. People could just create loans to themselves to boost up their reputation points for free.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Just a few random ideas:
- A KeyID holder could put x amount of y in escrow. A trusted third party controls the escrow. The keyid holder attributes a certain claim with his deposited y. The more specific the claim the more trustworthy will he be seen AND the more secure for the keyid holder it is to have no struggle getting his y back if he kept the claim: E.g. In case someone has an argument with me and claims I defrauded him/her and the trusted third party decides for my opponent then the trusted third party has the right to burn y (dividend burning...).
- the web of trust could get really advanced: How many recommendations do I have, how trusted are the ones that trust me and how trusted are those that distrust me
- the web of trust could be combined with a web of credit (the higher your credit range the more trust points you get in the credit / financial trust category) https://github.com/zeroreserve/ZeroReserve/wiki
- there could be different types of trust points: financial, non financial honesty,...
- I could participate in a prediction market with my KeyID and publish a bet that goes like "My research that proved that xy is true will not be proven wrong by a trusted research institute / by one of the following research institutes: ........" If I am proven wrong then my KeyId trust point for scientic credibility go down... Then there could be a risk category (makes strong claims that differ a lot from mainstream vs. only claims mainstream things) and a reliability category (how many of my bets have I won).

Overall I think being able to measure trust and credibility + a political awareness that does not allow for bailouts could change society more (in a positive way) than all the current decentralization narratives (trust less interaction/money etc.)!! Delegates would be one obvious application....   
« Last Edit: August 05, 2014, 06:30:46 pm by delulo »

Offline Riverhead

Since it would be hard to factor in the behavior of bad actors since bad actors can make good actors look bad on purpose I'd say the longer term advanced rating would be more like an age/experience thing.  This ID has been around for X amount of time, been involved in Y transactions that are worth an average of Z shares/coins/whatever.

Age would be the primary driving factor.  Would be a real long con setting up an ID for six months just to burn it in a scam.
« Last Edit: August 05, 2014, 05:28:34 pm by Riverhead »

Offline toast

  • Moderator
  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
This thread is just for longer-term ideas about an advanced reputation system.

This is independent of the "Magic Points" upburn/downburn which is already implemented and is just for fun and status.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

I am lost with page rank/edge values.

Proof of burn for novelty/status is about what I would expect.  You are throwing away funds to increase the status.  It is much like the "proof of burn" phrase popularized in the crypto-world.  It demonstrates you have more to lose if you start to scam people using that ID.  A bit of a strange concept but if you were to start transacting a lot of business it could be valuable to some degree.  I suppose it is something vaguely similar to a bond.
I speak for myself and only myself.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
...read it. I understood it this way: You can buy a KeyID for KeyIDcoins and the amount you bought it for defines the degree of your trustworthiness.
 
What does that "pagerank w/ edge values" mean? What does "proof-of-burn for novelty / status" mean and what is it useful for? Adding trust points everytime you use your KeyID (for example when sending an email with it)?

Quote
The biggest challenge I see is how to prevent people from buying their rep and then using that to rip people off.
Agree to this. But it can be said that a KeyID is always trustworthy if the amount the other one could loose is less than the KeyID cost. And since I can use this KeyID many times I would make economic sense for me to buy one (if everybody agree one KeyID as a standard).

I could also imagine that one could accumulate different types of trust verification methods: Buying a KeyID for price x, web of trust / collecting recommendations from others, associating a state issued ID with the KeyID.

It could also work without much network effect needed when an encrypted messaging app uses KeyIDs and only KeyIDs. 

Toast if you want many people to contribute you might want to explain the concepts and problems more understandable.
« Last Edit: August 05, 2014, 05:13:24 pm by delulo »

Offline Riverhead


Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
KeyID is keyhotee? Where is the post/whitepaper that defines what KeyID is?

Offline Riverhead

Sort of PoS in another person?  Proof of Integrity? Like cosigning a loan.  Could also look at how the credit agencies score people and adapt something similar based on actions in the blockchain.  The biggest challenge I see is how to prevent people from buying their rep and then using that to rip people off.

Offline toast

  • Moderator
  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I have a suspicion it looks something like pagerank w/ edge values that look like "I bet X that N won't defraud anyone"
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.