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
Milestone
Comments
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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:
The text was updated successfully, but these errors were encountered: