You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
FixesWalletWasabi#12790
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: