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 bisq-network/bisq#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 #27 (comment)

[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 #78 (comment)

[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 #27 (comment)

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

[m52go]

No silly concerns! Yes -- you can see first and last name of sender.

There may be edge cases such as name changes (PayPal claims 2-3 days lead time to process name changes, but how is that done, and what happens in the mean time?) that could be openings for scammers. I'm researching them now to better understand.

[ManfredKarrer]

We can consider any secondary bank where KYC is strong enough as such a 2FA. Paypal might be the weakest. Lots of scams and I would not be surprised that its not hard to fake name with a Paypal account.

[ghost]

It's a long time since I opened my paypal account, but for what I remember, you do it with ... a bank account (normally yours).
[Maybe it's even possible to open a paypal account without mentioning a bank account at all. In the case that the primary money source is transferring coming from other peoples paypal account(s)].
So I imagine that a guy with a stolen account without a paypal account associated can quite easily create it himself and do whatever he wants with.
(I'm also verifying how the paypal account creation works).

[mpolavieja]

Even if PayPal is not the best way to do it @m52go core idea still stands. As @ManfredKarrer says the core idea is 2FA with another account so any other bank account from a different bank could do the work. Not always instant though, but this could be a very strong verification measure.

[mpolavieja]

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.

@huey735 I was thinking about the use case of the one time user that just wants to privately buy around $500 - $4000 worth of BTC as a long term investment, and how we could facilitate UX for that kind of user (not having to wait to execute his trade). If the user does a minimum self verification (i.e. 2FA with 2 bank accounts, atm withdrawal, digital signature, etc) the system could allow him up to $2000 during the first month. Btw, I know that the delay option is being discarded at this moment, but this is the kind of user that probably wouldn´t mind a delay on the payment (we still would have the bad UX for the seller having to remember to take action once the delay is completed as I understand implementing an nlocktime for the release of BTC would not be easy at all as it would require a change on the protocol).

So I am constantly running into the limitation of not having trading information about the peer. Despite my privacy concerns, I fully agree that having this information would be a really powerful tool, specially during the first month. If we could have that information as "zero-knowledge" as possible just during the first month it could be extremely useful.

[flix1]

Instead of a distributed reputation... how about a "3 degrees of separation" system similar to that used by linkedin?

It would allow each user to label 10 payment accounts as "trusted"... and on the order book for each offer you would see a little (1) (2) (3) badge showing if the account used to create the offer is:
(1) Directly trusted by you
(2) Trusted by an account you trust
(3) Trusted by an account that is trusted by an account you trust
(-) Unknown to you or your trusted accounts

It would be merely informative, with no extra consequences or restrictions, but very visible.

Most importantly if you remove an account from your trusted list... it would disappear from all your contacts as a 2nd or 3rd degree trusted account.

Obviously this would only allow you to have up to 1110 1st/2nd/3rd degree trusted accounts... but on the other hand it seems easy to do, requires no personal identifying information and would be quite scalable.

What do you think?

[flix1]

A few more details about the above idea...

1. Degree of trust is for Payment Account.
   NOT for trader, user, onion seed or any other user or peer related info... to avoid any KYC slippery slope. This also helps avoid scammers switching payment accounts but keeping older trusted status to execute long cons or exit scams.

2. Information about trusted accounts is transmitted to the network in the same way that Account Age Witness is (account age should also be displayed more prominently in the order book).
   https://docs.bisq.network/payment-account-age-witness.html

3. Information is not centrally stored anywhere. Each node in the network has only local information about trusted accounts... plus the ability to receive 2nd and 3rd degree information from online trusted accounts.

4. It is crucial that trust can be easily and quickly revoked.
   No system is foolproof. But a system that can organically burn corrupted branches and build around them will grow stronger with time. Isolating scammers as fast as possible is very very important. Trust must be a scarce resource (hence the max 10 trusted accounts limit).

Since each payment account is already individually identified for account age purposes... all the information that you really need to store locally is a list of <1110 identifiers next to a (1)/(2)/(3). This might add a bit to the sync time for the network if this is updated often... but I believe the load would be very manageable.

Finally, this trust mechanism can also be used for negative trust as a warning and blacklisting mechanism similar to the one described in #27 .

[mpolavieja]

1.Degree of trust is for Payment Account.

Fully agree on that, we should take that as a core principle for any trust/reputation mechanism.

To make it more difficult for scammers to build a trust branch by setting up colluding accounts, would it make sense that you could grant trust to others only after you have been granted trust from someone else? That would require a bootstrap procedure... such as the one proposed by Manfred using the arbitrators for the initial trust setup. Or maybe your proposal goes in the direction of avoiding that initial setup by relying more on revoking?

[flix1]

Hi @mpolavieja the idea is that each user holds and manages their own whitelist of trusted accounts and also shares that information with the network. There is no signing of any kind. You don't grant somebody else's "trust" or some "official" network trust... you only grant your own trust and let the network know about it.

So it does not matter if a fraudster creates a thousand fake accounts and uses them to "trust" each other... as long as you personally don't add one of them to your trusted list, they will never have a (1) next to them.

Sure, if one of your trusted accounts adds a fake account to their trusted list, you will see offers using that account with a (2)... degree of trust decreases exponentially with each step away from direct trust. That is why only 3 degrees are really viable.

However this way is fully organic and decentralized. It does not rely on any initial bootstrapping or authority (such as arbitrators).

The information needed to bootstrap it is already there in your Bisq trade history: accounts that you have traded with multiple times months and years ago are the best candidates for you to trust.

Even if scammers create a fully corrupted branch of the trust tree... users have an easy way to disconnect from it and isolate it. (The scammers can trade with themselves!)

From a UX point of view this should also be very intuitive to the social media generation. With one key factor: trust must be made a scarce resource and so the number of accounts you can trust must have a (low) limit. Hence my suggestion of 10.

[flix1]

From the point of view of a scammer, to abuse this system you would need to enter the trust circles of honest users. There is only one way to do that: perform multiple honest trades with that account over a period of time.

The moment the account is:
-used for fraud
-anything suspicious happens
-a trade leads to a dispute
... or even it is just slow in completing a trade or gives bad information about payment (say wrong name or IBAN is used to make the payment)...

It will risk being dropped from the trusted list of the counterparty and replaced by a better partner in one of those 10 precious trust spots.

The system can be used not just to prevent fraud, but also to reward preferential trading partners who trade efficiently. Just like the Uber 5-star feedback mechanism signals good drivers.

Also see that it does not matter how many people trust you. That information is irrelevant and not shown to other traders. The only thing that matters is how close you are to direct trust with the other trader. So Sybil attacks or wash trading with yourself will not increase this score. Only convincing an honest user that you are also honest and reliable will have you added to their trustlist.

A scammer would basically have to exit scam individually every single trading partner by gaining their trust over time before scamming them. And here is where the warning system of negative trust could come in:

-Let's say that as well as a whitelist of 10 accounts you also locally manage a blacklist of 10 accounts.
-Next to offers you see (1)(2)(3)(-)(-1) or (!).

Where (-1) means that this account is in your blacklist and (!) means that it is in the blacklist of an account that you trust.

[flix1]

Considering that at the moment there are at most 40 live offers by maybe 10-20 traders on the EUR offer book... it would be extremely easy to set up this system. By the time the web of trust has spread to include those 20 traders... it would take a very short time for the (!) warning sign to be seen by everyone on any offers made with an account that has been used to scam someone.

Of course this helps reduce risk for takers... but what can we do to protect makers?

Maybe a maker can choose the option to restrict their offers so they can only be taken by accounts which are in their (1)-(2)-(3) trust circles? or to exclude accounts with (-1) and (!) from taking their offers?

I don't know if this can be done easily... But I like the idea of any restrictions and bans being set by users, not by the system or any Bisq "authority".

[mpolavieja]

But I like the idea of any restrictions and bans being set by users, not by the system or any Bisq "authority".

Fully agree

[ManfredKarrer]

@flix1 Thanks for the interesting idea.

Technically it can be done by requesting the trust assignments from the peers you choose by a request message and the peer responds with their trust list. There is some privacy issue though, maybe you don't want to reveal with whom you have traded to others? Maybe it could be limited so that only trusted peers can request that data?

For makers rejecting peers which are not above the custom trust level might be a bit of usability issue as the taker does not know if he is inside the maker's trust tolerance. Default behaviour would be that he gets rejected with an error. But of course that can be improved so that the taker gets a more informative feedback. So that should not be a major issue...
Adding additional messages in the take offer process might have some backward compatibility challenges, but are probably solveable.

We have to be careful to not make it too hard for newbies to find traders. It would decrease the existing liquidity. My personal experience on LBTC was that it is very hard to find traders if you are a newby and then price is usually very bad or those are low trusted as well (newbies). So entering becomes more frustrating and a certain feeling of being a "second class" user can creep in.

But beside all that, how much security does it add to the 2 main risks of scams (stolen account, money laundering)?

1. A stolen bank account scammer can trade a while until it gets detected in that time he can start gaining trust. The negative trust indication is not required here as such severe scams lead anyway to a ban by the filter mechanism, so nobody can ever trade with that onion and payment account anymore. So the trust score here would be more valuable if it gets some age factor based on the first usage of the account in a real trade, otherwise it can create for short time false impression of security. From our experience it takes 1-3 weeks for chargebacks. Negative feedback might be dangerous - flagging competitor traders has some financial incentive...

2. The money launderer scammer is more difficult to handle as it might take much longer until his account gets detected by the banks and it is not known yet if chargebacks are happening in such cases (so far we see currently no chargeback happened from the suspected cases). It can even be that we never know about. That some users gets closed their bank accounts for undisclosed reasons, as it happens quite often with N26 or Revolut might be indications that they had received money from money launderers but we have no facts about that. So all our time based protection tools do not work as we likely never or very late detect such cases. Those scammers are likely very active traders who transfer fast and therefore might get quickly earn positive reputation (fast release time, good prices,...). The hidden problem that the seller might get issues later with the bank once the scammer gets detected is not visible at all with that reputation idea.

So I think that idea is helpful for distinguishing fast traders from slow ones or ones who do "future trades" by canceling in case of high volatility but I fear for our current focus to protect against the above 2 types of scammers it will not add protection. We also need to take care to not create signals for a wrong feeling of security which is not covered by the type of protection. That is true for the other ideas as well. Just because we can be very sure that the user is not a chargeback scammer of money launderer does not mean he is a fast and honest Bisq trader (still could cancel out in case of high volatility, be very uncooperative in disptues,....). But I think those problems are less severe and the security deposit is already a good protection (for the "future trades" issue).

[flix1]

But beside all that, how much security does it add to the 2 main risks of scams (stolen account, money laundering)?

It does not help at all to prevent money laundering as these accounts can last for many months or even years before being detected. (Arguably all activity on Bisq could be considered an AML-risk).

It would help with stolen accounts. 2-3 weeks is probably not long enough to gain much trust and because they would need to do honest trades to gain that trust it would increase risk of detection.

...but this is maybe already covered by the amount limitations that come with account age witness... and a simpler solution is preferable to a complicated one if the benefits are the same.

[flix1]

Much simpler:

Display prominently in the offer book:

1. number of times that you have traded with that account
2. account age.

Information for both is already available. No major changes or innovations are needed to implement this. There are no additional privacy concerns.

This would allow takers to actively discriminate by only trading small amounts with unknown accounts and doing larger trades with those accounts that they personally have a longer history with or have been around for a long time.

We already show the number of times that you have traded with a certain trader (based on the onion address?) but not with a particular payment account.

[reipichu]

I have been formulating a proposal for an alternative solution to this problem, but it still needs some issues ironing out, so I will post my preliminary thoughts here:

The proposals we currently have for distributed trust and reputation systems (such as the one described above) are quite complex, which could make analysis of possible attacks quite difficult in practice. I'm also not convinced that we should move towards a system where we rely on the arbitrators as the root of trust - even though they could do this job, if we want to move to new trade protocols that remove the need for arbitration then this proposal would be a step in the opposite direction.

Our primary issue with account aging currently is that it is only a reliable indicator of stolen account risk if we can guarantee that the aging started along with the first payment made from the account. The main problem here is that a scammer can make a fake trade to start aging, and so this is what my proposal here addresses, using the much simpler idea of BSQ bonds, which have been mentioned elsewhere but I have not seen a concrete proposal as to how they could be used.

1. Introduce the concept of "Bonded Traders." These traders have locked up a BSQ bond, and their bonded status is relied upon solely for the truthful confirmation that a fiat transfer was indeed made to their account following the trade rules. These users are then trusted to attest truthfully that a transfer was made.
2. New Traders start with restricted trade limits for buying, for example 0.01 BTC (total) per 30 days, and can buy only from Bonded Traders.
3. In order to start account aging, a New Trader must make a trade as a buyer with a Bonded Trader as seller. The Bonded Trader signs the Account Age Witness record with the date of the trade to indicate the start of account aging. This is performed by the client when the Bonded Trader clicks "Received Payment."
4. In the event that the New Trader initiates a chargeback within 30 days of the date of the first trade, there is no consequence to the Bonded Trader and no risk to their BSQ bond.
5. When the account age reaches >30 days, the New Trader's trading limits are increased and they are permitted to trade with any other (non-Bonded) trader.
6. In the event that the New Trader initiates a chargeback after 30 days from the date of the first trade, then the attestation of the Bonded Trader is called into question (ie. it is considered likely that they may have lied).
7. In the case of (6), the Bonded Trader must now demonstrate proof to an arbitrator that they did indeed receive the fiat transfer from the New Trader (eg. using PageSigner) corresponding to the date they signed the Account Age Witness. If they can prove this then their BSQ bond is safe. If they cannot prove it then their BSQ bond is forfeit.
8. In the case that a Bonded Trader forfeits their BSQ bond, all signatures by this trader attached to Account Age Witness data will be considered invalid.

The properties of the described system are as follows:

• Due to (2), if the scammer does not bond BSQ themselves, they are limited to only being able to steal 0.01 BTC per stolen account, per 30 days. It is very likely that the chargeback will occur within 30 days, so this becomes 0.01 BTC per stolen account in total.
• Due to (6) and (7), the economics for a scammer are such that it is only profitable for them to bond their BSQ with the intention of losing it if they are able to make trades which sum to greater value than the BSQ bond before the first chargeback occurs, at which point the bond is forfeit and associated accounts (those signed by the scammer's Bonded Trader) are blacklisted.
• Due to (8), it is advisable for honest New Traders to perform their first trades with more than one Bonded Trader, to minimize the risk that their Account Age is reset to 0 if one of their Account Age Witness signers is blacklisted.

Using BSQ bonds as the root of trust for attesting account age leads to a similar system to that described above, but much simpler and with a clear economic disincentive to attempting to cheat the system, and an easier way for us to control that economic equation, by modifying the BSQ bond required or modifying trade limits, as necessary.

[mpolavieja]

Hi @reipichu, I think that most of us in the community think that BSQ bonding will be the best solution. The problem is that if requiring to own some BTC in order to onboard Bisq is a barrier of entry, requiring BSQ would raise the barrier of entry even more.

Furthermore, BSQ token still needs to mature, and we need a solution in the meantime.

Proposal #93 is a more concrete approach to strengthen account age as a trust parameter. In that proposal it wouldn't be that easy for a scammer to fake a fiat payment. The real root of trust in this proposal and also in #93 is not really arbitrators but old users.

In #93 it is also suggested to put the first stones to pave the way for an arbitration-less protocol by enabling direct communication between users. And once arbitrators are gone, a decentralized blacklisting system can be implemented (we already have a rather solid conceptual design), which will be needed anyway regardless of the protocol (BSQ bonding included).

I think we should focus on the priorities set at #91. What you propose is indeed excellent input for priority number 3, but we all need to make a decision first about priorities 1 and 2.

[reipichu]

The problem is that if requiring to own some BTC in order to onboard Bisq is a barrier of entry, requiring BSQ would raise the barrier of entry even more.

In respect to the above, the system I outlined above would only require BSQ bonds for old users or regular traders, not for new users. The Bonded Traders would be used to ascertain whether an initial fiat payment has occurred from a new user who has traded with them - the new user just needs to pick a Bonded Trader to trade with for their initial trade.

One incentive for old users to bond BSQ to be trusted to validate new users would be that they would be able to set slightly higher margins on their trade pricing as they would have a captive market of new users wishing to verify their payment accounts by trading with them. If that incentive is not sufficient, we could also consider a stipend/interest paid to Bonded Traders each cycle - not dissimilar to the role arbitrators currently serve.

[mpolavieja]

Yeah. Bonding BSQ opens a new ocean of possibilities. Indeed it could be implemented that for small quantities only the sellers would bond BSQ, as you said, and buyers would not need BSQ nor BTC, just fiat, and the seller would release the BTC upon receiving the fiat. So the on-boarding UX of newbies would be much better and it could lead to dramatically increase the number of Bisq users.

But we would need to address carefully the risk of a scammer becoming a bonded seller to fake witness-sign an army of stolen accounts and deploy an attack after 30 days. If the bond is low, it could be profitable for the scammer. If the bond is high it could be impractical for honest sellers. I still think that relying on old users (> 6 months) as a root of trust is very interesting. Maybe a combination of age and bonding would do the trick.... Discussion is needed

So as I said, we need first a practical solution within the current trade protocol, and then we can start the discussions and implementation of the new trade protocol (priority number 3 at #91)

[mpolavieja]

Closed as approved. Although not exactly as initially proposed, account signing has been finally implemented in version 1.2.