Paying 10 sat/vB fees is wasteful on low fee days

[unbeaten69]

Description

Transaction fee used by Bisq for trading never seems to go below 10 sat/vB, even when less than half of that easily gets you into the top block...

curl -s --proxy socks5h://127.0.0.1:9050 http://devinpndvdwll4wiqcyq5e7itezmarg7rzicrvf6brzkwxdm374kmmyd.onion/getAllMarketPrices | jq ".bitcoinFeeInfo"

{
  "btcTxFee": 10,
  "btcMinTxFee": 2
}

I understand that it probably was implemented this was to save users problems when fees spike, but doesn't that problem come back anyway whenever fees hover above 10 sat/vB for a longer period of time?

[MwithM]

It's probably not worth changing the code as when it's done, mining fees could go over 10sat/vb.
But I agree that this measure is not as effective as we think when mining fees skyrocket, while in this rare situations where mining fees are lower than 10 sats/vb, it is wasteful.

[HenrikJannsen]

One has to consider the time delay between the take offer event and the publishing of the payout tx. The miner fee for the payout tx is defined at take offer time. In case the miner fee is very low at take offer time but rises much higher during the trade period (which can be 1 week in slow fiat payment methods or mediation disputes) there is risk that the payout tx never gets confirmed which causes extra effort to use a manual payout tx.
Dealing with miner fees is a pain and there is not perfect solution. But I think the problems with stuck transactions are much worse then the overpay in low-fee environments. As I guess we did not had much issues with stuck transactions even in the past month with crazy miner fee volatility, I think the current model is in a good shape and should not be changed without proper analysis and reason.

[snex]

It has been over a month since this issue was opened and fees are still well below 10 sat/vB. It would not have been wasteful to change the code a month ago and it would not be wasteful to change it now. When fees are over 10, competitive rates are chosen by the app. There is zero reason to not choose competitive rates when fees are below 10. Whatever problems in fee spikes you list have been around forever and will be around when fees are above 10.

[cparke2]

I think I found where the minimum transaction fee of 10 sats/vb is hardcoded in this source file for the Price Node:
https://github.com/bisq-network/bisq-pricenode/blob/main/src/main/java/bisq/price/mining/FeeRateProvider.java
The last change on that file was 2 years ago, when the minimum fee rate for withdrawals was halved from 2 sats/vb to 1 sat/vb, which is really really low! For trades, it was kept at 10.

I furthermore patched my local build of Bisq for testing purposes and made it to use a fee rate of 7 sats/vb on this BSQ & BTC combined transaction:
https://mempool.bisq.services/tx/3f66218b66d851166de2903649c8f485201ead84d1b862a4feac1b592aa6e5fe

As you can see, mempool found that fee rate to be optimal, and it worked fine and there were no issues getting transaction confirmations.

Now, I do understand then need for a min/max fee rate and get uncomfortable when the fee rate gets below 5 sats/vb that it could be a temporary anomaly and quickly become a "no priority" fee, causing the transaction to get stuck a long time. However, as the OP has noted, fee rates have been generally low for many months now, although they do spike up from time to time. Many Bisq transactions are being marked as overpaying 2x or 3x because of this hardcoded minimum.

So I don't see why halving the minimum fee rate to 5 should be a problem? I know the Bitcoin protocol does have a way to revise the fee rate on an unconfirmed transaction if it gets stuck, but if that happens to someone on Bisq, how does one actually increase it?

P.S. Why is this limit being set at the Price Node rather than as a configuration option in the client application?

[HenrikJannsen]

We have to separate that issue in 2 parts:

Normal transactions: Here it's totally up the user and a too low fee rate might lead to problems only affecting that user (also not completely true if that tx is a parent to a trade transaction).

Trade transactions: In case of a stuck transaction it affect not only the user but the trade peer and the Bisq DAO (extended support effort).

In case of sudden and sustained fee increase (as happened various times) a too low fee will cause the tx to get removed from mempool (each mempool have diff. policies based on memory consumption and resources). Usually after at least 2 weeks a tx gets removed if still not confirmed.

In such cases there are only few things a user can do:

• Boost the fee with RBF
• Use CPFP
• Pay miners out of band

