Distributed reputation system

[ManfredKarrer]

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

In a discussion with @mpolavieja we developed a feasible solution for a distributed reputation system based on the account age witness but including a proof of a bank transfer. It is bases on an existing trusted element (arbitration) and from there we can build up a hierarchy of trusted traders.

The arbitrators could sign with their key all account age witness data from fiat traders who had completed the trades (fiat was trnasferred) and which have been older then 2 months. The P2P network payload data will contain the signature, the account age witness data (hash) and the public key of the arbitrator and it is distributed to all nodes. Anyone can verify the signature with the public key of the arbitrator. This will create the root of trust where the arbitrators are a semi-centralized trust root and they give those traders trust level 1.

We apply that to both buyers and sellers. It is guaranteed that the buyer did not has made a chargeback in that time frame. The seller does not give that guarantee but it is very unlikely that the scammer used his own account to receive the Fiat so it seems reasonable to include sellers and gain 50% more of initial level 1 peers.

For signing we might need to use the hard coded EC key as only that is persistant. The normal signature key would not be available anymore once an arbitrator has revoked as it is only part of the arbitrators P2P payload data. We need to think here about the future changes with integration of check for validity of an arbitrator depending on acceptance and locked up bond in the DAO. The current hard coded pubKeys will become obsolete then.

If a new user with a fresh account is trading with one of those traders who have received a signature from the arbitrators the trusted user will sign the untrusted one's account age witness data. By that he will gain trust level 2 but it will require some aging until it is considered trustworthy (e.g. the peer could still make a chargeback in the upcoming weeks). We could use a linear function to derive some trust score from that age.

It is an open question if a single signature is enough here or if we should require up to 3 signatures from 3 different trusted traders. Collusion risk between a potential scammer with a trusted peer is probably a very low risk. If we require too many it leads to some privacy loss for the trusted peer as with his public key anyone can see how often he has traded. If the number of such signing interactions are rather low the visible nr. of trades is much lower than the real number of trades and the problem is less severe.

Another open question is if the signing only would apply to buyers or both to buyers and sellers? Again if the seller is the scammer he would receive the funds on a stolen account which is unlikely that he want to do. If the victim sees incoming money he might get alerted as well and the account can get closed. So we prefer that the process of building up trust happens faster by doing it both ways rather that to be too restrictive.

All that signing and data publishing would happen without user interaction in the background.

A bigger challenge than the implementation of that part is the user experience aspect. We need to find a way to communicate those complex concepts in a simple way to users: The untrusted user need to understand why he has a low trust score and what he can do to increase that. The trade peer need to understand what risk he is willing to take (by trading with low trusted peers) and what are the usability consequences (delayed payout).

It has to be combined with the other proposal about the delayed payout. We need to support both the current account age witness system and that enhanced one with the signature of a trusted peer who has trades with you. With the current weaker account age reputation we are not protected against a scammer who is willing to wait for 1 months without using the stolen account. With the enhanced system one's account age would only start aging once you have done a trade with a trusted peer. New users would prefer to trade with a trusted peer so that they can get faster a good trust score. All that need to be packed into the UI in a way to not confuse users and to not add too much requirement for reading and understanding all that background. Probably the biggest challenge in that proposal....

[mpolavieja]

If a new user with a fresh account is trading with one of those traders who have received a signature from the arbitrators the trusted user will sign the untrusted one's account age witness data.

I understand that the signature from the trusted user is done in the background when the trusted user confirms the payment from the untrusted user. That is, the signing is fully linked with the payment confirmation and the delay. Correct? The new user should only get the signature from the trusted user when both the payment is confirmed and the delay time has been completed without disputes (i.e. chargeback request).

[ManfredKarrer]

Yes the signing happens after trade is completed. Not sure how to combine it with the delayed payout. Basically it could be kept independent. The signature alone has not much value yet only after the accunt age reaches a certain level. We need a mechanism for banning scammers so in case a signature was created and 1 week later a chargeback happens that account age witnetness become invalid. But I think that is not really required as a scammer gets added to the filter and cannot use that payment account anymore.

