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

[m52go]

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]

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]

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]

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]

'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 :

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

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]

2. 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]

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]

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]

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]

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]

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.

[ghost]

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]

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 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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@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 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]

@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]

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]

@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]

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]

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]

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]

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]

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]

Got it. Edited my comment above accordingly.

[mpolavieja]

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]

@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]

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]

@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]

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.

[mpolavieja]

• Buyer as maker is able to only allow verified account signers to take its offer

This is optional, right? This is very nice to have.

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

I don´t fully understand this. I would say that the account shouldn´t be able to sign until the account age (based on the new account age algorithm) reaches 90 days. Maybe this should be implemented as a parameter and we should discuss the value of this parameter.

• In the peer info popup we'll display how the user became a verified account signer (e.g. single payment with maturity over time)

I would wait to implement this until more methods are available.

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

Are the allowed trade time limits going to change?

OPEN QUESTION:

I would say that the easiest way to handle this is that arbitrators sign all accounts prior to 1 March, and all the other accounts are all 0 age until they get signed by other users, and then the account age will begin on 1 day, no matter when the account was created. Not very fair, but that way we can ensure the scammer does not sneak in as a signer without first having conducted a trade with a signer. This is always under the assumption that the scammer does not own an account prior to 1 March, which is fair to assume because the scammer has been inactive since the 1 March cut was made.

[ripcurlx]

This is optional, right? This is very nice to have.

Yes, I would have put it into the advanced options section when creating an offer

I don´t fully understand this. I would say that the account shouldn´t be able to sign until the account age (based on the new account age algorithm) reaches 90 days. Maybe this should be implemented as a parameter and we should discuss the value of this parameter.

At the moment implementation details oft the account age and limits are as follows:

• At creation of the payment account an account age witness is created and dated
• The age of the payment account is calculated based on the current time and the creation time
• For accounts younger than one month (< 30 days) the trade limit is 25% of the max trade limit (e.g. MAX 0.25 BTC for SEPA -> 25%: 0.0625 BTC)
• For accounts between one to two months (>= 30 day and < 60 days) the trade limit is 50% of the max trade limit
• For account older than two months (>= 60 days ) the max trade limit is used (e.g. 0.25 BTC for SEPA).

After the implementation of the protection tools it would be:

• At creation of the payment account an account age witness is created and dated
• At signing of the payment account witness an signed witness is created and dated
• ATM for the trade limits the account age date is used. That means as soon as the account gets signed, 30 days later the tolerated small trade amount of 0.01 BTC gets lifted and the regular trade limits based on the account age are applied.

Example: I have created an account after 1st of March

• My account age is between 1 - 2 months
• If my account gets signed, I have to wait 30 more days until the 0.01 BTC limit will be lifted. So I'll be able to trade 100% of max trade amount (account age 60+ days) 30 days after my account got signed.

I have created an account before 1st of March

• My account age is older than 2 months
• If my account gets signed by an arbitrator, do we also want the user to wait 30 more days until the 0.01 BTC limit will be lifted?
• If the 0.01 BTC limit will be lifted immediately for accounts signed by arbitrators we could get rid of the hard coded 1st of March ruleset in the code. So all old accounts continue to be able to trade 100% of max trade amount.

@m52go @mpolavieja If we show the age since signing in a separate column in the offer book it will be the same for all arbitrator signed users. On the first day everyone will have 0 days age since signing. Might look weird in the beginning, but I think it should be fine on the long run.

QUESTION: Do we want to continue to calculate the trade limits as mentioned above based on the account creation date or based on the signing of the account age?

I would wait to implement this until more methods are available. 👍 Yes, we can wait until the 2FA is implemented

