Local prison should have an invalidation mechanism about walletwasabi HOT 12 CLOSED

With #11958 merged and released, we made a quick fix for this issue.

Should we proceed with one of the ideas?

If yes, which one?

If no, then I think we can close this issue.

from walletwasabi.

Should we proceed with one of the ideas?

from walletwasabi.

proposal: change how often the client attempts to register a banned coin from 2 days to 2 weeks.

from walletwasabi.

According to the title Local prison should have an invalidation mechanism this is done.

One more thing remained to mitigate the suboptimal coinselection. @adamPetho will create a separate issue for that.

from walletwasabi.

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.

I am catching up on this, I was abroad at this time - sorry for the confusion. Local invalidation is a good solution on the client side. What happens after that? The client tries to register and finds out there are banned coins, which leads to suboptimal coin selection.

There is a simple naive solution for that. 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. If it is too late to leave, then proceed with the round (rare case).

WDYT?

from walletwasabi.

For me this solution is also the best, as it's a proper fix and doesn't introduce much complexity. I like the idea of filters etc and it might be more convenient for integrations but I don't feel an absolute urge and need to have it. For Wasabi clients, waiting 2-4 days in case we ban incorrectly is not really a big deal as it doesn't really happen often.

It's a bit implementation detail, but something to consider:
I have 10 coins banned for 1 week. After some day, I try to register them again, all at once.
If we implement this solution, and don't continue with registering the coins, we will need 10 successive rounds that we unregister from to get rid of this incorrect information, as we will do 1 by 1.

So we have to choose between:

• Do 1 by 1 -> drawback: time, UX
• 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

from walletwasabi.

I vote for the second option.

from walletwasabi.

If no one else wants to vote on this, then I will start to figure out how to implement the second option.

Altho, I'm not a fan of choosing a solution with privacy drawbacks over UX drawbacks...

from walletwasabi.

Well there is a complex solution. The client has a set of coins to register into the coinjoin. It starts registering one by one. If at least one coin is banned we set a flag.

If the flag is set we just register the coins but we never confirm, so coins will time out in input reg phase. Before the input reg ends we bail out and remember the banned coins.

The solution has no drawback except that it is complex...

from walletwasabi.

@adamPetho please change the parameter to 2 weeks.

from walletwasabi.

@adamPetho please change the parameter to 2 weeks.

Why?
Didn't this discussion happen last week?

from walletwasabi.

You know I could also change the title. Closing issue for the sake of closing issues is ridiculous, this is not fixed.

from walletwasabi.