[mpolavieja]

If in the delay process it is required that the seller explicitly takes action in order to release the Bitcoin, then the signing can happen at that moment instead of on the payment confirmation. What we really want to be signed is the fact that no chargeback has occured, not so much that the payment has been received.

[ManfredKarrer]

Yes, I am just not so sure if we should combine too closely together both proposals (delayed payout) as that would let inherit that proposal the properties we have set in the other. I mean if we make the signature after the 30 days account age is reached then the signature will be considered valid if 30 days have passed. If we want to change that 30 days delay we automatically would change the signature handling as well. Also if the scammer has waited 30 day without using the account he would not have any delay and the trusted peer would sign directly.

If we keep it separate we are more flexible. E.g. If it is signed at confirm payment received we know the trader has used that account but we don't know it it might be chargebacked. So we treat such signatures less trustworthy. Only after a certain time (e.g. 2 months) we consider it safe. If a chargeback happens in the meantime it will get escalated anyway and the scammers account get banned. That banning is a centralized element but as its only exceptionally used I think its not a problem. We want to make the system so that scammers don't use it in the first place as they have no chance to succeed so if the meachnism for detecting and banning is fully decentralized or not is not that relevant IMO.

Also keeping all those protection tools separate will make it easier to combine it. Some future ideas like the certificacte or BSQ bonding might get added and they all in sum create a trust score. E.g. A new user who is willing to lock up 10000 BSQ can be considered trustworthy even if his signature is just 1 day old. If we would not publish the signature before 30 days is over that information that he has traded with a trusted peer and used his account would not visible. But as it is valuable information we should make it visible and leave the interpretation to another layer.

[mpolavieja]

Ok, I see now. Making it modular is best.

One concern I´ve just realised is that if a signed new account happens to be a stolen account, arbitrator eyes might turn not only to the scammer new account but also to the owner of the old account. This is bad if the old account owner was honest and simply the scammer´s victim realised the scam on a later transaction after the delay, but it is good if the old account owner was somehow colluding with the scammer by confirming an unexisting payment. My point is that with this system some kind of responsability could fall onto the signer.

In this respect your approach by keeping it separate is better because the old account owner is just confirming a payment, which later the system uses for the account age mechanism to build an "account age reputation". It is good that the old account owner does not finalize the process by signing.

Anyhow, If the old account owner is honest there wouldn´t be any responsability/liability problems outside Bisq as long as he can demonstrate that he received the payment, which he can prove with his bank information. Correct? The only risky situation for him is that if he mistakenly (honestly) confirms an unexisting payment from a scammer... That would be an extremely unlucky situation, but just thinking out loud....

[ManfredKarrer]

Regarding arbitration keys: We can use the current hard coded keys and later once the DAO side validation of arbitrators is implemented we can use the EC key of the input for the arbitrators bond. This data is always available also if an arbitrator has revoked and the bond is unlocked. We will need to support then both implementations, thought the current one is rather trivial. It is also questionable if we need to repeat that initial trust distribution from the arbitrators side if there are enough trusted traders who give further the trust to new users.

Another aspect to consider is how we treat new users getting verified by trusted traders. Once their account is mature they can act as signers for others as well. Should be consider them level 1 trusted users or add a new level 2 for them and the later level 3,....? As the initial trust distribution from the arbitrators does not give much more security than later when a traders account matured and he is enabled to sign others, I think we should not add complexity by multiple layers and treat all the same. The main security parameter is the time we want to wait before we consider an account safe, not if the signer received his signature from the arbitrator or other trusted traders.

[mpolavieja]

Another aspect to consider is how we treat new users getting verified by trusted traders

I´d say that once the account is mature it can be used to verify other traders. For more security I´d rather require more than 1 trade with old users and keep the non mature / mature binary, than adding more levels

[mpolavieja]

Regarding the above, I am not sure if we could have a limited issue with the accounts created the last few weeks and until this system is put in place, those accounts would be in the middle of nowhere.... Not old but not new, and created during a specifically risky time period. How will this accounts be treated when they become old?

[mpolavieja]

The only risky situation for him [old account owner that confirms the payment] is that if he mistakenly (honestly) confirms an unexisting payment from a scammer...

Regarding the above risk, requiring that 2 old accounts confirm a payment for the new account to become mature, would extremely reduce the impact of one of them mistankly (honestly) confirming an unexisting payment from a scammer. Given that this risk is worth mitigating.

Furthermore, if liability / responsability is an issue (I am not sure about that), then maybe it would be worth requiring 2 of 3 payment confirmations from old owners and randomly selecting the 2 of 3 to relieve individual users from that possible liability.

[sqrrm]

These are some interesting ideas. My first thought is how this will be done technically, do we keep some kind of accountagewitness map with respective acks from other trusted nodes? How do we avoid backdating and other such issues? This is probably solvable, sounds like @ManfredKarrer has an idea. Sounds like it will be quite a bit more complex than the current accountagewitness.

I also wonder how we protect against an attacker that creates a genuine account, makes a tx and ages it such that they now have a trusted account. This attacker can now make fake trades with stolen accounts to age them and thus make them trusted. There is a bigger risk for the scammer as there need to be at least one genuine bank tx at some point but it seems like an attack vector.

This kind of distributed reputation system probably adds some extra protection, at the price of complexity and possibly a feeling of being safer than it is. I'm not sure if it's worth adding or not.

[ManfredKarrer]

@sqrrm See https://github.com/bisq-network/bisq/pull/2768

Basic idea: A new P2P network payload similar to AccountAgeWitness which takes a hash of a AccountAgeWitness the pubKey of the signer, the pubKey of the AccountAgeWitness owner, the date and the signature. It is date protected in the same way as the AccountAgeWitness (prevent backdating). It starts that arbitrators sign the AccountAgeWitness of traders of completed fiat trades (fiat was transferred). Then those who got signed can sign others with whom the trade.

Regarding your attack concern: If the scammer uses the account for any tx it is likely that the fraud gets detected and leads to a chargeback and he loses control over the account. The signing of the AccountAgeWitness does not mean that the account owner is immediately trusted. It starts aging from that moment on and only after a certain time it is considered trusted. If it was a scammer it get banned anyway via the filter objects.

[ripcurlx]

Regarding your attack concern: If the scammer uses the account for any tx it is likely that the fraud gets detected and leads to a chargeback and he loses control over the account. The signing of the AccountAgeWitness does not mean that the account owner is immediately trusted. It starts aging from that moment on and only after a certain time it is considered trusted.

Would it make sense to make signatures by a scammer account invalid? Just to prevent having lots of sub-accounts of the scammer in the system that might be trusted ones in the future?

If it was a scammer it get banned anyway via the filter objects.

But that is just for the case that she is using the same onion address.

[ManfredKarrer]

@ripcurlx The account age witness is based on the account data (IBAN,...). We can ban users by that account data and then the user is blocked independent if the account age witness is valid. Those account age witness data and the signed ones are immutable append only data so we cannot change or invalidate those directly, but use an external ban list to check if one is valid or not.

[ghost]

Transfered to https://github.com/bisq-network/proposals/issues/27#event-2291785175

[ManfredKarrer]

@sqrrm I understand now your attack scenario (after our discussion). I summarize it here again and documment the protection idea:

Attack: The scammer could use a sybil account (his own valid account or a colluding peer) to get a signature by doing a real trade. After he gets signing right (e.g. after 1 month) he do a fake trade (no fiat transfer) with the stolen account to that sybil and gets the signature as well. He does not use that stolen account for any transfer so it stays undetected. After 1 months he is fully trusted and he starts his cashout scam and don't suffer the delayed payout of the BTC.

