Coinjoin fee structure - Coordinator pays the mining fee

[yahiheb]

It is clear that the current coinjoin fee model has a lot of limitations, specially in a high fee environment.

When the mempool spikes the users want to coinjoin less because of the high mining fee.
The main issue with the current model is that users have no way to influence the mining fee chosen by the coordinator that they themselves pay. If the coordinator selects a low fee their money is trapped. If it selects a high fee they pay for that blindly.
Any mistake in the coordinator's decision will have to be paid by the users, either by time or by money.

Since the coordinator is making the decision and it is incentivized to get the coinjoin confirmed then it makes sense for the coordinator to take responsibility of paying the coinjoin mining fee.
The users can/should pay a percentage of their inputs for each round they participate in as a coordination fee.

This can improve the UX for users a lot by making it somehow easier for them to calculate the cost of coinjoin even if it is higher than the current model because many users want clarity instead of some black box method, and it would allow them to coinjoin at any time regardless of the mining fee state.

That would allow us also to explore other ideas on how to deal with these fee spikes, like to pay miners off chain.

[yahiheb]

A example of a user turning off auto-coinjoin after realizing that mining fee costs them a lot of money.

https://www.reddit.com/r/WasabiWallet/comments/13531w3/comment/jka1beg/?utm_source=share&utm_medium=web2x&context=3

[MaxHillebrand]

CNACK, with mining fees so volatile, it is risky to offload the payment to the coordinator.

When mining fees are low, users will have to pay a huge coordinator fee which is all profit for the coordinator.

When mining fees are high, users pay the same high coordinator fee, but now the coordinator has to pay mining fee, meaning he's likely to have losses.

Also notice that now the coordinator has the incentive to low ball fee rates, because the less he pays, the more profit he makes.

Also notice that the mining fee depends not just on inputs, but also on outputs, so somehow the coordinator would have to charge fee for outputs too.

Mining fees are an inherently difficult topic, but I think the best way to solve this resource allocation problem is by everyone paying for what they use.

I think the solution is to make the client smarter with when to coinjoin, and for the coordinator to potentially offer multiple rounds at different fee rates.

[yahiheb]

When mining fees are low, users will have to pay a huge coordinator fee which is all profit for the coordinator.

What is wrong with that? If the users deem the service to be worth their sats then it doesn't matter how much the coordinator is making profit.

When mining fees are high, users pay the same high coordinator fee, but now the coordinator has to pay mining fee, meaning he's likely to have losses.

This balances out your first point when the fees were low and the coordinator was making more profit.

There should be a balance between the two cases for the this model to work fine from the coordinator's point of view.
But also think about the good UX for users who do not have to worry or care about the fees to decide whether to coinjoin or not, and who are currently losing time or money because of decisions made for them by the coordinator who doesn't lose much.

Also notice that now the coordinator has the incentive to low ball fee rates, because the less he pays, the more profit he makes.

That is not necessarily true, the coordinator is incentivized to have more coinjoins and to get them confirmed faster, when users are paying each round. Also the reputation and the quality of the service is at play here.

Also notice that the mining fee depends not just on inputs, but also on outputs, so somehow the coordinator would have to charge fee for outputs too.

Yes that should be taken into account when deciding what and how much users pay for the service.

Mining fees are an inherently difficult topic, but I think the best way to solve this resource allocation problem is by everyone paying for what they use.

I agree with that, but who pays what doesn't really matter if the model works from a business point of view and the users pay for the service that they get with all sovereignty and transparency.
I would say that the less hassle and the predictability of the costs and being truly in charge of what to pay and when is a very desirable outcome for users and justifies even an increase in the cost of the service.

[MaxHillebrand]

Think of it like this, if fee rates are 1000 sats/vByte, the coordinator would have to charge 10% or so to remain profitable.

Then if fee rates are 10 sats/vByte, the coordinator can provide the service at a 1% fee or so.

Should he now adjust the coordinator fee down? If yes, then we again have volatility in the total fee paid by the user. If no, then users pay an insane amount of fees eventhough the mempool is empty.

Yet another problem is, that the coordinator fee rate is a percentage point of sats amount, whereas mining fee is rate for a vByte size amount.

These two fees do not go well together, and that's why they are currently separate concepts, that's a good thing. Our current solution is better than any other, imho.

[yahiheb]

Think of it like this, if fee rates are 1000 sats/vByte, the coordinator would have to charge 10% or so to remain profitable.

The current system is not any better, if fee rates are 1000 sats/vByte then users would end up paying a lot in each round in mining fees which might be more than 10%.
Even worse users at such high fee rates won't be coinjoining so how can the coordinator be profitable??

Regardless of the mining fees issue, how could the coordinator be profitable if no new user coinjoin in the current model?

At the end of the day the users pay for a service and if it is useful to them then they will pay for it.
Some research/calculation should be made to determine what percentage should be charged in different scenario.

These two fees do not go well together, and that's why they are currently separate concepts, that's a good thing.

It is a good thing from the coordinator's point of view because it doesn't pay for the mining fees but the users do. Underpaying or overpaying doesn't harm the coordinator.

Our current solution is better than any other, imho.

We can explore different options. The current model cannot be better than any solution when we are clearly facing issues regarding mining fees, and to fix that we are adding more complexity on all levels to an already complex system.

[MaxHillebrand]

Fees are high, so blockspace demand is high, so there is no shortage of potential customers of the coordinator who are willing to pay the miner fee, because they must do an onchain transaction.

The blockspace cost can either be paid directly by the user, or indirectly by the user through the coordinator as middle man.

[yahiheb]

Fees are high, so blockspace demand is high, so there is no shortage of potential customers of the coordinator who are willing to pay the miner fee, because they must do an onchain transaction.

The blockspace demand is high does not mean that users want to coinjoin. We know for a fact that users coinjoin less when fees are high, and the above mentioned example supports that.

The blockspace cost can either be paid directly by the user, or indirectly by the user through the coordinator as middle man.

The users are now paying directly for a fee that the coordinator decides for them.

Imagine taking a taxi and the driver tells you:

Pay X for the service + Y for the gas/petrol which the driver decides for you. (our current fee model)
Pay Z for the service. (real world)

[MaxHillebrand]

The users are now paying directly for a fee that the coordinator decides for them.

A solution to this is the coordinator offers different fee rates in parallel rounds.

[yahiheb]

A solution to this is the coordinator offers different fee rates in parallel rounds.

I don't know how realistic is this solution or how it would work or affect the rounds by splitting the liquidity.

[Kruwed]

I don't know how realistic is this solution or how it would work or affect the rounds by splitting the liquidity.

#10615 describes a possible implementation of this solution.

[Kruwed]

The main issue with the current model is that users have no way to influence the mining fee chosen by the coordinator that they themselves pay. If the coordinator selects a low fee their money is trapped. If it selects a high fee they pay for that blindly. Any mistake in the coordinator's decision will have to be paid by the users, either by time or by money.

The solution for high fees chosen by the coordinator already exists in the form of the "Coinjoin time preference" setting which allows users to opt out. However, the problem of money getting trapped still exists since the coordinator's fee estimation does not react quickly when fees increase - (#12087)

The problem of paying fees blindly is "fixed" by #12131 but the issue of blind costs is ultimately built into the core functionality of the coinjoin feature: Since you don't choose your inputs or outputs for the coinjoin, you can incur costs several times higher in one coinjoin than another, with no option to fine tune the selection of many inputs or creation of many outputs.