Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of protection tools: strengthening Account Age by requiring payments from 2 Bank Accounts #93

Open
m52go opened this issue May 21, 2019 · 40 comments

Comments

Projects
None yet
10 participants
@m52go
Copy link
Member

commented May 21, 2019

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

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 #83) 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.

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.

Introduction

This is a proposal for trade protection mechanisms from @mpolavieja and myself, and as it is the number 1 development priority outlined in #91 by @ManfredKarrer, we would like to discuss it with the community before writing a tech spec.

We tried to integrate the most robust ideas from previous proposals #77, #78, and #83, and leave some of the more significant mechanisms for future implementation (see note above).

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.

Goal

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.

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. They are just about account age, 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.

Moreover, this protection measure is fully compatible with other local/P2P protection developments, such as not revealing seller payment account data to the buyer until the seller has somehow verified the buyer (see proposals #90, #83 and #79), negative reputation system (see #27) or a LinkedIn-like relationship (see @flix1's proposals, like here).

Assumptions

  • New users are incentivized to trigger their account age above zero, so they can enjoy higher trading limits.

  • It is unlikely that a scammer manages to control two different bank accounts from different banks from the user.

  • 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.

UX impact overview

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:

  • 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.

  • 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.

  • 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).

  • 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)

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.

Implementation overview

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.

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 the trader P2P chat 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.

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.

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.

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.

Account age calculation procedure

When enforcing the trading limits or interacting with any trading peer, the Bisq client would check the following:

  • The onion address of the peer is not banned.
  • The onion address of the peer´s triggering user is not in the blacklist
  • 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).

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).

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.

Account age triggering procedure

The following prerequisites are needed:

  • 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”.

  • The buyer must use a “triggering account” if he wants his account age to be triggered.

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:

  1. The buyer is not banned.
  2. Seller’s account is not banned (it wouldn’t even be shown as old for the buyer).
  3. Seller’s account has not reached its maximum of triggered payment accounts.
  4. Triggering User of the seller account is not in the blacklist
  5. 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.
  6. 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.
  7. The verification of names and different banks would be manually performed by the seller.
  8. The seller finally confirms the payments.

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).

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.

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)

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.

Blacklisting and Banning Procedures

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 must.

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.

For now, the procedure would be as follows:

  • 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.

  • 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.

  • If the buyer does not respond, or if his answers are suspicious, then the arbitrator includes the onion address of the buyer in the ban list 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.

  • 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.

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.

@m52go

This comment has been minimized.

Copy link
Member Author

commented May 21, 2019

Given the number of proposals now out for protection mechanisms, should we have a call to discuss where we stand, and what this particular one is all about? I can see it being confusing for people to provide feedback just as it is.

How about next Tuesday, 28 May? Time TBD but would have to be at or before 5pm CET.

Feel free to read through this proposal, ask questions, etc. and we can talk through everything then to determine a way forward.

@mpolavieja

This comment has been minimized.

Copy link

commented May 21, 2019

Next tuesday at 5 PM is ok with me.

  • 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.

This assumption is subject to the idea of adding a pre-trade step where the buyer and the seller can communicate through the p2p chat, which would help fighting stolen/bought IDs and money launderers

@sqrrm

This comment has been minimized.

Copy link
Member

commented May 21, 2019

Over all I approve. I think focusing on getting this done makes sense and perhaps continue other discussions on other features in parallel.

I find the 'Account age calculation procedure' section rather difficult to understand, if it's possible to simplify it that would be a good thing.

The whole banning concept relies on someone having the ability to trigger bans. It would be nice to be able to not have such a single point of authority, but it's hard to see how decentralizing this decision would work considering the urgent time frame of stopping an account from continues scamming. The bans would mainly be on account(agewitsesses) rather than onion addresses I assume since it's possible to move accounts between onion addresses.

A graph to explain who is considered suspicious or not might help to clarify the intricate relationships between scamming brothers, parents and cousins. Such a mischievous family.

@mpolavieja

This comment has been minimized.

Copy link

commented May 21, 2019

'Account age calculation procedure' section rather difficult to understand

That´s because it is written having edge cases in mind and thinking from the point of view of the Bisq client that has to verify everything by itself. This procedure basically means that payment accounts only begin to age from the date when an old enough user has confirmed a trade with 2 payments from different banks.

The whole banning concept relies on someone having the ability to trigger bans.It would be nice to be able to not have such a single point of authority