Protection: Once a chargeback is detected we can check which account age witnesss owner has signed the scammer (the sybil in above case). We check who has signed the sybils account age and with that we detect the users who have really traded with the sybil. They get an alert in their app to report the sybil to the community and the account details (name, IBAN,...) can be used for criminal prosecution. Just to have that option in place should increase the risk for the colluding peer a lot to not be part of it.

[mpolavieja]

regarding @sqrrm attack scenario, An scammer creating real accounts and doing real trades is definetively possible, but he would be exposing his identity very dangerously. So it is not an easy path at all for him.

Another way of adding protection from that attack is requiring more than 1 different old account to sign. The scammer would have to expose himself even more with several real accounts and trades. Although this would make identifying the sybil account more difficult.

Also, as Manfred points out and I highlighted above, if scam happens eyes will quickly turn to the signer. In that respect please see my comment above about possible signer liability https://github.com/bisq-network/proposals/issues/78#issuecomment-485751009

[ManfredKarrer]

Yes I see the liability issue now different. I think there is no risk for the signer as long he can proof that the fiat transfer really happened. All what he would be required in case if the above scam scenario is to provide the sybils account data and then the sybil need to proof that he did a real transfer with the scamme and he will fail on that. Of course in reality it will be harder as peers will not be online anymore, etc...But I think just to have that option in place makes it very risky for the sybil to collude.

Maybe we need to add another note in the "Confirm fiat" popup so that it is clear that this confirmation has an additional security context. But not sure if that gets too complicate then?

[mpolavieja]

I am not sure because making it clear to the user could make it even more liable like it is his responsability and not that the system is just using his payment confirmation to build a reputation by its own. I acknowledge that I am little bit throwing the stone and hiding my hand with this liability issue. Just want to raise it to make sure is considered, but probably not that relevant.

Liability only would arise in a situation where the signer mistakenly (honestly) confirms an unexistent payment from a scammer. But I guess that´d be a rather unlikey situation.

[ManfredKarrer]

I think the parameters (how many signers, age,...) should be delegated to the trust score layer so we are more flexible. The signing theshold though is a binary issue and cannot be changes later to not invalidate the trust chain (it is sort of blockchain of trust). So we need to make a good future proof decision here. Requireing too many signers to enable one to sign will slow down the propagation of trust. But 2 might be a reasonable number. How we interpret the age is up to the trust score domain. With signing the age starts but is does not provide security as the account still can be chargebacked. So we can be flexible what age we use to increase the score and how the score influence dealyed payout and deposit amount. The trade amount of the fiat transfer might be important to add as well to avoid that the scammer makes a real transfer to his stolen account which might be harder to detect for the victim. Probably not a big risk but we should consider to add that into the data.

[mpolavieja]

I feel inclined to require more signers, but that also has the problem that if the scammer manages to become a signer, it is more difficult to identify him amongst other signers. Keeping it down to 1 signer is the positive side of the liability problem (plus it is less complex).

As a general comment, I forgot to say this at the dev call, for me the strongest deterrent for scammers by a huge difference will be the payment delay. The fact that new accounts are unable to cash out bitcoin for several days after the payment is extremely risky for the scammer compared to now having many chances that the scammer cashes out the btc before the chargeback request happens. This is a difference like night and day in my opinion.

The reputation, if we get it right, would round this up by deterring also patient scammers. But probably keeping it as simple as possible is best. So I agree flexibility and simplicity is important. So I would vote for just 1 signer. Not completely sure, though.

[ghost]

Sorry, what is a " EC key " ?

[flix1]

Agree with @mpolavieja that time is the biggest factor. Scammers work under time pressure.

The biggest drawback is that delays also impact all honest users. Considering that fraudsters represent a tiny % of trades and users... it is sad when ux is made worse for everyone to deter the 0.1%.

