Increase our mempool fee estimation from "medium" to "high" priority #4585
Conversation
Bisq currently uses the mempool.space API for fee estimation, selecting the "medium" priority fee, which generally works very well. However, if your timing is bad, sometimes the mempool can quickly fill up and your TX can get stuck for several hours or even days, which degrades the UX of Bisq. This PR changes the Pricenode code to always use "high" priority fees, which would at the time of writing use 99 sat/vB instead of 85 sat/vB, and hopefully prevent the above-mentioned issue from occuring. Of course if the mempool is empty the minimum fees would still be used, as this only changes the "priority" from medium to high. Fee estimates: https://mempool.space/ API endpoint: https://mempool.space/api/v1/fees/recommended
|
utACK |
|
utACK .. good call! |
|
utACK, seems reasonable, though I'm not sure how much of a problem this has been in practice. @m52go and I ran into this the other day while were recording a demo (had to wait many hours for a confirmation), but have @bisq-network/support-agents been hearing many complaints about this? It's probably worth doing because the difference in sats / overall dollar value isn't huge, but if it does become significant, people might start to balk. |
|
Might turn away new users who are trading 0.01 BTC or less, see #4575 The difference in fees between medium and high-prio can be small or large, depending on how the mempool distribution looks like at that moment. For example now, the high-prio fees are 5x the medium ones:
I agree, Maybe wait with this PR until segwit is live? Combined with lower tx size, the increased fee rate might have a minimal effect on the total mining fee paid per trade. |
|
utACK It might be a while until we have segwit for trades. I would think it better to increase the fees sooner as we're having issues right now. |
|
@cd2357 I'm sure everyone knows Bisq will eventually get priced out of the base layer Bitcoin blockchain, and obviously the $100 trades are already "priced out" in the sense they are not profitable if they cost $10 in fees. While we can optimize the amount of on-chain space used for a Bisq trade with Segwit or atomic trades etc., the only way to optimize the fees paid is to trade on the weekend, when fees are expensive we need to pay them or trades get stuck which causes a lot of real problems for users. Obviously the only real solution to this "high fee problem" is getting Bisq working on Layer 2 such as a sidechain like Liquid or a network like Lightning where fees can be kept low, in exchange for various security tradeoffs, but that is another discussion.... My motivation for this PR is because today I spent $10 in fees for my DAO voting and it was still not confirmed in time due to a sudden surge in mempool activity, presumably everyone withdrawing from BitMEX at the same time due to the news today. It can also happen due to mining variance when there are just no blocks for an hour or longer and the mempool gets backed up. |
|
Instant trades should pay high priority fees. Normal trades, I'm not sure what's best. |
Reverts bisq-network#4585, which increased Bisq to always use the "high" priority fee estimation. Now that we've improved mempool.space "medium" fee estimates in mempool/mempool@15bb5a96 and addressed the empty mempool issue as well, we can move Bisq back to using "medium", since always using "high" would be a bit wasteful at times.
Reverts bisq-network#4585, which increased Bisq to always use the "high" priority fee estimation. Now that we've improved mempool.space "medium" fee estimates in mempool/mempool@15bb5a96, we can move Bisq back to using "medium", since always using "high" will be too wasteful on the weekends when the mempool is empty
Bisq currently uses the mempool.space API for fee estimation, selecting
the "medium" priority fee, which generally works very well. However, if
your timing is bad, sometimes the mempool can quickly fill up and your
TX can get stuck for several hours or even days, which degrades the UX
of Bisq.
This PR changes the Pricenode code to always use "high" priority fees,
which would at the time of writing use 99 sat/vB instead of 85 sat/vB,
and hopefully prevent the above-mentioned issue from occuring. Of
course if the mempool is empty the minimum fees would still be used, as
this only changes the "priority" from medium to high.
Fee estimates: https://mempool.space/
API endpoint: https://mempool.space/api/v1/fees/recommended