Fully agree. Steve and I initially thought of proposing a decentralized system. We have worked through it quite in depth and we think it is certainly possible but it would be much longer to implement and since it would be based on bonding BSQ we thought to better leave it out and wait until the trading protocol also upgrades.

The mischievous family :

image

  • When a chargeback occurs in a payment account, all payment accounts of that user (“brother” accounts) are permanently banned

  • The payment accounts triggered by the same Triggering User (“cousin” accounts) are temporarily blacklisted and need to verify again

@flix1

This comment has been minimized.

Copy link
Member

commented May 22, 2019

Agree with having a call to discuss all proposals. Next tuesday at 5 PM is ok.

My main concerns with this as with similar proposals are:

1. Don't break what does work to fix what doesn't.
If 99.9% of trades so far have been honest... don't make all of them more difficult or block new users to prevent 0.1% of scams.

2. Keep it voluntary.
Don't assume that changes will work as intended. Consider the possibility of being wrong. Add it as an optional feature that people will voluntarily use if it adds value and ignore it if it does not work.

3. Don't ignore impact on UX and onboarding.
Scalability matters. Bisq as it is right now is no more than a beta. We need to plan for Bisq with 1000x more users. If onboarding takes weeks it will never scale.

4. KEEP IT SIMPLE!
If it takes more than 5 minutes to explain to users how it works and what it does... it will go to that special place in hell reserved for overengineered features.

Many of these mechanisms could even be built on top of Bisq instead of in Bisq.
For example for #90 you can go to a lot of trouble to integrate direct chat... or just include a field for an e-mail address in the contract...

@mpolavieja

This comment has been minimized.

Copy link

commented May 22, 2019

  1. Keep it voluntary.

A way to keep it voluntary would be to keep internally the current account age for trading limits (or maybe allowing to gain just one step after one month). But the account age shown to other users would work as suggested in this proposal. So it would be up to the other users the decision to trade or not with 0 account age users. Again direct communication between traders would be very interesting here as an old user could be comfortable to trade with a 0 account user if both privately agree for whatever reasons (for example local whitelisting methods when implemented).

If 99.9% of trades so far have been honest....

My view on that is that there is a high chance that scammers are not coming to Bisq because of low liquidity. And unfortunately the harm of just a few dishonest trades, even if just every once in a while, could be very big.

The good thing of your suggestion of implementing the measures proposed here as optional, is that if we keep for long enough, we might have a reasonable feedback of what works and what doesn't work.

@mpolavieja

This comment has been minimized.

Copy link

commented May 22, 2019

Regarding the banning procedure, I strongly believe it should be implemented in any case. Now with arbitrators and in the future decentralized once arbitrators are gone. @flix1, what´s your opinion on this?

@flix1

This comment has been minimized.

Copy link
Member

commented May 22, 2019

Regarding the banning procedure, I think it should be implemented in any case. Now with arbitrators and in the future decentralized once arbitrators are gone.

I prefer decentralized solutions such as p2p blacklists to banning. However banning is simpler and as long as we have arbitrators it makes more sense. So I agree with banning for now.

However when arbitrators are gone it will be too dangerous to have a centralized authority (DAO role?) with the power to ban users. It would be an obvious single point of attack for any regulator that wants to impose censorship.

It would also be dangerous to allow users to report/ban as this mechanism creates perverse incentives in a competitive market. A user who wants to corner a market could easily game this feature.

So long term we need to come up with something better.

Researching cell systems is probably a good start:
https://en.m.wikipedia.org/wiki/Clandestine_cell_system
https://en.m.wikipedia.org/wiki/Cellular_organizational_structure

@mpolavieja

This comment has been minimized.

Copy link

commented May 22, 2019

A user who wants to corner a market could easily game this feature

The basic idea is that the BTC buyer could defend by challenging the seller through a predefined trade with highest possible security deposits (or with BSQ bonding), and involving a randomly selected triggering user. The accusation would put the Buyer on a temporary blacklist which would downgrade its account age to 0. If the buyer is able to make the 2 payments again, he would be removed from the blacklist (the Seller would lose the bond if applicable). If the buyer fails to overcome the challenge, he would lose the security deposit / bond and would be permanentely banned. The seller could have his account age rejected to 0 or even be banned if his accusations are succesfully challenged more than 1 or 2 times. The DAO wouldn't be involved.

This is the very basic concept. The full idea deals with quite a few nuances and edge cases.

But since this proposal is already difficult, I suggest to discuss this after a decission on this proposal is made, or in a separate thread if you agree.