[ghost]

I tend to agree with flix1. I'm not convinced with using delay as a relevant tool here. It may harm the application usage, and at the end just push the problem a bit further. So in the long term it will bring nothing, at the price of damaging the appli. Higher deposit seems me a more relevant "fly to quality". Ring of trust also. And also blacklisting encrypted IBANs in a publicly maintained list as I suggest in https://github.com/bisq-network/proposals/issues/27#event-2291785175

[ManfredKarrer]

Sorry, what is a " EC key " ?

Elliptic curve key (e.g. Bitcoin key)

[mpolavieja]

if the scammer manages to become a signer, it is more difficult to identify him amongst other signers. Keeping it down to 1 signer is the positive side of the liability problem (plus it is less complex).

Now I realize that this might be stupid, if there are 2 signers that sign a fraudulent account, it is very likely that both are scammers.

[mpolavieja]

Fully agree with @flix1 on the drawbacks and that fraudsters will be always a minority. But not having any delay is a red carpet welcoming the use of stolen accounts. For example having a minimum delay of 2 or 3 working days (which is happening already in many trades where the payment is received on the 2nd day and it is confirmed in the 4th or 5th day) would make a huge difference from not having a delay at all for new accounts.

Regarding Harry concerns, I agree it might harm application usage, but chargebacks will also harm application usage, there are not so many banks, and as chargebacks occur bisq users could be eventually banned from all banks, specially the most active ones which are the ones that provide liquidity and make the system usable.

[mpolavieja]

I also agree with Harry that higher deposits are a fly to quality. Organized markets have been working like that for centuries for a reason. But to deterr scammers without a delay the security deposit must be at least as high as the trading amount, which would also impact UX.

What are you referring by "ring of trust" @HarryMacfinned ?

[m52go]

These measures (delayed payout and distributed reputation) would only need to be enabled for fiat payment methods with chargeback risk, correct? So anything cash-based like face-to-face and money orders (Western Union via cash, Moneygram, etc) would be exempt from payout delays and reputation limits?

If so, they could be mitigating factors for usability/new-user on-ramping, since bank-related ones will make the process slow and frustrating.

[ghost]

@mpolavieja In fact I had that in mind : https://en.wikipedia.org/wiki/Web_of_trust It's just that the Bisq network itself is 99.9% of honest users. And thus, there is no need to a "better" proof of confidence than itself. No need imo to use old gov tools. btw, I'm quite confident that the new protocol proposed by Manfred (based on a big deposit/bond as far as I understand) is a long-term solution to scammers issue, at least on the makers side. We had probably a better time bringing users there than stacking patches engineered too rapidly.

[mpolavieja]

99,9% of honest users when the liquidity is still low. But liquidity is growing and if because of that growth honest users drop to 98%, that could mean fiat trading is doomed. Chargebacks from stolen accounts will kill market makers, even if they are very few and low quantity (below 300€) because the default behaviour of Banks when a chargeback from a stolen account occurs, no matter the quantity, is to target the recipient (the market maker) as suspcious of a criminal activity.

Fully agree, however, that the solution based on big deposits is very promising. It is the one I like the most, but I fear that it would also be an important barrier of entry for small traders.

[ManfredKarrer]

These measures (delayed payout and distributed reputation) would only need to be enabled for fiat payment methods with chargeback risk, correct? So anything cash-based like face-to-face and money orders (Western Union via cash, Moneygram, etc) would be exempt from payout delays and reputation limits?

Yes it would only affect bank transfer based payment methods.

[flix1]

Please see this idea for Payment Account reputation/verification in a distributed way: https://github.com/bisq-network/proposals/issues/23#issuecomment-487028547

I believe that between this system and BSQ bonding we could do a lot to eliminate scammers.

[huey735]

Without taking into account any certificate, the reputation system (only relevant to BTC buyers with fiat payment methods with risk of charge back) should contain the following elements:

