Reputation based trust model vs privacy

[Reckless-Satoshi]

Most p2p exchanges rely on reputation models. After a trade users can rate each other. Over time, users can build a profile with good reputation facilitating trust.

The reputation based model, while successful in practice, has a clear disadvantage regarding privacy: it incentivizes identity reuse.

One of the core ideas in RoboSats is to avoid identity reuse. This is achieved by facilitating avatar generation. By following the minimum effort route users are constantly creating new identities. Every time a user lands in the homepage, a new avatar is created. Extra effort is needed if the user wants to reuse an identity (yet it is possible by backing up the user token and inserting it once again).

RoboSats trust model relies solely on the fidelity bond system (bonds of misbehaving users are slashed). This is why users can expect counterparts to not cheat. It is however unclear whether liquidity will grow in a market that does not allow liquidity providers to build reputation.

As of now, it might be best to have a reputation system in place, and let users decide whether that is important for them or not. Indeed, it might get problematic if users start demanding other users to have a good profile (therefore, lowering their privacy practices). In the v0.1.0 MVP there is already an implemented reputation system, however the scores are not shown anywhere in the frontend.

Anecdotally, I myself have had trouble when starting to use a new p2p platform. Most makers limit their offers to users that do not have any previous trade. So one ends up taking a few small and pricey trades to start building a profile. The incentive to reuse the same identity is strong, and all trades from that point on are linked under the same username.

I think keeping an eye on this phenomena and steering away from it, while not damaging market liquidity, should be a priority for RoboSats.

[Kerbotanist]

So, let's say there were two layers, and one is is something like a RoboSatsTrustLedger value or score.

That is to say, a user could hold a persistent, but secret, ID, entitling them to generate new anonymous RoboSats ID's with a corresponding 'transactions satisfactorily completed' number, for example.

[chimp1984]

Interesting discussion!

I think one need to consider the context of the whole system. A Fiat exchange inherits the terribly bad privacy from bank transfers (if not using face to face trades). As one can never know if the counterparty is not collecting/leaking your data the foundation for privacy is already pretty bad. To try to build super sophisticated privacy on an already broken base foundation would be rather "privacy theatre" and could even be dangerous by giving wrong expectations. Bitcoins weak privacy add more to that bad situation - though with LN it's likely better, but have not investigated enough to be sure it does actually add privacy and not only obfuscate it for humans (but not for chain analysis algorithms).

[Kerbotanist]

Okay right, what was trying to say was: what is a practical way to implement a reputation system that does not violate privacy? What came to mind is like a one-way function where successful trades accrue a reputation score to a user's account, but that account is secret. However, the score can be expressed when creating new anonymous accounts. Sort of like digital signing. The existence of the reputation layer would let people evaluate the trustworthiness of the other party without knowing their identity.

So the reputation layer would have to be a separate ledger, where a transaction in the coin layer would give each party the opportunity to generate a 'successful transaction token', so to speak, on the reputation layer, creditable to the other party's rep score. That rep score would have no function other than to allow the holder to generate RoboSats avatars that were provably signed by someone with a reputation that was expressed as part of the RoboID.

Thinking about it again, where this falls down is, anyone could game such a system by trading with themself on another account, in order to artificially inflate their reputation. But then I guess that is actually true of any reputation score that does not expose the details of transactions comprising the score.

Edit: so I just realized that I'm retarded, or at least I had too much rum last night when I was first reading this.

It looks like you already have everything in place for rep score and persistent accounts, and there is no need to try to make any of that decentralized, which makes keeping reputation data in a distributed ledger, etc. completely irrelevant. Sorry.

Simplified version of what I was attempting to suggest: A user could have a persistent account, with reputation, which would be used to generate a new avatar for each transaction, and the avatar would carry the reputation score of the persistent account.

Then the issue would be to what extent could the reputation system itself act as an identifier? For example, a simple cumulative rating like 4 stars out of five would be fairly anonymous, but not very useful. On the other hand, even exposing total number of ratings could be completely identifiable data for someone with a lot of transactions.

So this is a very interesting question, to what extent is it possible to present reputation data in a way that sufficiently describes trustworthiness while preserving anonymity?