Are the allowed trade time limits going to change? ATM I wasn't thinking about changing them. If we extend them it should only be for trades with an unsigned buyer account. In that case we could think about a factor that increases the existing trade limit only on the seller side (we don't want the buyer to be able to wait even longer). So there also needs to be some information popup for the buyer that the payout is delayed up to x amount of days because of security reasons. But that is something that should be actually presented to the buyer upfront as it might be disappointing to see this only after you already wired the money and expected the trade to complete soon. Also we need to display this additional waiting time to buyer and disable the ability to open a dispute in that case. So adding this would increase the workload for this feature quite a lot. We had this requirement already in the past and it made it quite complicated from the UI perspective. I agree that this might be a good functionality to protect the seller from getting scammed in the first place, but I would start working on it as an add-on after the account signing feature.

Are the allowed trade time limits going to change? ATM I wouldn't change them to reduce risk if a scammer is able to abuse a stolen bank account for longer.

I would say that the easiest way to handle this is that arbitrators sign all accounts prior to 1 March, and all the other accounts are all 0 age until they get signed by other users, and then the account age will begin on 1 day, no matter when the account was created. Not very fair, but that way we can ensure the scammer does not sneak in as a signer without first having conducted a trade with a signer. This is always under the assumption that the scammer does not own an account prior to 1 March, which is fair to assume because the scammer has been inactive since the 1 March cut was made.

For accounts that where created after 1st of March I do agree. I meant the accounts prior to 1st of March. Are they also age 0 after signing? I personally would be a little bit upset that I have to start again trading 0.0625 BTC amounts again for couple of months.

[mpolavieja]

On the first day everyone will have 0 days age since signing. Might look weird in the beginning, but I think it should be fine on the long run.

If old account age is greater than 111 days (days from 1 March to arbitrators signing date), is it possible to show old account age instead of the new one?

QUESTION: Do we want to continue to calculate the trade limits as mentioned above based on the account creation date or based on the signing of the account age?

I think trading limits should be calculated based on the signing date, but as you say, an exception should be made for those users with a creation account age greater than 111 days (i.e. days from 1 March to arbitrators signing date). For code cleanliness this exception could be removed when new account age catches up.

Regarding the 0,01BTC limit, my initial thought was that it would get lifted as soon as the signing trade settles. Now that you raise the possibility of waiting 30 days I am not that sure. Once 2FA is enabled then I do think it would be too conservative.

Are the allowed trade time limits going to change? ATM I wasn't thinking about changing them

Ok @

[ripcurlx]

If old account age is greater than 111 days (days from 1 March to arbitrators signing date), is it possible to show old account age instead of the new one?

I'm not sure if it is a good idea to use different values for different signers. Might cause even more confusion. I would label the column with something like Time since signing. On clicking the avatar icon you'll have both values anyways (account age and time since signing). I'll add something like a -Badge or similar to the time value in the list.

I think trading limits should be calculated based on the signing date, but as you say, an exception should be made for those users with a creation account age greater than 111 days (i.e. days from 1 March to arbitrators signing date).

I'm not 100% sure about that either. In the end we'll have payment methods without signing altcoins, payment methods where signing could be optional e.g. ALI_PAY_ID, and payment methods where signing is mandatory to release initial limitation e.g SEPA. Taking for different payment methods different starting points in time where the limitations are reduced is difficult IMHO to communicate for the user and also makes the code harder to maintain. Of course if there is a good reason for it to do so, let's discuss it. But as the chargeback risk should be handled by our signing process already there might be no reason to delay the account aging for the user.

Regarding the 0,01BTC limit, my initial thought was that it would get lifted as soon as the signing trade settles. Now that you raise the possibility of waiting 30 days I am not that sure. Once 2FA is enabled then I do think it would be too conservative.

Yes, delay should be doable. We have the date of signing in the SignedWitness store and can lift the limits only for accounts that were signed at least e.g. 30 days ago.

QUESTION: Do we want to force the signing restriction on all currencies for a high risk payment method or only for certain currencies (e.g. main markets: EUR, USD, CAD,...)? This would make it easier for bootstrapping new markets (e.g. JPY)? If a market is big enough we could release a new client version that requires signed accounts (would render old offers invalid until signed). So we would maintain a chargebackrisk list containing payment method and currency in the client (atm it is only by payment method: SEPA, SEPA Instant,...)