• account age - ideally > 31 days. This value should hold the least weight as the next values will complement and replace it
• number of days since first trade - ideally > maximum period allowed for charge-back (6 months)
  • if => maximum period allowed for charge-back weight = 100%
  • looking at charge back statistics we could implement different weights:
  • if => 20% of maximum period allowed for charge-back weight = 20%
• sum of days in-between trades - ideally > 30. It serves to distinguish between 20 trades on one day and 20 trades distributed through 3 months
• number of different trade partners - ideally over 4
• reputation of trade partners - ideally over 400

Trades here refers to complete trades with age < maximum period allowed for charge-back. Successful trades are those with age > maximum period allowed for charge-back

How we should treat newcomers BTC buyers

• high security deposit that is delayed in reimbursement - maybe > 7 days after end of trade limit duration
• allowed to only make 1 trade every 7 days
• limit trade amount like it's already done

How we should treat those with high reputations

• stop counting positive trades after a certain reputation - as soon as number of days since firs successful trade => maximum period allowed for charge-back

We should have a warning in the Pending trades screen alerting users to verify that the details of their trade partner provided by Bisq match those in their bank account.

[ManfredKarrer]

Thanks @huey735 for your input!

We have to consider that a trade is basically anonymous. So counting number of trades is not easy to achieve. Signing the account age witness will also reveal information about trade activity for the signer who might not benefit as he has already a good reputation. Maybe it is not a major concern but should be considered as well....

[huey735]

@ManfredKarrer The network can see the onion address of an offer or finished trade, can't it? Couldnt' it be able to log it and deny any new offer for 7 days? Also we could incentivize traders to get 1 token of reputation from which we could have a reference. They'd need:

• account age witness data
• trade id
• their position on the trade (maker or taker)
• and sign it with the the public key of address on which they've received the payout

And that signature would get that trader a token of reputation associated with that account age witness data. And it'd be stored by the network. One of those tokens with a certain age would give them a golden status. Those without this token would be exposed to extreme delays. Those with a token that's like 1 year old would get a Gold badge. The network would lookup the ledger for that account age witness data and if it found a token with a certain age it wouldn't append any new information. I think all this could be done directly through the software by contacting the arbitrators.

[flix1]

How we should treat newcomers BTC buyers high security deposit that is delayed in reimbursement - maybe > 7 days after end of trade limit duration allowed to only make 1 trade every 7 days limit trade amount like it's already done

Please don't forget about DEMO MODE. It is extremely important for newcomers to be able to play around and do a few trades immediately after installing Bisq to learn how it works.

Otherwise the learning curve is interrupted and onboarding becomes a disaster.

So by all means limit trade amount, but don't limit number of trades and don't force them to wait 30 days for a payout on their first trade. None of the above restrictions should apply to 0.001 BTC trades. There is practically zero risk of fraud for such low amounts.

[ManfredKarrer]

If trade amount is below 0.01 BTC (about 50 USD atm) there are no delays and increased security deposit (same as now).

That is planned demo mode.

[mpolavieja]

• stop counting positive trades after a certain reputation - as soon as number of days since firs successful trade => maximum period allowed for charge-back

@huey735, The possibility of users accessing other users trade data should be kept to a minimum for privacy reasons. This is specially relevant for highly trusted and very active traders that could be targeted by regulators, specially if they are mainly posting offers (market makers).

[mpolavieja]

I am thinking about sellers setting up Bisq so they won´t let fresh accounts (bronze) take their offers. As @ManfredKarrer pointed out, if all trusted users do this, it will be hard for fresh accounts to get validated.

Could it be possible that the most restricted setting would still allow for each fresh account to at least trade once with a trusted peer?

If possible, I understand it might be a UI a challenge for the user to understand. That minimum enablement for the most restricted setting could be one of the following:

• Allow one trade with only one fresh account for the trusted account lifetime (most restrictive)
• Allow one trade with a fresh account once a month (i.e. validating a fresh account each month)
• Allow only one trade with the same fresh account (it would allow to trade once with many fresh accounts)