Anyway -- This project is badass! Saw it on reddit and I was blown away by the enterprising spirit.

[chimp1984]

Decentralized privacy protecting reputation systems are a holy grail nobody has cracked as far I am aware. Maybe some zero knowledge proof magic enables new avenues?
Another approach is to piggyback on existing systems which are already part of the system (e.g. bank accounts) and use that in a specific context to gain some additional security properties (as done in Bisq with the account age signing system).

[dbolser]

Actually, this is a good use case to pitch an idea I've been thinking about for a while... Anonymous reputation. Sounds counter intuitive, but you could have 'reputation bonds' like Chaumian eCash issued by the platform.

It's like a certificate that you can use to prove your reputation without revealing your identity

When you log in to a new profile, the site could ask you to upload your reputation certificate. Even the site wouldn't know who you are (k-anonymity not withstanding)

reputation could even be transferable between sites...

Disclaimer: I'm not an expert either. It uses the concept of 'blind signatures', it relies on the fact that in some signing schemes, the encrypted signature of the plain text is a valid signature of the encrypted text. e.g. the sig is valid before and after encryption. The site issues a signed certificate of reputation (e.g. after completing a trade) and gives it to me. I can then encrypt that certificate and give it back to the site at some point. The site can't read the certificate, but can see a valid signature, e.g. yup, this is good for 1 reputation token and it was issued by us. Beyond that you don't know anything... At least that's how I think it works

I get it. Sounds like a sort of DID. I see how that is very useful for cross-site reputation. Unsure what the use case is if implemented for RoboSats only. For example, the fact that you have "37 reputation points", might be enough to identify you across many robot identities.

[chimp1984]

@dbolser Sounds like a feasible idea. Can you try to sketch it out in more details to see it the idea really holds?

[cointastical]

What outcome would be the result of the following?

A Dispute is Opened by the seller.

Both Buyer and Seller provide screen shots of the chat.
Seller's screen shot of the chat shows payment instruction "Send to Zelle account: [email protected]".
Buyer provides a screen shot from the chat that shows "Send to Zelle account: [email protected]", along with screen shot of the Zelle transaction (and corresponding e-mail from Zelle).

How does the dispute mediator decide?

It's trivial for either party to edit the DOM for the chat and take a screen shot of it. In the above example, the Seller could have been the one that changed the payment instruction (for purposes of the dispute), to show AliceTheWhale. It could be just as likely that the Buyer change the payment instruction, to show EvaTheTrickster.

Even if using PGP, this can still occur. There's no way for the mediator to know which of two countering claims is the truth.

I think that is one of the reasons Bisq dispute resolution includes the last-resort option of requiring ID. Adding that requirement with RoboSats (only for disputes which cannot otherwise be resolved) makes it so that the scam would only succeed once for that one scammer. This would only occur once, as the second time the scammer would attempt this:

• The dispute mediator would see that there was a previous dispute involving that party (using the ID required during both "otherwise un-resolvable" disputes)
• This second dispute would have similar circumstances to the earlier dispute (where it was claimed that the payment instructions differ from those that the counterparty claims)
• The mediator would then almost certainly have to resolve the dispute in favor of the counterparty (where there never had been such a claim in their reputation / trust history for that person -- again, something that could be determined only after doing ID verification as a last-resort for this "otherwise un-resolvable" dispute)

So it is kind of like a reputation model but one that is quite limited as it only starts (or gets added to) when the trader is party to a trade that goes into dispute and no other resolution could be found (i.e., a rare occurrence).

[dbolser]

@dbolser Sounds like a feasible idea. Can you try to sketch it out in more details to see it the idea really holds?

I'm honestly not sure...

Perhaps something along the lines of the site issuing your reputation token to a bitcoin address, then when you connect to the site you digitally attest to as many tokens of reputation as you like.

The way this works in detail with blind signatures or Chaumian eCash isn't something I know in detail, but I know it's not that weird (cryptographically).

Shame there is nothing like metamask for bitcoin that integrates really well with the browser... LN mask?

[dbolser]