[mpolavieja]

Ok, I think I didn´t fully understand your concerns before. I see not that it is much simpler to use the signing as a way to simply unlock the limit of 0,01 BTC and leave everything else as it was.

The only concern there would be that a scammer colluding with a signer waits 2 months to get the highest limits as soon as the account is signed. Now I understand the importance of a waiting period after the signing process, which is not to allow the new user to make big trades until we are more or less sure that the signing trade has not been chargebacked.

So my answer is to the question of how to calculate the trade limits is to keep using the account creation date

QUESTION: Do we want to force the signing restriction on all currencies for a high risk payment method or only for certain currencies (e.g. main markets: EUR, USD, CAD,...)?

Enforcing the signing restriction would need some kind of trusted setup to appoint signers on new markets, or to allow that accounts become signers simply by aging while there are no signers or very few signers. Otherwise new markets could never have signers.

So my answer to that question is that I would not force the restriction on all currencies to allow bootstraping. However, the ideal solution would be to always make the signing in the background, but not enforcing the restriction for a currency until a minimum number of active signers exist. But I don´t know how much dev effort it is and therefore if it is worth implementing it.

Question: For main markets, under what condition are you thinking that a signed account will become a signer account?

[ripcurlx]

So my answer to that question is that I would not force the restriction on all currencies to allow bootstraping. However, the ideal solution would be to always make the signing in the background, but not enforcing the restriction for a currency until a minimum number of active signers exist. But I don´t know how much dev effort it is and therefore if it is worth implementing it.

The idea was to provide arbitrators with an interface to sign account age witnesses that fulfill following conditions:

• Account age witness date is before selected date (e.g. 1st of March)
• Of selected payment account type (e.g. SEPA)
• Was in a dispute with following condition: buyer received BTC (fiat was successfully transferred)

So we should be quite sure that we only sign accounts that had real trades. Arbitrators could run this signing again and again as it should only sign account age witnesses without a signed witness.

For bootstrap markets where the signing is not required yet, arbitrators can also sign accounts whenever they like. As soon as we have sufficient signed accounts or based on other metrics we can decide to force the market to require signed accounts after a certain date (similar as we do it now with the 1st of March rule).

Question: For main markets, under what condition are you thinking that a signed account will become a signer account?

After being signed the tolerated small trade amount of 0.01 BTC gets lifted 30 days later and the account will be able to sign other accounts x days (e.g. 60 days?) after the signing date.

What do you think?

[mpolavieja]

• Was in a dispute with following condition: buyer received BTC (fiat was successfully transferred)

I remember this condition was brought into discussion but wasn´t aware that it was going to be forced. It is indeed very good measure for mature markets. I am not sure if it would work for inmature markets, because once this signing condition is known, we could only use disputes where the arbitrator did have evidence of the fiat trade, because faking a dispute is trivial for scammers.

I suggested the possibility of accounts becoming signers simply by aging while there are not enough signers to not to rely on arbitrators for this, but I guess we should postpone this idea for arbitration-less context and for now it is better to stick to the same mechanism of arbitration sigining for all cases. However, if the code always relies on signatures still this raises the question for the long term sustainability of all this signing mechanism of who/how the first signers are going to get signed when there are no arbitrators.

After being signed the tolerated small trade amount of 0.01 BTC gets lifted 30 days later and the account will be able to sign other accounts x days (e.g. 60 days?) after the signing date.

For me anything between 60-90 days after the signing is ok. I would say 90, but would not be against 60.

[ripcurlx]

I remember this condition was brought into discussion but wasn´t aware that it was going to be forced. It is indeed very good measure for mature markets. I am not sure if it would work for inmature markets, because once this signing condition is known, we could only use disputes where the arbitrator did have evidence of the fiat trade, because faking a dispute is trivial for scammers.