[mpolavieja]

If I recall correctly, trade amount limits could not be used to completely restrict bronze accounts taking your offers, as a bronze account can have the highest trading amount limit after 45/60 days.

[huey735]

• stop counting positive trades after a certain reputation - as soon as number of days since firs successful trade => maximum period allowed for charge-back

@huey735, The possibility of users accessing other users trade data should be kept to a minimum for privacy reasons. This is specially relevant for highly trusted and very active traders that could be targeted by regulators, specially if they are mainly posting offers (market makers).

Exactly, that's my point. That after a certain status there shouldn't be the need for more data. I think we could limit the revealing of trade data to 1 instance, the first trade.

[ManfredKarrer]

The signed witness data are only created once between 2 traders, so if they repeat trades with the same accounts there is no additional object created/stored. So that reduces to leak information how many trades one had. We can extend that so that if one has already a signature he will not require an additional from another trader. That also helps to limit data storage.

Regarding the suggestions above. I prefer to keep it as simple as possible and tracking number of trades etc. might be tricky to implement anyway.

What if we just remove all restrictions for small amount trades (< 0.01 btc)? So if one creates an offer below that amount he cannot restrict the offer to takers who have silver level. So all new users are able to take such an offer. Still the question if we should allow those trades to be signed by the peer if he has silver level?

[mpolavieja]

One possibility to "incentivize" trusted user to sign fresh accounts is to disable the controls on the UI for restrictions until they sign at least one or two fresh accounts.

[mpolavieja]

What if we just remove all restrictions for small amount trades (< 0.01 btc)? So if one creates an offer below that amount he cannot restrict the offer to takers who have silver level. So all new users are able to take such an offer. Still the question if we should allow those trades to be signed by the peer if he has silver level?

I thought about this approach as well, the problem I see is that it could place the core of the reputation system (the signing) in a riskier environment as there are no delays. IMO delays is the strongest deterrent for scammers. Reputation is the cherry on top of the "delay cake".

[m52go]

What if a buyer sends the seller 1 USD via a service like PayPal upon taking an offer? Verified PayPal users have already done KYC to ensure they actually own their bank accounts. If a buyer can send a tiny payment via PayPal to the seller, after accepting their offer, odds should be pretty high they're not a scammer, as a scammer would need to gain access to a victim's PayPal account in addition to their bank account.

PayPal payments are instant, so if buyer cannot send the tiny payment, the seller knows he should send the trade to arbitration. Only change this should require in the interface is an additional field in the payment account details for PayPal address.

Maybe this is 1 route to elevated badging and fewer restrictions without having to wait? Especially since the delayed payout may not be feasible as originally planned.

[ManfredKarrer]

@m52go Interesting idea. Would you mind to create a new proposal for that to avoid to mix too much other proposals. We could get a mix of several tools. We need to kepp inmind the opionality as not all want to use or have that option and the UX costs.

[m52go]

Sure. I wasn't sure if it could be weaved into the reputation system somehow. Will do.

[ghost]

I confirm that paypal is indeed easy to create an account and easy to use. Good idea from Steve ! Thanks.

[mpolavieja]

as a scammer would need to gain access to a victim's PayPal account in addition to their bank account.

Although this additional paypal check would certainly make things much more difficult for the scammer, wouldn´t it be possible that the scammer uses some random stolen Paypal account unrelated to the owner´s bank account?

[m52go]

I believe PayPal has a Verified level which a user can only attain after verifying their bank account and their identity. If it works as intended, it should make it vastly harder for a scammer to use a random stolen PayPal account since the identity of the PayPal user sending the tiny payment wouldn't match the identity of the bank account owner in Bisq.

I'm researching PayPal's policies (as well as those of Venmo, Cash App, and some other popular payment methods) to better understand their processes and will make a separate proposal soon.