@dbolser Sounds like a feasible idea. Can you try to sketch it out in more details to see it the idea really holds?

Heh... I just found this: https://www.cs.columbia.edu/~smb/papers/anonrep.pdf

Misbehavior is one of the biggest problems in pseudonymous P2P systems, where there is little incentive for proper behavior. In our scheme, using ecash for reputation points ...

[chimp1984]

@dbolser Sounds like a feasible idea. Can you try to sketch it out in more details to see it the idea really holds?

Heh... I just found this: https://www.cs.columbia.edu/~smb/papers/anonrep.pdf

Misbehavior is one of the biggest problems in pseudonymous P2P systems, where there is little incentive for proper behavior. In our scheme, using ecash for reputation points ...

Ah thanks for the link!

Negative reputation might be easier to handle. And privacy concerns can be dropped for certain levels of bad behaviour. E.g. if used only in clear contract breaches (scam attempts) privacy can be ignored at all (no need to protect scammers privacy).

There have been some discussions about it for Bisq:
bisq-network/proposals#260

Bisq uses a concept called "account age witness" which could be used for that as ID.
But a hash of the most relevant bank account data (e.g. SEPA account number) could be used as well. Only scammers get that negative score issued, so they lose some level of privacy (one need to know the SEPA number to match to the hash). This would render a bank account un-usable for further trading. The options to open new bank accounts is limited, at least for professional/serial scammers its not a feasible option. Some one-time scammers might get around with it but those do not pose a systemic risk.

But all that would require to have the bank account set up in the app and not only be part of a chat message.

[dbolser]

Strong disagree. Privacy should not be sacrificed.

[chimp1984]

Strong disagree. Privacy should not be sacrificed.

So you prefer to protect scammers? The real issue with the proposal IMO is the centralisation power of the arbitrator who can effectively ban users by applying a negative score.
But the positive side is that is relatively easy to implement and a feasible concept. All the other ideas about decentralized reputation systems are kind of vaporware, and so far nobody has developed one. Open Bazaar had a researcher paid and never got out a result. Its a hard problem. But would be great if you figure out a solution. Blind signatures might be a path, but it might end up developing a privacy coin.

[dbolser]

Strong disagree. Privacy should not be sacrificed.

So you prefer to protect scammers?

Of course. Are you tripping? Where have you been the last 13 years? I know, let's blacklist bitcoin addresses... Only for scammers of course...

Anonymous means anonymous. Most people are not scammers. Prevent Cybil and we're golden.

The real issue with the proposal IMO is the centralisation power of the arbitrator who can effectively ban users by applying a negative score.

You don't seem to understand the proposal / concept of 'anonymous reputation' / are talking about something other than my proposal.

But the positive side is that is relatively easy to implement and a feasible concept. All the other ideas about decentralized reputation systems are kind of vaporware, and so far nobody has developed one. Open Bazaar had a researcher paid and never got out a result. Its a hard problem. But would be great if you figure out a solution. Blind signatures might be a path, but it might end up developing a privacy coin.

The only good thing about a 'coin' is that it promotes standardisation and interoperability. There are so many bad things about making a coin, I don't think it's worth it. Standards are hard, but that's what the W3C is for.

Thanks for comments, sorry I'm toxic.

[Reckless-Satoshi]

The discussion here is being really interesting (though a bit all over the place :D)

I will just give my thoughts, because I see some of you guys are falling for a false dilemma here: either a reputation model is implemented or we are allowing scammers. This is totally not the case! We have a fidelity bond system for a reason. The best trust/dispute/reputation model system is the one that prevents any misbehavior in the first place.

Anyone who knows math won't try to cheat. This is the current setup as a cheater:

You risk 1% (can be raised) of trade_amount. Best case, you are an excellent cheater and you trick the staff into being unable to resolve the dispute. The fallback for unresolvable disputes is a 50/50 split of the funds. Therefore, you must be confident that you can trick the staff at least 2% (more if it is raised) of your attempts at cheating, at least so you come out even bitcoin-wise. This is probably close to a true number, yet you still need to account for the cost/work of going through this whole exercise as a cheater: a cheater will very likely come out net negative. This is mostly true because amounts in RoboSats are very small and winning a dispute requires a lot of proof of work (record videos, etc). Cannot be compared to Bisq where a cheater is aiming for big hits.