The miner fee for the payout tx is set at take offer time. As with slow payment methods a trade could take several days or even 1-2 weeks, specially if a dispute arise, that is another risk factor. If the fees rise substantially between take-offer time and the payout tx, the payout tx could get stuck, and in case it would never get confirmed would lead to serious problems. If both traders are responsive and cooperative there are ways to republish that tx and add CPFP to boost fee rate, but if one trade has become unresponsive the trade would end up in arbitration and need to get reimbursed by the DAO, which causes costs to the Bisq DAO.

BitcoinJ which is used in Bisq does not support RBF to boost a tx, but even if so it would not help in case of the trade transactions. Furthermore a canceled tx (BitcoinJ registered the tx in the wallet but it never got confirmed) will require a restore from seed of the wallet, which, in case the wallet is old and has many transactions, can consume a lot of time and CPU (many hours at 100%).
If the user made multiple transactions/trades, the problem might get multiplied as all depending txs are affected as well.
If those issues happen, Bisq support get's very busy to try to help the users to either boost the tx with CPFP or assist then to restore their wallet.
And of course it affects both traders, that is why it is not fair to leave it to one trader as the potential costs for saving some satoshis will be paid by both traders (+ Bisq support).

A better strategy to optimize fee payment is to check if there are many utxo's and if so consolidate those at low fee rate times (normal tx where the user can set the fee). Then when doing a trade there will not be that many utxo's consumed, resulting in a smaller tx and lower fees.

The current fee rate has as far I am aware worked quite well even in volatile fee environments. I guess if we would have a 5 sat fee we would have face issues in the past year.

Why is this limit being set at the Price Node rather than as a configuration option in the client application?

In case we need to change it we can easier update the price node rather then to motivate all users to update to a new version. There are other tools we could use to dynamically push that value to users, but I think it was a historic relict then the price node was introduced to add a min/max and it had worked good enough...

As explained above trade fee cannot be considered a responsibility of the user alone IMO as it affects others as well, thus a user-specific setting is not appropriate.

[snex]

All of the arguments made by @HenrikJannsen apply when fees are above 10sat/vbyte - which they were for months straight. Bisq did not suffer catastrophic failure during that time. I don't see why it would suddenly fail if we could stop paying 10sat/vbyte minimums when fees are below that level.

[HenrikJannsen]

Fees can spike fast and as said we have to consider a 1-2 week window due the payout tx. If we allow a 5 sat fee and fees go quickly high its more likely that such txs get never confirmed. Its of course no hard science and also with 10 sat that can happen. But we have experience form the past, and as far I am aware with the 10 sat we did not run into that problem. So never change a running horse....

[cparke2]

Very interesting, thank you very much @HenrikJannsen for the background on this minimum tx fee rate.

There's multiple transactions in a Bisq trade, and security deposits and trade fee execute immediately at the time of making/taking. Same thing for BSQ swaps and other DAO activity. These don't seem to need the long-term protection of minimum fee rate that you've emphasized.

I'm not sure too why the mining fee for the future payout needs to be fixed at the time of taking. It really should be left as an open variable throughout the deal, determined only when BTC seller hits 'Payment Received' or accepts mediators proposal. Certainly for Bisq2 I hope we can do it that way.

@snex pointed out that the 10 sats/vb minimum offers no fee surge protection for Bisq whatsoever when the fee rate is already over 10, rather it's just worked out for the most part. If mining fee needs to stay fixed in Bisq1 at the time the offer is taken, I would think that it would be better if this was determined using a percentage markup (or premium) instead of just a minimum rate, to address the real concerns involved. However, if we did that, then we'd perhaps be fixing something that isn't broken, and the mining fee rate would go up for everyone, and even at low rates like we often have today, it's still going to be 10 or close to it usually.

[HenrikJannsen]

Yes, we could improve to use a different fee for the payout tx as that carries higher risk.

I'm not sure too why the mining fee for the future payout needs to be fixed at the time of taking.

Because the traders need to provide the funds for that in the deposit tx. An alternative would be that the buyer gets less BTC paid out if higher fee is required, but that would be bad UX and confusing to buyers.