[bisq-network/bisq] User can set custom tx fee to override FeeService estimated fee (#4231)

Chris Beams notifications at github.com
Thu May 7 07:56:11 UTC 2020

> @cbeams I understand that your argument applies to offer-taking, but what about offer-making [...]?

Offer making is a different story as it's theoretically only the maker's problem, and they're not externalizing anything on their counterparty, but as @sqrrm mentions, in practice it's probably still going to land in support. Supporting RBF (replace-by-fee) in Bisq would help solve this as it would allow makers to self-serve solving the problem. And there's nothing we can do in support to help them anyway. We would have to be very clear that in the UI that changing the recommended transaction fee is to be done at the users' risk, that there's nothing we can do to help their transaction if it's stuck, etc. Would need to think about how offer publication happens as well. I think right now, the offer gets published to the offer book and becomes visible even before the first confirmation occurs. We wouldn't want that to be the case if this change were made, because again an unwitting taker could get hurt for no fault of their own if the maker fee tx gets stuck.

> what about [...] proposals?

This would be less risky to allow it here. It's fully the problem of the proposer if the tx gets stuck, and we could be clear that there is no recourse for this, just do it at your own risk.


With the above said, I don't see this as a priority now that we've solved the problem of too-high fee rate recommendations out of earn.com with @cd2357's PR at https://github.com/bisq-network/projects/issues/27.

As far as I'm aware, users haven't been complaining about the tx fee rate in Bisq except during a couple incidents where rates were way too high and got stuck there. This happened in 2017, just recently, and IIRC there was one other time too. If the new mempool.space service proves reliable in producing reasonable estimates, my preference would be to leave this area alone for now, and not add more complexity and risk leading to potentially more support incidents and poor user experiences.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200507/b005aadd/attachment.html>

More information about the bisq-github mailing list