The numbers above (default bond size %) can be adjusted in a smart way as we get more data about disputes and what is the rate of unresolvable disputes (none so far). In addition, makers will soon be able to specify the bond sizes, see pull request #76 .

A quick thought on other fancy ideas. I would discard all the fancy decentralized privacy stuff. Robosats is technically a "smart lightning node" that allows conditional routing. Now, who is going to enter the data about past trading activity into whatever decentralized system... robosats' server? how do you know there isn't a copy of it in the server? I do not see how this could work. I wish a magical solution existed... it is out of the scope of this project, we do not have the resources to chase unicorns ;)

Best way to protect private data (e.g. how many trades someone made) is by it not existing, anywhere, period. Why would we want to break the "one identity = one trade" that makes robosats so awesome? I only see a very very limited reputation model being implemented if the market fails to grow as it is right now. Then some small tradeoff will have to be made, but I am hopeful!

[chimp1984]

Good luck. I leave that discussion.
Not interested in getting insulted by ppl (@dbolser) who have never built anything in that area, don't gety the problem space and are not able to have a cultivated discussion.

[Reckless-Satoshi]

Not interested in getting insulted by ppl (@dbolser) who have never built anything in that area, don't gety the problem space and are not able to have a cultivated discussion.

@dbolser and @chimp1984 can we all be robo-adults and be friends please? :) We need everyone's contribution here. Too precious to be lost because of some bad mood.

Guys, I don't want to lose time implementing a Code of Conduct :)

[dbolser]

If there is no code of conduct I quit!

Don't you know how quickly I'll start making rape jokes unless you explicitly ban them! (And I'm against rape!)

Seriously though, I agree @Reckless-Satoshi.

The idea is sound I think, but is out of scope. Can't resist one last point though:

who is going to enter the data about past trading activity into whatever decentralized system... robosats' server? how do you know there isn't a copy of it in the server? I

It's literally Chaumian eCash, 'anonymous reputation' is burned on every trade and re-issued (+1) if a trade goes well.

Anyway, I'm off to rage quit, because scammers are nasty people.

[Reckless-Satoshi]

Anyway, I'm off to rage quit, because scammers are nasty people.

Haha, I appreciate it :D (scammers don't....)

It's literally Chaumian eCash, 'anonymous reputation' is burned on every trade and re-issued (+1) if a trade goes well.

I think there is something I did not understand. Who/what is in charge of burning the reputation and re-issuing it?

[dbolser]

As you say, it would be the RoboSats server. The server signs a message that represents 1 reputation token and sends it to the user (perhaps in the form of a QR code?). Now there is a bit of missing tech (browser plugn or app) whereby the user encrypts the signed message and stores it somewhere. When the user creates a new identity, there is an option to 'deposit trust tokens' when creating an offer. They use the app to somehow do that. They can select exactly how much trust to slap on the offer. RoboSats has no idea where that trust came from, but you know that you issued it at some point. That trust is now revoked by RoboSats... Hmm... that is different from burning isn't it... Hmm... let me think... perhaps I got it wrong! Perhaps you would need to track revoked trust tokens I'm not sure. Anyway that's the idea roughly... if the user 'burns' 10 trust tokens on an offer, they get 11 in return if it goes well... I guess this doesn't stop Cybil attacks after all :-/ Meh... yeah... slash! Fun to think about, but I don't see how this can work now! Cheers,

…

On Wed, 16 Mar 2022 at 14:51, Reckless_Satoshi ***@***.***> wrote: Anyway, I'm off to rage quit, because scammers are nasty people. Haha, I appreciate it :D (scammers don't....) It's literally Chaumian eCash, 'anonymous reputation' is burned on every trade and re-issued (+1) if a trade goes well. I think there is something I did not understand. Who/what is in charge of burning the reputation and re-issuing it? — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7NEYDK5HGNWJRHX7A7LLVAHYPTANCNFSM5NESW5LA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>