@m52go

This comment has been minimized.

Copy link
Member Author

commented May 22, 2019

We forgot to include that the arbitrator would always ask the accused to return the BTC if he has received the money back.

@mpolavieja are you referring to this? I think it might already be in the proposal in the "Blacklisting and Banning Procedures" section:

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.

@cadayton

This comment has been minimized.

Copy link

commented May 23, 2019

My bank is very curious about my transactions using Zelle. On just about every trade I'm get called asking what the transaction was for. I have a dedicated bank that I only use for Bisq. With the new account age process, it looks like I'll need to go shopping for another bank and payment type. My fear is the bank(s) will get wise to what I'm doing and suspend the account. If I have to establish a new bank account then, I'm back to square one with the accounting aging process. I bet you can read my mind if this ever happens.

The bonding process sounds good to me. I'd more willing to put my BTC/BSQ at risk if I don't honestly complete the trade contract. The bonding process would be less headache for the end user than that which is being proposed.

I'm finding it difficult to trust Bisq to be there when I need it to conduct trading. There always some weird issue that comes up that is blocking for one reason another at the perfectly wrong time. It is not always a Bisq issue that is getting in the way. I'm just saying this so know my experience and that you don't forget to put on your customer shoes and look at the solution from a customer who wants to use Bisq for active trading (not Hodling). Bisq is still the best P2P solution, it just needs to attractive more active traders.

@HarryMacfinned

This comment has been minimized.

Copy link

commented May 23, 2019

The fiat banking system is treating its users like childs and burglars, with tons of regulation/protection/limits/delays etc. With bankers experts knowing better than users what is good for them and what is not good for them.
Some people which are annoyed being treated this way try to escape and go in the crypto world. Because crypto world should be free etc.
And there, guess what, we are frenetically rebuilding a carbon-copy micro-banking system will all kind of protections/limits/delays etc, where users will also be exactly treated as childs and burglars. And where we, experts, have plenty of ideas about what is good/not good for them.
Because of 1 or 2 scammers, every user will be asked 2 proof of accounts.
Because of 1 or 2 scammers, every user will be treated as a child and will have super small trading limits (which increase dramatically the fee ratio (which not even profits to Bisq), which increase the number of moves and alerts the banks, etc).
This Lépine contest of measures is in fact a usability killer contest.
There is no measure without side effects, that simply does not exist. Sometimes cascading.
Our fiat/crypto users will die cured.

I monitor the EUR/BTC, USD/BTC numbers daily. Everybody participating to this discussion should do that. The decrease is really worrisome. We are really hurting hard our poor customers and of course some go away.
Instead of knocking out our customers under a pile of measures we should stop forgetting the initial way people search with crypto : freedom + responsability.
Offering them the exact reverse is completely missing our core target. Crypto customer profile is a guy searching for a place to trade conveniently, freely, with privacy, at very first. He is not searching for a mother to take him by the hand or bury him under her petticoats. Customers searching for that have it already with the existing banking system.
We'll alas probably pay it and see it in the numbers.
Bisq profitability with fiat/crypto trading is an horizon that we ourselves methodically push further every day.

@mpolavieja

This comment has been minimized.

Copy link

commented May 23, 2019

You could say the exact same thing about any software or service that enforces 2FA / multisig. We must not confuse basic security standards with KYC. This proposal is about 2FA, and if possible it will be implemented as optional, so we will see if users use it or not.

@flix1

This comment has been minimized.

Copy link
Member

commented May 23, 2019

This Lépine contest of measures is in fact a usability killer contest.

I monitor the EUR/BTC, USD/BTC numbers daily. Everybody participating to this discussion should do that. The decrease is really worrisome.

Instead of knocking out our customers under a pile of measures we should stop forgetting the initial way people search with crypto : freedom + responsability.

@HarryMacfinned I agree with a lot of what you are saying. We should not be making decisions for users like a company or bank. That's the whole point of being decentralized.

Our role should be to build tools that allow users to protect themselves. Not to be in charge of protecting them.

@mpolavieja

This comment has been minimized.

Copy link

commented May 23, 2019

With the new account age process, it looks like I'll need to go shopping for another bank and payment type

@cadayton It could be an overkill to set up a new account just for making the first secondary initial payment. It shouldn't be a problem to use any other bank account you already have to make that one single payment. Unless you want to use that secondary account as a Bisq back-up in case your bank closes your main account for whatever reason. The secondary account would age the same than the main account so you could keep trading with the same limits with the secondary account.