That's true. That might reduce the number of signable disputes quite a lot and I think it will need a manual selection by the arbitrator. I don't think I can filter out disputes that fulfill the conditions automatically. So for the start for our mature markets it will work fine, as the pre-condition for being aribtrator signed wasn't known and I can provide automatic signing for arbitrators for all disputes with a payout to the buyer. Maybe for inmature markets it would work to sign on the go without having the 0.01 BTC limit in place and force signing as soon as the market explodes or we have sufficient signed traders.

I suggested the possibility of accounts becoming signers simply by aging while there are not enough signers to not to rely on arbitrators for this, but I guess we should postpone this idea for arbitration-less context and for now it is better to stick to the same mechanism of arbitration sigining for all cases. However, if the code always relies on signatures still this raises the question for the long term sustainability of all this signing mechanism of who/how the first signers are going to get signed when there are no arbitrators.

Yes, it is quite difficult to do this without having someone objectively verifying the fiat transaction, without risking getting scam signers into the system. Regarding forcing everyone to apply to this rule to be able to trade above the limits I was thinking again if there is an option to do it in a way without putting new users at risk, but still make it easier for new markets to bootstrap. Maybe we could remove the 0.01 BTC limit altogether as soon as the account signing and the chat is out and label all offers that are not signed and above the limit with a warning sign and additionally warn the seller during the trade process that he is trading at his own risk from that point on. So the seller has to do the account verification himself using the chat. Not sure if that opens additional attack vectors. Just a thought to put out for discussion. But probably not worth the risk if we have other account verification methods in place already, that will remove the limit immediately anyways.

For me anything between 60-90 days after the signing is ok. I would say 90, but would not be against 60.

Then let's start high with 90 days and go down if we see that it takes too long to get enough signed accounts in the system. Do we want to have special handling for arbitrator signed accounts? So that they are able to sign immediately. All this accounts are quite old anyways.

[mpolavieja]

So for the start for our mature markets it will work fine, as the pre-condition for being aribtrator signed wasn't known and I can provide automatic signing for arbitrators for all disputes with a payout to the buyer

Fully agree, please note that my concern is only for new markets were we would need to rely on future disputes.

For new markets, the warnings for the seller could be the most practical solution. Also, if there is a group of bootstrapping people in a new market, the signing script for arbitrators could be slightly adapted for that market to sign those users, coordinating when they set up their payment accounts so only their accounts get signed by narrowing and tailoring the account age condition for that specific market.

For a future arbitration-less context, I think a local reputation system a la linkedin as @flix1 suggested here https://github.com/bisq-network/proposals/issues/78#issuecomment-490123550 would help a lot on bootstraping (and it would be also very useful for mature operation). But of course this is for future development.

But in an arbitration-less context and for the long term viability of all this signing process I am still concerned on how are the first signers going to be signed and who will be the signers. The only way I can think of it is that accounts older than a certain date can always sign. Those old accounts would need to sign each other once they reach that specific age. Then the signing process for new users would develop as normal. Makes sense? Is it feasible?

Do we want to have special handling for arbitrator signed accounts? So that they are able to sign immediately. All this accounts are quite old anyways.

By special handling you mean that signed accounts would be signers if "account age < 1 march" instead of needing 90 days since signing? I would say yes, so they are able to immediately sign new users. Otherwise we would have to wait other 90 days to restore normal operation.

[ripcurlx]

The only way I can think of it is that accounts older than a certain date can always sign. Those old accounts would need to sign each other once they reach that specific age. Then the signing process for new users would develop as normal. Makes sense? Is it feasible?

Signing after a certain date for new markets might put us in a similar situation that if everyone knows this process a scammer could just create a fake account for each market now and wait. After signing is required he could start signing all his other new stolen accounts. He could go even that far to create multiple accounts for the same market, so he can use another one to sign if one gets detected.

By special handling you mean that signed accounts would be signers if "account age < 1 march" instead of needing 90 days since signing? I would say yes, so they are able to immediately sign new users. Otherwise we would have to wait other 90 days to restore normal operation.

Yes, I meant exactly that.