<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>Here I offer some ideas to bolster bitcoin seller confidence through 2 techniques:</p>
<ul>
<li>verify buyer identity though multiple methods <em>for each trade</em> before any money can be sent to seller</li>
<li>mark/sign payment accounts which fail this verification step, and immediately blackball them from trading</li>
</ul>
<p>The fundamental concept is to (continually) seek to prove a trader is bad, rather than seek to prove (once) that a trader is good.</p>
<p>I think such a system would be less risky for the network in the long-term, because it would be built on <em>distrust</em> instead of <em>trust</em>, without reliance on a single trust chain where integrity can be tainted with a single mistake. A downside here is that it makes individual traders responsible for establishing a counterparty's integrity on their own, <em>for each trade</em>, but as you'll see below, I think the proposed methods are relatively simple, quick, private, and (when used in combination) robust.</p>
<p>Because only "negative reputation" can be earned (i.e., in this concept, signed accounts are very BAD), there would be no way for a scammer to "game the system" aside from resorting to extraordinary measures to pass verification for <em>every single trade</em> he does.</p>
<h2>Objective</h2>
<p>Prevent buyer from sending payment until seller is confident about the buyer's identity, so that if/when payment is sent, chances are high it was initiated from the rightful account owner.</p>
<h2>Disclaimer</h2>
<p>These ideas are meant more as a starting point for discussion and further ideas than a solid solution ready to implement.</p>
<p><em>Some of these ideas are rather off-the-wall.</em></p>
<h2>Concept</h2>
<p>Currently, once deposit transactions are confirmed, the buyer goes right to sending payment.</p>
<p>But what if the buyer was forced to identify himself before he could send payment?</p>
<p>Identity is virtually impossible to prove online, so this proposal offers a handful of methods a buyer could use to <em>increase confidence</em> in the seller that he's not bluffing—it's never possible to be 100% sure, but maybe we can get to 90% or 95% certainty by combining 2 or 3 or even 4 methods at a time.</p>
<p>So we offer multiple identity verification methods a buyer can use to boost a seller's confidence. The buyer pre-determines which of these verification methods he's comfortable with proving when he creates his payment account, and upon entering a trade, the seller can challenge the buyer to prove his identity using any of those methods the buyer previously selected.</p>
<p>The more methods a buyer employs & verifies for an account, the more confident a seller can be in trading with him.</p>
<p>Payment details should be hidden from the buyer until the seller indicates he is confident about the buyer's identity. I'll discuss other technical considerations below...I'm hoping they aren't too significant.</p>
<h2>Identity Verification Methods</h2>
<p>These are merely the methods I've come up with so far. I hope there are more...please share if you have other ideas, and also please voice any concerns about the viability of each one.</p>
<p>Keep in mind that no single method is good enough to stand on its own, so we seek to establish high confidence by combining a number of methods that (together) would make it highly unlikely that the buyer is a scammer.</p>
<p>Putting the burden of proof on the buyer every time he makes a trade with a new peer magnifies the value of account age—in the off chance a scammer is able to do all the tedious, hacky work necessary to successfully thwart 2 or 3 identity verification methods <em>once</em>, he would have to ensure all aspects of his false identity remain intact again and again for every trade, for weeks, months, etc...and the minute he fails just 1 check, his payment account is toast.</p>
<p>On the other hand, there's virtually no reason for an honest trader to ever fail an identity check, and most checks below are quite simple and quick.</p>
<p>As you review the suggested methods below, keep in mind that not every user will want to employ every method below, and not every method makes sense for every payment type either.</p>
<p>Each of these methods would probably require a peer-to-peer chat mechanism be built in to Bisq.</p>
<p><strong>1. Buyer sends seller small payment from second bank account</strong></p>
<p><em>Seller matches full name on payment from second bank account with full name on primary bank account</em></p>
<p>Upon closer inspection, PayPal probably won't work, as a scammer could simply sign up for PayPal using the exact same primary bank account—PayPal doesn't seem to show the receiver which payment method was used for the transaction.</p>
<p>Sending money through a service like MoneyGram could also work, because they would require ID. But it's probably a hassle to do this for most people since it would require going somewhere in-person.</p>
<ul>
<li>Verifies: full name</li>
<li>Usage: all payment methods where full name is required</li>
<li>Integrity: derived from KYC procedures of the secondary bank</li>
<li>Ease: probably high, as a transfer can be done online, quickly, with little effort</li>
<li>Downside: scammer with stolen identity can make another bank account to thwart this measure</li>
<li>Privacy: good, as no new personal details are uncovered aside from secondary bank account details</li>
</ul>
<p><strong>2. Sign string using PGP key posted on public websites</strong></p>
<p><em>Seller verifies buyer's PGP fingerprint exists on public websites (ideally more than one of the following: buyer's blog, twitter, github, keybase, etc), and challenges buyer to sign string (e.g., trade id) with corresponding private key</em></p>
<ul>
<li>Verifies: full name (assuming websites with fingerprint include user's full name)</li>
<li>Usage: all payment methods where full name is required</li>
<li>Integrity: derived from difficulty of a hacker infiltrating all a user's sites and posting a fingerprint for a public key that's older than the Bisq payment account, and/or the difficulty of establishing a whole new (convincing) web presence for a person from scratch</li>
<li>Ease: high, once Bisq buyer generates GPG keypair and posts it on his site/social profiles</li>
<li>Downside: users would need to know/learn basic GPG functions, but all commands are simple enough for a short doc/video</li>
<li>Privacy: good, as no non-public information is disclosed, and posting fingerprints is something many people do and is not a conspicuous activity</li>
</ul>
<p><strong>3. Post trade id on website with matching WHOIS data</strong></p>
<p><em>Buyer posts trade id on website with domain name where whois details match those of Bisq payment account, and whois details haven't been updated during the life of the Bisq payment account</em></p>
<ul>
<li>Verifies: full name</li>
<li>Usage: all payment methods where full name is required</li>
<li>Integrity: derived from difficulty of a hacker infiltrating a user's legitimate website, OR changing whois details for a site he owns <em>before</em> creating the payment account in Bisq</li>
<li>Ease: high, just upload a text file to server containing the trade id</li>
<li>Downside: only applies to people who own domain names without privacy, as well as hosting they control</li>
<li>Privacy: good, as no non-public information is disclosed</li>
</ul>
<p><strong>4. Snail-mail random key to street address</strong></p>
<p><em>Seller snail-mails buyer a random string to the address listed in his Bisq payment account details; if buyer can confirm receipt, street address is verified</em></p>
<ul>
<li>Verifies: street address</li>
<li>Usage: bank wires, and other payment methods where street address is required</li>
<li>Integrity: derived from practical difficulty of overcoming geographic distances and intercepting snail mail</li>
<li>Ease: medium, as one has to use snail-mail</li>
<li>Downside: snail-mail can take a day or two, and it doesn't apply to most payment methods (Bisq doesn't work with wires at the moment)</li>
<li>Privacy: good, as sender doesn't need to put return address on envelope</li>
</ul>
<p><strong>5. Verify phone number through Signal</strong></p>
<p><em>Buyer sends seller trade id via Signal, and seller matches Signal phone number with phone number in Bisq account details</em></p>
<p>While Zelle is built on phone numbers, it can be used without the mobile app, so verifying that a buyer has <em>current</em> control of the Zelle phone number can be useful (but not fool-proof).</p>
<ul>
<li>Verifies: phone number</li>
<li>Usage: only with payment methods like Zelle which require a phone number</li>
<li>Integrity: derived from difficulty of hijacking a phone number (which is relatively low, it seems)</li>
<li>Ease: easy</li>
<li>Downside: not terribly meaningful, but given the low effort for users, it might be a nice third factor for payment methods based on phone number</li>
<li>Privacy: good, as Signal doesn't retain metadata</li>
</ul>
<h2>Practical Example</h2>
<ul>
<li>buyer creates sepa payment account</li>
<li>in payment account details, there are additional fields for each identity verification mechanism: secondary bank account details, pgp key, website, etc.
<ul>
<li>buyer fills in data for verification methods he likes</li>
</ul>
</li>
<li>buyer accepts offer to buy bitcoin</li>
<li>after bitcoin deposit transactions are confirmed, payment account details only show to the seller
<ul>
<li>seller asks buyer over p2p chat to prove identity through methods listed on the buyer's payment account details
<ul>
<li>if successful, seller acknowledges he's comfortable with his payment details being shown to buyer, and deal carries on as normal</li>
<li>if failure, seller opens dispute and works with arbitrator to determine if buyer is a scammer. if scammer, account is signed.</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>Signed accounts are effectively blackballed from trading immediately (see "Quarantining signed accounts" below).</p>
<p>In case of a scammer, seller payment details are never revealed to buyer, so <strong>no money is ever sent to the seller, greatly reducing the chance honest traders end up dealing with shady/stolen property.</strong> This is huge for sellers...if banks start to think you're a shady person (which can very well happen if you receive money from just 1 shady account), you might run into major life-long disadvantages in opening new accounts, obtaining credit, etc.</p>
<h2>Technical Considerations</h2>
<p>Aside from the peer-to-peer chat tool, I'm hoping these additional measures aren't a huge pain to implement.</p>
<p><strong>Peer-to-peer chat</strong></p>
<p>It would be important for trading peers to have some way to privately communicate with each other to verify the buyer's identity. This is already on the roadmap as a part of the new trade protocol, and the methods proposed above assume this mechanism is in place.</p>
<p><strong>Quarantining signed accounts</strong></p>
<p>If it's not technically possible to outright block signed payment accounts without resorting to an emergency filter message, then we can use the UI to strongly discourage trades with signed accounts from happening:</p>
<ol>
<li>offers made with signed payment accounts should be clearly marked in the offers view so traders know not to take such offers</li>
<li>offer makers should immediately open a dispute if a trader with a signed payment account takes their offer</li>
</ol>
<p><strong>Trade protocol</strong></p>
<p>I don't think we would need another step in the trade process to make this possible, but there would need to be a way for the seller's payment details to be hidden from the buyer until the seller acknowledges their comfort with the buyer.</p>
<p>Trade periods might need an extra day or two to allow time for buyers to prove their identity.</p>
<h2>Concerns</h2>
<p><strong>Scammer could keep making new accounts</strong> after failure to verify identity. But he'd keep hitting the same wall, as he'd never be able to verify his identity, so it would be irrational to keep wasting time trying. And he'd be starting over with 0 account age every time, which is regarded with extra scrutiny anyway.</p>
<p><strong>Verification methods have limited potential</strong> since many people don't administer a web server of some kind. Even though a lot of users probably don't use PGP either, I think the requirements for its usage here are simple enough (using PGP for email is daunting sometimes even for veterans, but we're not doing that here), and over time, some functionality like verifying signatures could be built right into Bisq.</p>
<p>I think the PGP strategy combined with a secondary bank account transfer should be accessible for most users...ambitious, but it should be an effective tactic against the threats we face.</p>
<p><strong>Verification methods need to be carried out for every new trading peer.</strong> Would be great if we could figure out a clever way to cache previous successful trading peers locally (beyond onion address -- by actual payment account) so verification doesn't need to be done again for 2 people who have traded before.</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/83">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNREIF6LKIVS6IYZLELPUIAMFANCNFSM4HLNAEKQ">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJFFTNSUHY4BALVD54MH2DTPUIAMFA5CNFSM4HLNAEK2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GSQMJOQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/83",
"url": "https://github.com/bisq-network/proposals/issues/83",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>