<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><em>This proposal is designed to protect users against scammers using stolen bank accounts. To protect against scammers using stolen identities and money launderers, we are evaluating the idea of adding another step in the trading process where a buyer can assure the seller using various verification mechanisms (like those in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="441475677" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/83" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/83/hovercard" href="https://github.com/bisq-network/proposals/issues/83">#83</a>) before the sellers' payment details are ever shown to the buyer. As this change would require more considerable development work, we leave it out of this proposal.</em></p>
<p><em>We strongly believe P2P chat is a critical part of achieving protection against both types of scams, so we highly recommend implementing that as soon as possible—details below.</em></p>
<h2>Introduction</h2>
<p>This is a proposal for trade protection mechanisms from <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> and myself, and as it is the number 1 development priority outlined in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="444500792" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/91" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/91/hovercard" href="https://github.com/bisq-network/proposals/issues/91">#91</a> by <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=1449498" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/ManfredKarrer">@ManfredKarrer</a>, we would like to discuss it with the community before writing a tech spec.</p>
<p>We tried to integrate the most robust ideas from previous proposals <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="435576959" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/77" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/77/hovercard" href="https://github.com/bisq-network/proposals/issues/77">#77</a>, <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="435922491" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/78" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/78/hovercard" href="https://github.com/bisq-network/proposals/issues/78">#78</a>, and <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="441475677" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/83" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/83/hovercard" href="https://github.com/bisq-network/proposals/issues/83">#83</a>, and leave some of the more significant mechanisms for future implementation (see note above).</p>
<p>As we think it is important to move forward quickly, if you clearly don’t approve this approach please just down-vote it and write a short comment on why you don’t like it, we kindly ask not to propose alternatives within the comments for this proposal (please submit a different proposal).  If you like the core idea of this approach but you want to suggest improvements, changes or corrections, please comment.</p>
<h2>Goal</h2>
<p>The goal of this proposal is to strengthen the account age concept, as it has been already proven that it does not deter scammers as it was initially expected.  Keeping it unchanged would be irresponsible so we have to either downgrade it to a local scope parameter or strengthen it if we want to maintain its network (global) scope.</p>
<p>The strengthening is based on the very basic concept that payment accounts would begin to age only if certain conditions are fulfilled.  These additional conditions should not be interpreted as a reputation system.  <em>They are just about account age</em>, and despite the added conditions, account age will still mean just that: Account Age, and nothing more.  As such, it is not any bullet-proof protection mechanism, so due diligence of each trading peer will still always be required.</p>
<p><strong>Moreover, this protection measure is fully compatible with other local/P2P protection developments</strong>, such as not revealing seller payment account data to the buyer until the seller has somehow verified the buyer (see proposals <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="444498213" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/90" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/90/hovercard" href="https://github.com/bisq-network/proposals/issues/90">#90</a>, <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="441475677" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/83" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/83/hovercard" href="https://github.com/bisq-network/proposals/issues/83">#83</a> and <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="437058941" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/79" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/79/hovercard" href="https://github.com/bisq-network/proposals/issues/79">#79</a>), negative reputation system (see <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="330440955" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/27" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/27/hovercard" href="https://github.com/bisq-network/proposals/issues/27">#27</a>) or a LinkedIn-like relationship (see <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=4233784" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/flix1">@flix1</a>'s proposals, like <a href="https://github.com/bisq-network/proposals/issues/78#issuecomment-490123550" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/78/hovercard">here</a>).</p>
<h3>Assumptions</h3>
<ul>
<li>
<p>New users are incentivized to trigger their account age above zero, so they can enjoy higher trading limits.</p>
</li>
<li>
<p>It is unlikely that a scammer manages to control two different bank accounts from different banks from the user.</p>
</li>
<li>
<p>This proposal does not provide prevention measures from a scammer stealing or buying IDs and opening several bank accounts, following the rules and doing real fiat trades in order to gain account age and become a user that can trigger account age for other users.  However, this proposal provides a procedure to immediately abort corruption of the account age parameter once the illicit activity is detected.</p>
</li>
</ul>
<h2>UX impact overview</h2>
<p>Most trades would not be affected at all by this implementation.  For new users there is a one-off UX drawback.  With respect to the current UX experience this implementation would involve the following changes on UX/UI:</p>
<ul>
<li>
<p>A new user would need to set up 2 accounts and point to a secondary bank account within his main account configuration, if he wants his limits to go up.</p>
</li>
<li>
<p>A new user would have to understand that he needs to make a trade with an old user in order to begin to gain higher trading limits.</p>
</li>
<li>
<p>Old users need to understand that when a new user wants to trigger their account age with them, the payment is split in two and they have to verify both payments (same name, different banks).</p>
</li>
<li>
<p>Once it is triggered, the account age parameter would work the same way is working now from UX pov (we need to internally handle a subtle exception for accounts created between 1-March-2019 and the date this implementation is deployed)</p>
</li>
</ul>
<p>A procedure for banning and blacklisting users needs to be implemented.  The UX of this procedure is similar to that of current disputes with arbitrators.</p>
<h2>Implementation overview</h2>
<p>This implementation applies to all bank account payment methods and it is based on payment accounts beginning to age only if certain conditions are fulfilled.  For this purpose we need users that perform the role of “age triggering”.   For a payment account to become age triggering for other accounts is just a matter of time and not being banned (i.e. not being accused of scamming).  Users don’t have to learn or understand how their payment accounts achieve that status. It is a passive role. It is new users who are incentivized to reach them.</p>
<p>This proposal could be improved by optionally offering different conditions to trigger account age, or by additionally requiring more conditions to trigger account age.  Ideally, those additional conditions should be verifiable by third parties.  As a first step, we strongly believe that <strong>the trader P2P chat</strong> should be implemented along with this proposal so sellers can freely decide how to verify users, and that would be a really helpful feedback on what verification methods should we implement.</p>
<p>Account age would be calculated and displayed individually for each payment account, but when a payment account is banned, all “brother” fiat payment methods from the parent onion address will be also banned.</p>
<p>A bootstrapping procedure to enable a curated list of triggering users could be done, but it is not completely necessary as we could assume users older than 1-March-2019 as triggering users.  If something goes wrong, the banning procedure should kick in.</p>
<p>All the terms used in this proposal are technical terms (triggering user, triggering account age, etc) in order to be as specific as possible.  Those terms are not necessarily intended to be used for the UI.</p>
<h3>Account age calculation procedure</h3>
<p>When enforcing the trading limits or interacting with any trading peer, the Bisq client would check the following:</p>
<ul>
<li>The onion address of the peer is not banned.</li>
<li>The onion address of the peer´s triggering user is not in the blacklist</li>
<li>The user is older than 1-March-2019 or the user carries Triggering User witness data that fulfills the necessary age conditions (i.e. older than 1-March-2019 or greater than 6 months from 1-Sept-2019).</li>
</ul>
<p>If all of the above are fulfilled, the account age of the peer is calculated by verifying the witness data of the peer (witness data would also include the necessary data from the triggering user).</p>
<p>If any of the above conditions is not fulfilled the account age of the trading peer would return 0.  Note that if the onion address of the triggering user is in the blacklist, all its “sons” (“brothers” and “cousins” from the alleged scammer account) are automatically under suspicion and de facto included in the blacklist.</p>
<h3>Account age triggering procedure</h3>
<p>The following prerequisites are needed:</p>
<ul>
<li>
<p>An option should be added to payment accounts to select a secondary payment account from the other accounts configured by the user. The name and last name must be the same for the two payments methods and Banks must be different. This would be an “age triggering account”.</p>
</li>
<li>
<p>The buyer must use a “triggering account” if he wants his account age to be triggered.</p>
</li>
</ul>
<p>Unlike it is implemented now, account age of risky fiat payment methods would remain at 0 until the user conducts a trade as a BTC buyer with fiat that fulfills the following:</p>
<ol>
<li>The buyer is not banned.</li>
<li>Seller’s account is not banned (it wouldn’t even be shown as old for the buyer).</li>
<li>Seller’s account has not reached its maximum of triggered payment accounts.</li>
<li>Triggering User of the seller account is not in the blacklist</li>
<li>Seller’s account age is older than 1-March-2019.  From 1-Sept-2019 we would require the seller to be older than 1-March-2019 OR more than 6 months old and having successfully overcome this procedure.</li>
<li>The seller is instructed that the payment is coming from 2 different accounts and that he should not confirm  until he receives the 2 payments.</li>
<li>The verification of names and  different banks would be <strong>manually performed</strong> by the seller.</li>
<li>The seller finally confirms the payments.</li>
</ol>
<p>If all the above are fulfilled, the account age witness of the buyer would be generated using both the private key of the buyer and the seller and including the account age witness of the seller (from now on Triggering User).</p>
<p>If the buyer was in the blacklist as a suspicious “cousin” and he successfully overcomes the above procedure, he will be removed from the blacklist.  However, for these cases the seller could require more details from the buyer, the P2P chat for traders would be very helpful here.</p>
<p>To avoid strong disruption on the network (i.e. too many “cousins” being suspicious), each triggering payment account can trigger account age for a maximum of 3 new payment accounts.  A maximum of 1 per week (if it is possible to implement)</p>
<p>We suggest a longer time limit of 21 days for this type of initial trades, so the seller can gain a bit more comfort that if chargeback occurs at least he is not going to lose his BTC and the victim will recover his money.  This could be lowered in the future if additional verification methods are added.</p>
<h3>Blacklisting and Banning Procedures</h3>
<p>As stated in the Introduction section, the account age parameter is not bullet-proof so we cannot implement this proposal without a blacklisting procedure. This procedure is a <strong>must</strong>.</p>
<p>Arbitrators would manage a ban list for permanent bans and a blacklist for suspicious triggering users. In the future blacklisting could be done without arbitrators as well.</p>
<p>For now, the procedure would be as follows:</p>
<ul>
<li>
<p>The seller selects the conflictive trade and clicks the dispute button to initiate the procedure. Now the dispute option has to be also enabled for settled trades.</p>
</li>
<li>
<p>The user explains to the arbitrator, and if the arbitrator thinks the complaint is legit, he asks the buyer to send back the BTC if he has received the money back.</p>
</li>
<li>
<p>If the buyer does not respond, or if his answers are suspicious, then the arbitrator includes the onion address of the buyer in the <strong>ban list</strong> so he cannot trade anymore.  The onion address of triggering user of the buyer is included in the blacklist so he cannot trigger account age for any new user.   If the triggering user was already in the blacklist, then he would be totally banned from all activity.</p>
</li>
<li>
<p>By including the triggering user, all “cousin” payment accounts are de facto temporarily blacklisted so they need to overcome a new age triggering process to get removed from the blacklist.</p>
</li>
</ul>
<p>As a general rule, the banning / blacklisting procedure has to be categorical. The arbitrator shall not hesitate to ban the buyer if the seller provides enough proof of the chargeback.  Only if the arbitrator suspects that the seller tries to unfairly slander the buyer he should refrain from banning.  Internal guidelines for the arbitrators will be prepared.</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/93?email_source=notifications&email_token=AJFFTNUUPQH4QSSXETNFT5LPWQPJZA5CNFSM4HOMXIY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GVAKDCA">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNVCYVPC4N35BG46W23PWQPJZANCNFSM4HOMXIYQ">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJFFTNT24UXAE46XX45WKPDPWQPJZA5CNFSM4HOMXIY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GVAKDCA.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/93?email_source=notifications\u0026email_token=AJFFTNUUPQH4QSSXETNFT5LPWQPJZA5CNFSM4HOMXIY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GVAKDCA",
"url": "https://github.com/bisq-network/proposals/issues/93?email_source=notifications\u0026email_token=AJFFTNUUPQH4QSSXETNFT5LPWQPJZA5CNFSM4HOMXIY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GVAKDCA",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>