<blockquote>
<p><em>This is a Bisq Network proposal. Please familiarize yourself with the <a href="https://docs.bisq.network/proposals.html" rel="nofollow">submission and review process</a>.</em></p>
</blockquote>
<p>In a discussion with <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=17677608" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/mpolavieja">@mpolavieja</a> we developed a feasible solution for a distributed reputation system based on the account age witness but including a proof of a bank transfer. It is bases on an existing trusted element (arbitration) and from there we can build up a hierarchy of trusted traders.</p>
<p>The arbitrators could sign with their key all account age witness data from fiat traders who had completed the trades (fiat was trnasferred) and which have been older then 2 months. The P2P network payload data will contain the signature, the account age witness data (hash) and the public key of the arbitrator and it is distributed to all nodes. Anyone can verify the signature with the public key of the arbitrator. This will create the root of trust where the arbitrators are a semi-centralized trust root and they give those traders trust level 1.</p>
<p>We apply that to both buyers and sellers. It is guaranteed that the buyer did not has made a chargeback in that time frame. The seller does not give that guarantee but it is very unlikely that the scammer used his own account to receive the Fiat so it seems reasonable to include sellers and gain 50% more of initial level 1 peers.</p>
<p>For signing we might need to use the hard coded EC key as only that is persistant. The normal signature key would not be available anymore once an arbitrator has revoked as it is only part of the arbitrators P2P payload data. We need to think here about the future changes with integration of check for validity of an arbitrator depending on acceptance and locked up bond in the DAO. The current hard coded pubKeys will become obsolete then.</p>
<p>If a new user with a fresh account is trading with one of those traders who have received a  signature from the arbitrators the trusted user will sign the untrusted one's account age witness data. By that he will gain trust level 2 but it will require some aging until it is considered trustworthy (e.g. the peer could still make a chargeback in the upcoming weeks). We could use a linear function to derive some trust score from that age.</p>
<p>It is an open question if a single signature is enough here or if we should require up to 3 signatures from 3 different trusted traders. Collusion risk between a potential scammer with a trusted peer is probably a very low risk. If we require too many it leads to some privacy loss for the trusted peer as with his public key anyone can see how often he has traded. If the number of such signing interactions are rather low the visible nr. of trades is much lower than the real number of trades and the problem is less severe.</p>
<p>Another open question is if the signing only would apply to buyers or both to buyers and sellers? Again if the seller is the scammer he would receive the funds on a stolen account which is unlikely that he want to do. If the victim sees incoming money he might get alerted as well and the account can get closed. So we prefer that the process of building up trust happens faster by doing it both ways rather that to be too restrictive.</p>
<p>All that signing and data publishing would happen without user interaction in the background.</p>
<p>A bigger challenge than the implementation of that part is the user experience aspect. We need to find a way to communicate those complex concepts in a simple way to users: The untrusted user need to understand why he has a low trust score and what he can do to increase that. The trade peer need to understand what risk he is willing to take (by trading with low trusted peers) and what are the usability consequences (delayed payout).</p>
<p>It has to be combined with the other proposal about the delayed payout. We need to support both the current account age witness system and that enhanced one with the signature of a trusted peer who has trades with you. With the current weaker account age reputation we are not protected against a scammer who is willing to wait for 1 months without using the stolen account. With the enhanced system one's account age would only start aging once you have done a trade with a trusted peer. New users would prefer to trade with a trusted peer so that they can get faster a good trust score. All that need to be packed into the UI in a way to not confuse users and to not add too much requirement for reading and understanding all that background. Probably the biggest challenge in that proposal....</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/78">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNREN6TYLLEB5ITMTJTPRY5TLANCNFSM4HHTGH4Q">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJFFTNV76YB73NYTQQJ4PZLPRY5TLANCNFSM4HHTGH4Q.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/bisq-network/proposals","title":"bisq-network/proposals","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/bisq-network/proposals"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"Distributed reputation system (#78)"}],"action":{"name":"View Issue","url":"https://github.com/bisq-network/proposals/issues/78"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/78",
"url": "https://github.com/bisq-network/proposals/issues/78",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>