Furthermore, at the beginning of the proposal it is suggested to introduce a pre-trade step where users could freely and privately agree on how they want to conduct the trade (not necessarily requiring a second bank account). However, the technical feasibility of adding pre-trade step needs to be assessed carefully as it could be rather complex.

@mpolavieja

This comment has been minimized.

Copy link

commented May 23, 2019

And as a more general comment, regarding the UX of having a network level account age parameter, I think that if we don´t have that (or what we have is not reliable enough) we all agree that a decentralized local whitelisting should be implemented. Comparing those two alternatives it is not clear at all that the decentralizaed UX is better as you would have to repeat whatever process you deem necessary with every single new trader and it could lead to fragmented and siloed liquidity.

The account age procedure suggested here is just a one-off hassle, so it is probably more balanced towards UX than to security than the fully decentralized approach.

Our role should be to build tools that allow users to protect themselves. Not to be in charge of protecting them.

Ok @flix1, but we should be careful not to annoy users with too many options. Users come to Bisq to trade not to figure out security. As an example think about the simplicity of hardware wallets vs. the complexity of glacier. Because as for now Bisq is not only a protocol but also a front/end UI, we need to find a balance between "HW approach" and "Glacier approach" (i.e. a balance between UX and security).

@sqrrm

This comment has been minimized.

Copy link
Member

commented May 23, 2019

I like having this as an option among other protection tools. For a normal user that wants to just buy some BTC and don't care about continuous trading this could be an easy way in with limited risk of having their bank accounts closed or otherwise bothered by their masters.

For those that don't have multiple bank accounts or have other limitations we should think of other methods as well. Using BSQ bonds is a really neat thought but I think it's still too early for that.

In case I'm wrong and we decide to add BSQ bonding as a way to perform the initial trade there are quite some work to be done. We have already thought a bit about using bonding as a trade protocol, it's rather complicated and I'm convinced it's too early for that now. For just one trade it would be more feasible, but the bond would still have to be locked up for at least 1.5 DAO cycles (1.5 months) to allow time for it to be confiscated. Perhaps this could be a way to towards the bonded trade protocol.

@mpolavieja

This comment has been minimized.

Copy link

commented May 23, 2019

I think that BSQ bonding is a great idea but as you say BSQ and the DAO are not mature enough and bonding BSQ is also a barrier of entry for onboarding UX, which is one the main drawbacks also raised for this proposal. Moreover, involving the DAO on confiscating as a standard procedure sounds to me as an extremely difficult decision to make.

So if we want to move forward and unlock the current situation with the trading limits, I suggest to focus the discussion on approving, modifying or rejecting this proposal.

In that respect, should we first make a final decission on finally approving the priorities proposed at #91?

@m52go

This comment has been minimized.

Copy link
Member Author

commented May 23, 2019

And as a more general comment, regarding the UX of having a network level account age parameter, I think that if we don´t have that (or what we have is not reliable enough) we all agree that a decentralized local whitelisting should be implemented. Comparing those two alternatives it is not clear at all that the decentralizaed UX is better as you would have to repeat whatever process you deem necessary with every single new trader and it could lead to fragmented and siloed liquidity.

This, in my mind, is the critical decision we will need to collectively make: peer-to-peer with repetition or network-wide with convenience.

