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.