Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Sub-optimal coin selection when one of the coin is banned by the backend #12790

Open
adamPetho opened this issue Apr 9, 2024 · 0 comments · May be fixed by #12967
Open

Sub-optimal coin selection when one of the coin is banned by the backend #12790

adamPetho opened this issue Apr 9, 2024 · 0 comments · May be fixed by #12967
Assignees
Milestone

Comments

@adamPetho
Copy link
Collaborator

adamPetho commented Apr 9, 2024

This issue is created to collect ideas, solutions and concerns.

Extracted ideas from: #11910

General Description

When one (or more) out of the selected coin candidates are banned, we remove the banned coins and continue with the CJ with the rest.
While this is good for time-efficiency, BUT it results in a sub-optimal coin selection for the round.

All solutions have trade-offs, and finding a good one is challenging because it has to respect both:

  • Privacy: (malicious) coordinator shouldn't be able to have extra clues on common ownership, banning information shouldn't be publicly available...
  • Integrations: It must be helpful for other software, not only Wasabi.

Backend Solutions

Filters for ownership proofs in Prison

This solution is proposed and described here: #10700 (comment). It has the caveats of potentially harming privacy, as any active observer could know that a coin is in Prison at a given time, considering that the ownership proofs are made public during the round.

Endpoint

An endpoint that the clients call with the ownership proof of one random coin that is supposed to be banned for a round. The endpoint gives back the actual banning information. The whole cache is invalidated if the information received differs from locally cached information. I believe that this idea is the most interesting.

Same without endpoint

It is the same as the previous solution, except this process is done directly when registering inputs. This has the caveat of making a bad input selection if the coin is still banned.

Client-side Solution

Leave round if banned coin is detected

If the client detects there is a banned coin in the selection - it will just stop registering and leave the round by letting it's inputs timeout. The implementation is already done for leaving a round without privacy loss.

We have to choose between:

  • Do 1 by 1 -> drawback: time, UX, many rounds needed to detect all of my banned coins.
  • If we detect a banned coin in the selection, keep trying to register the selection to detect the other banned coins, then unregister all -> drawback: privacy
@MaxHillebrand MaxHillebrand added this to the v2.0.8 milestone Apr 15, 2024
csiki2 added a commit to csiki2/WalletWasabi that referenced this issue Apr 29, 2024
Moving the RegisterInputAsync function from the method.
Contributes to zkSNACKs#12790 (comment)
csiki2 added a commit to csiki2/WalletWasabi that referenced this issue May 2, 2024
If the client has a banned coin then it does not finish the coin connection confirmation.
It won't participate in the next phase, but checks the coins whether they are banned or not.

Fixes zkSNACKs#12790
@csiki2 csiki2 linked a pull request May 2, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✋Will Do
Development

Successfully merging a pull request may close this issue.

3 participants