[I scheduled a call to discuss this stuff for Tuesday at 17 CET: https://github.com/bisq-network/growth/issues/132]

At this point, I think we've got adequate ideas that indicate how each one would practically turn out for users.

To address cadayton's points: if we stick with the network-wide approach proposed here, perhaps we broaden the measures required to start account aging to some of those included in #83 (particularly method 2, which I just updated to not require PGP anymore) so users aren't required to open/use a second bank account.

@m52go

This comment has been minimized.

Copy link
Member Author

commented May 23, 2019

Another piece in this puzzle I think we should consider is payment methods themselves. Remember that cash-based payment methods will not require any of this mess.

Maybe we should consider adding new payment methods:

  1. bank wires (no chargeback risk, can be done online, compatible with verification methods including street address which can be very strong)
  2. online gift cards (cursory research indicates these can be purchased online and delivered by email...buyer could prove purchase with TLSNotary; doesn't seem like chargebacks would be an issue)
  3. cashier's checks (buyer doesn't lose money if check doesn't reach seller, unlike money order; downside is you have to send these in-person)

(2) is particularly interesting as it seems almost as good as cash, provable, and relatively quick/convenient...it may be able to get by without any onerous requirements.

Note that I haven't thoroughly researched any of the items above...I guess my point here is that the proposed measures (in some form) may be necessary for the payment methods they're intended for. Perhaps new payment methods can get by without needing them.

@mpolavieja

This comment has been minimized.

Copy link

commented May 23, 2019

Overall, we need to find a balance between on-boarding UX and protecting already on-board traders, specially active traders. Active traders are both the strength and the Achilles heel of Bisq. Active users are the ones that have a huge chance of getting hit by scammers.

If we get a scammer every once in a while, it will most likely hit active traders who always post offers, so only a few scamming events would lead to lose a lot of liquidity if active trader's accounts are slowly but relentlessly getting closed. Moreover, as active traders are very easy to spot by banks, even if the account of the active trader is not closed, all the accounts that have traded with him from the same sender bank of the scammer are at high risk of being closed (this has already happened with some banks).

Users that initially join with the clear idea of active trading might be careful since the beginning. But users that become active without planning might be risky if Bisq does not easily take them through a secure path, specially considering that most Bisq users are honest which might very easily lead to relax security as most trades are settled without any problem at all.

@mpolavieja

This comment has been minimized.

Copy link

commented May 24, 2019

Regarding optionality and the pre-trade stage this is another possibility:

  • Bisq could enforce the highest possible security deposit for the buyer on buy offers posted by zero age payment accounts.
  • When trading with zero age accounts, the Seller Triggering Account would be exempt from trading fees (shouldn´t we incentivize a little bit the process of triggering?)

Then, the Seller Triggering Account could require zero age account buyers one of the following:

  1. Nothing, the account age of the buyer would be triggered by confirming a normal payment. But for allowing this, we should enforce some delay for the BTC release for trades with zero age buyers (see below) and limit the number of trades that new accounts can do during the first month.
  2. To choose a 2FA verification method before the trade. Buyer would have to select an option from a closed list. In order to select the 2 bank payment option buyer must have the appropriate account configuration. The chosen verification method of the buyer would be part of the trading contract. If the buyer pays but does not verify as agreed, the seller should return the money and open a dispute.
  3. Not accepting to trade at all with buyers whose age account is below X days (X could range between 0 and 180 days, setting it to 1 would only exclude 0 age accounts).

Option 3 is important for very active traders or market makers. Bisq's liquidity network needs those type of users to be very careful from whom they receive bank payments.

For Option 1 it would be best to enable a delay for releasing the BTC such as the following proposed by @ManfredKarrer in #77:

Maybe there is still a way to add the payout delay without big effort:
To use the timelock function on the tx level again (as it was in earlier trade protocol) but to make it more simple so that it does not require an extra handshake cycle. It still would be a kind of hard fork but maybe we find some way to mitigate that to cause less harm.
Idea is to just add the timelock in case the buyer is considered risky. Based on the risk level the timelck can be defined from 0 blocks to 4300 blocks (about 1 month). It can be determined at take offer time and without haveing thought in depth about it I do not see a big problem in implementing that. Usability would be the same, just require an info that the btc are released but not usable until the timelock is over. Hope it would not turn out as well in too much UX confusion when looking deeper....

@angkorfilms

This comment has been minimized.

Copy link

commented May 28, 2019

Agree with most of the comments...

  1. Keep it simple and clean (minimalist)... unless you want Bisq to be a programmer-only platform.
  2. Keep it decentralized. What's the point of having this great technology by Satoshi yet going against it with a centralized authority to ban/blacklist users? Let users themselves be the ones protecting themselves, just give them the tools to do it. I don't think LocalBitcoins is perfect, but it's pretty simple and user-friendly... not to mention intuitive. I'd suggest taking a lot of its features (specially when it comes to trust) as references.
  3. 2FA... totally.
  4. The biggest issue for "Onboarding" even if you have the greatest marketing of all times is, so far, Trust. There is no clear way to trust users. mpolavieja said "99,9% of Bisq users are honest and all trades settled rather quickly"... oh well, easier said than trusted. If I'm not wrong, the user base is still tiny. Again, not as a programmer, just as the regular user I am, I find it very difficult to start a transaction on Bisq, because I have no idea whether the trader I end up choosing will run away with my money after it's sent. Showing the user's age, transaction history (anonymously), comments and ratings by other users would definitely make a difference. You do business with someone for three reasons: a) you know the person b) you know someone who knows the person (referral) or c) you just want to take the risk (e.g. going into a new restaurant you've never been to or heard of before).
@reipichu

This comment has been minimized.

Copy link

commented May 28, 2019

3. cashier's checks (buyer doesn't lose money if check doesn't reach seller, unlike money order; downside is you have to send these in-person)

In my country, cashier's checks are treated exactly like paper money. If you lose them then you lose the money. The withdrawal from the account is made immediately upon requesting the check from the teller. Just FYI.

@mpolavieja

This comment has been minimized.

Copy link

commented May 28, 2019

@angkorfilms Thank you very much for your feedback. I´ll try to address it as best as I can.

2. Keep it decentralized.

Fully agree. A decentralized blacklisting method is also on the roadmap. But since this proposal is complex enough on itself and developers are a very scarce resource, we prefer to go step by step and first rely on the arbitrators for blacklisting. When the protection tools are implemented, we will go for a decentralized blacklisting procedure, which we are rather optimistic it is possible to implement.

easier said than trusted

Fully agree. Indeed, the goal of this proposal is to make the Bisq more trustworthy on itself

4. I have no idea whether the trader I end up choosing will run away with my money after it's sent.

If you are a BTC seller the only way your peer can run away with your money is through a chargeback, and that´s exactly what we are trying to minimize with this proposal (2FA, enabling chat, etc)

If you are a buyer, the BTC of the seller is locked in a multisig, so it is very difficult that the seller can runaway with your fiat without releasing the BTC unless he colludes with the arbitrator. It will be virtually impossible when the new trading protocol without arbitrators is implemented.

@mpolavieja

This comment has been minimized.

Copy link

commented Jun 6, 2019

This proposal has been partially approved. The proposed account age calculation and triggering procedure are being implemented for normal payments (the 2FA process might be implemented in a next release) and the filtering procedure will remain current so the proposed blacklisting procedure is stalled.

@mpolavieja

This comment has been minimized.

Copy link

commented Jun 7, 2019

@ripcurlx, Is a longer trade period going to be implemented for trades involving unsigned buyers and signers? If so, the signer could have more leeway to wait at least 3 or 4 working days after he receives the fiat payment to make sure there is no chargeback. Another approach would be to just advise the signer to open a dispute if they feel they did not have enough time to confirm there is no chargeback (In this regard, maybe we have to consider the possibility of opening a dispute for a settled transaction to quickly inform the arbitrator if there is a chargeback).

Maybe an internal soft-limit could be implemented, so the new account would only get signed if there are more than X days between the "payment started" and "payment received" events. If this information could also be hashed into the witness data, it could maybe be used in a future implementation as a negative/positive reputation metric of reckless/trustworthy signers?

Knowing that info about how much signers wait on average would be a very interesting feedback.

@mpolavieja

This comment has been minimized.

Copy link

commented Jun 7, 2019

Another thing to consider regarding UI is the possibility of opening a dispute for a settled transaction to quickly inform the arbitrator if there is a chargeback.

@ripcurlx

This comment has been minimized.

Copy link
Member

commented Jun 7, 2019

@ripcurlx, Is a longer trade period going to be implemented for trades involving unsigned buyers and signers? If so, the signer could have more leeway to wait at least 3 or 4 working days after he receives the fiat payment to make sure there is no chargeback. Another approach would be to just advise the signer to open a dispute if they feel they did not have enough time to confirm there is no chargeback (In this regard, maybe we have to consider the possibility of opening a dispute for a settled transaction to quickly inform the arbitrator if there is a chargeback).

Atm it wasn't on my list yet. It can't be easily done by just extending the trade period by a certain factor, if a unsigned buyer account is involved, as it could then just be misused by the buyer to delay the payment as long as possible. If we display and implement this delay only on the seller side, the buyer might open a dispute in the meantime after the trade period is over. I think the easiest thing we could do is to show additional information to the seller if an unsigned buyer is involved to delay the release of the BTC as long as possible. The proper implementation would be to not show the dispute button to the buyer after the trade period is over and display another delay bar and additional information. Not sure if it is worth to implement this properly as we still have the amount limit (0.02 BTC) for unsigned accounts anyways. @mpolavieja What do you think?

Maybe an internal soft-limit could be implemented, so the new account would only get signed if there are more than X days between the "payment started" and "payment received" events. If this information could also be hashed into the witness data, it could maybe be used in a future implementation as a negative/positive reputation metric of reckless/trustworthy signers?

We could do that, but it is an additional challenge for the UI as it might cause some confusion on the buyer side if a signed account doesn't sign their account within the trade.

Another thing to consider regarding UI is the possibility of opening a dispute for a settled transaction to quickly inform the arbitrator if there is a chargeback.

Good point - could you open a separate GitHub issue for that? Just want to implement the first account signing as lean as possible and than add as many separate functionalities afterwards if there is time left.

@ripcurlx

This comment has been minimized.

Copy link
Member

commented Jun 7, 2019

I also have a couple of points I want to discuss after looking through the existing signing code.

  • Do we see in the UI an account only as signed if it is signed and mature (e.g. 30 days after successful trade)? Or do we want to provide sophisticated filtering for offer makers and within the offer book to display signed and mature, signed and immature, unsigned
  • If we add the 2FA payment (split payment) as an optional verification, do we want to set the account mature immediately or also only after a certain time delay?
  • Shall we display if an account was signed by 2FA or matured by a single payment plus delay and also provide the option to filter during offer making and taking.

If we add more and more granular filtering options it would split up liquidity more and more and it will get more complicated for new users. What do you think?

@mpolavieja

This comment has been minimized.

Copy link

commented Jun 7, 2019

Not sure if it is worth to implement this properly as we still have the amount limit (0.02 BTC) for unsigned accounts anyways. @mpolavieja What do you think?

While 2FA is not implemented or if implemented as optional and single payments are still valid for account aging, what worries me a lot more than the quantity is that if a scam happens, it is very likely that active traders and market makers are the ones going to get hit. The risk is that the bank closes the market maker account, so Bisq loses a big chunk of liquidity.

So the best we can do to minimize that risk is to put measures in place that deter as much as possible the scammers to try it. That is, that they clearly feel that it will be extremely difficult that the signer is going to sign carelessly (2FA, if not 2FA the signer will wait, etc).

We could do that, but it is an additional challenge for the UI as it might cause some confusion on the buyer side if a signed account doesn't sign their account within the trade.

Yeah. If this soft-limit is enforced the buyer should be informed that his account is still unsigned because not enough time did elapse from payment sending to confirmation and be advised to send the payment as quickly as possible on the next trade if he wants to get signed. But yeah, it is bad UX, we should discuss if it is worth it.

IMO, the most important risk to control is that a scammer does not become a signer. So we need to rely on signers reacting quickly and opening a dispute if they have a chargeback with a new account. I´ll open another GitHub issue for disputes on settled trades (You mean a proposal, right?).

@mpolavieja

This comment has been minimized.

Copy link

commented Jun 7, 2019

If we add more and more granular filtering options it would split up liquidity more and more and it will get more complicated for new users. What do you think?

Market makers are very sensitive users (or at least they should be). With more filtering options it is true that it could be split liquidity so it is hard and frustrating for new users to join the liquidity of mature users. But are we going to get a lot of market makers without the necessary tools to protect themselves? It is not easy at all for me to answer this question.

Regarding the other questions, could it be a simpler approach that the UI shows 0 age account for unsigned accounts and the age in number of days for signed accounts? And maybe only an additional info to make clear an account has signing capability (regardless of how it reached maturity).

Regarding filtering options, I suggest to wait and see before implementing any filtering, in the meantime rough filtering can be done through trading amounts (i.e. if I post an offer above 0,02 BTC I know that an unsigned account won´t be able to take my offer).

@m52go m52go referenced this issue Jun 7, 2019

Closed

For Cycle 2 #294

@m52go

This comment has been minimized.

Copy link
Member Author

commented Jun 10, 2019

Do we see in the UI an account only as signed if it is signed and mature (e.g. 30 days after successful trade)? Or do we want to provide sophisticated filtering for offer makers and within the offer book to display signed and mature, signed and immature, unsigned

EDIT: I agree with Manuel's approach to show 0 age until signed, and then a show a small symbol/indicator when signing status is obtained.

If we add the 2FA payment (split payment) as an optional verification, do we want to set the account mature immediately or also only after a certain time delay?

I agree that it's important that we make it as hard as possible for scammers to succeed, so I'm in favor of requiring a time delay for 2FA methods too. EDIT: I think there should be a delay to become a "mature" account no matter the type of verification used.

Shall we display if an account was signed by 2FA or matured by a single payment plus delay and also provide the option to filter during offer making and taking.

I'm not sure filtering is required at this point, but showing the means by which a person was verified would be important, I think, especially if we end up implementing multiple verification methods in the future. Both so that a trader can (1) "filter" unverified accounts on their own with less upfront development work (and reduce fragmentation in the UI), and (2) so traders can know (in the future) how a particular trader has verified themselves (perhaps they prefer a certain method, or perhaps they prefer 3 or 4 verification methods instead of just 2).

@mpolavieja

This comment has been minimized.

Copy link

commented Jun 10, 2019

Signed but immature accounts don't have any additional powers (is that right?)

I understand once an account is signed, which could be shown in the UI as age=1, its trading limits would automatically jump from 0,02 BTC to 0,0625BTC. And once it is 30 days old it would jump to 0,125BTC.

Regarding "mature" accounts, I think @ripcurlx was using that term for those accounts that have the capability to sign other accounts. IMO I wouldn't set it mature until age reaches at least 60 days.

@m52go

This comment has been minimized.

Copy link
Member Author

commented Jun 10, 2019

Got it. Edited my comment above accordingly.

@mpolavieja

This comment has been minimized.

Copy link

commented Jun 10, 2019

Regarding the delay for 2FA methods, since it is going to be implemented in a next release I suggest to wait and see how the new account age process works to decide on that.

@ripcurlx Could you please confirm if you want me to open a new github proposal for implementing the dispute button for settled trades?

@ripcurlx

This comment has been minimized.

Copy link
Member

commented Jun 11, 2019

@ripcurlx Could you please confirm if you want me to open a new github proposal for implementing the dispute button for settled trades?

Yes, please do so - this is something that could also be done by someone else.

@spogulis

This comment has been minimized.

Copy link

commented Jun 12, 2019

As Bitcoin is a means to reduce dependability on 3rd parties (banks) and Bisq as well (centralized exchanges), I disagree that having two bank accounts is the way to go.

@mpolavieja

This comment has been minimized.

Copy link

commented Jun 12, 2019

@spogulis, 2FA with two bank accounts will be just one verification method, and it is probably going to be optional. There are other different 2FA verifications methods planned. All ideas are welcome, so if you can come up with other ideas that would be really appreciated.

Please note that Bisq's main purpose is being fiat on ramps and this proposal is for bank fiat payments, so within the context of this proposal it is unavoidable to depend on banks. For those who don´t want to rely on banks, I'd recommend f2f transactions.

@ripcurlx

This comment has been minimized.

Copy link
Member

commented Jun 20, 2019

So to sum up the spec for the first iteration of this feature:

  • Unless an account gets signed by a verified account signer the TOLERATED_SMALL_TRADE_AMOUNT (atm 0.01 BTC) limit will stay in place
  • Buyer as maker is able to only allow verified account signers to take its offer
  • Payment account age will be 0 until an account gets signed. After that it will increase with every day
  • As soon as the account age reaches 30 days (30 days until account age starts to account + additional 30 days to be able to sign) we'll present the user with a popup showing that he is now a verified account signer. This information will be shown (e.g. icon) on each offer the user places.
  • In the peer info popup we'll display how the user became a verified account signer (e.g. single payment with maturity over time)
  • For unsigned account buyers we'll present the seller with an additional warning during the trade process, that he should delay the release of BTC as long as possible (within the allowed trade limit)
  • Arbitrators will have a new functionality to initially sign accounts within a payment method (open by key shortcut). In the popup arbitrators can select payment method and point of time (e.g. for SEPA 1st of March 2019) from which backwards all accounts will get signed.

ADDED:

  • After an account gets signed (successful trade), buyer gets popup that he was successfully signed and the initial limit was lifted. From now on the account is aging and the regular limits will apply based on it (e.g. 0.0625 BTC). After 30 days he will also be able to sign other accounts.

OPEN QUESTION:

  • How do we handle the limits for old accounts that will be signed by the arbitrator (< 1 month, 1-2 months, > 2months)? If we start the account age from now on from the time of signing, then also all old accounts will have the < 1 month limit in place from the start (e.g. 0.0625 BTC). Maybe we can solve it in a way that for accounts signed by arbitrators account age is counted since the account creation and for all accounts that are not signed by arbitrators account aging starts with the signing point of time.

@mpolavieja @m52go Please let me know if I missed any essential functionality. If not I'll start to create mockups for the critical screens of this new feature tomorrow and post it for feedback. In parallel I'll start implementing the required domain logic and tests tomorrow as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.