-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve fee estimation #1077
Comments
Besides optimizing the fee adjustments, we should also add the information within the trading process of the expected confirmation time to reduce the number of disputes opened. |
I use https://jochen-hoenicke.de/queue/#2h I enter manually 300 200 140 or 100 depending on the chart - works for me. Now it would be 300. |
@montvid based on what do you take 300? You just take the 'second most expensive' fee interval from that page? |
500 - 300 tx 300 - 15000 tx 200 - 25000 tx so i choose the best for me. If I want to wait i choose 200 if i want it quite fast i choose 300 if i want instant i can do earn.com or 500. |
Here you can see our current fees: http://37.139.14.34:8080/getFees |
I don't know from where are you getting litecoin fees ""ltcTxFee": 500" but they are the minimum 0.001ltc/kb and will be in the future (from 0.16 the devs say it could be 0.0001ltc/kb) as the blocks are never full always half empty. Litecoin blocks are capable 2.5min/1mb so 10min/4mb - with segwit almost 10min/8mb. I was saying we could use discovery how many transactions are in what range of satoshi as earn.com or https://jochen-hoenicke.de/queue/#2h and make our own conclusions as to what fee is optimal. How to automate that I don't know but I never use the earn.com recommended price as it is too big - I decide from the charts a more optimal price. of course there is the bitcoin core client algorithm to predict fees but i don't think it is very accurate too. Good luck! |
See here for litecoin block space info https://chain.so/ltc |
Of interest from an article posted today: https://coinjournal.net/charlie-lee-wants-test-new-solution-bitcoin-fee-estimation-litecoin/
|
A good fee estimate is important, but we should also be able to use RBF to increase fee if the "mempool landscape" changes, as it were. If this is a bounty, would you make #1139 a bounty, as well? I would claim this bounty, but do so via #1139, ensuring that Bech32 (P2WKPH) and RBF are both covered by bitcoinj, if necessary. Fees would be lowered significantly via SegWit already. Then we could use a relatively-low initial fee estimate (or better yet, give the users a simple slider to choose between a 25-block and next-block estimate) and just increase it later. |
Yes, all of this stuff is bounty potential. Please come join us in Slack where we can discuss this and related work in more detail. https://bisq.network/slack-invite. |
I want to suggest using a bitcoin node with a limited mempool to estimate fees. The mempool holds the highest fee/fastest to confirm transactions first. Let's say the mempool is 10 or 20 MB so the node would report what is the minimum fee to get into the 10 MB mempool thereby predicting the tx cost in realtime like https://dedi.jochen-hoenicke.de/queue/#2h (see Mempool size in MB and Unconfirmed tx count) |
There are 2 dev working on better fee estimation (met them in 34c3). Can anyone contact them and check out possibilities to use their service? Felix at least told me that he has his service open source and should be out mid January. |
The guys behind that page seem to be other good candidates: https://b10c.me/ |
Electrum announced mempool based fee estimation: |
Unfortunately there is no big use in that if bisq fee setting is broken now #1325 but looking bright in the future! |
@montvid Your bug report is the only I am aware of. Fee calculation basically works but seems some edge cases are not covered correctly (your report). |
David Vorick's idea: https://gist.github.com/DavidVorick/ba17fb7db50b9270d1c2131ff425422b |
I just had a conversation with Felix Weiss and he told me he does not have time to help us. The API is still not public but we can use that url: https://whatthefee.io/data.json curl https://whatthefee.io/data.json To get to satoshi/byte just calculate exp(feelvl/100), e.g. exp(300/100) = 20.8. He will update us if the format changes. Any dev want to work on that? It is not lot of work, just a request, parsing the json and making that sanity check. I suggest a bounty of 1000 BSQ for that. |
@ManfredKarrer |
Yes. But its is pretty simple. |
I'll give it a look. |
Please study the design of the relevant pricenode code, particularly |
yet another fee estimator, looks well thought out, leaving it here for reference: https://bitcoiner.live/ |
Hi, developer of bitcoiner.live here. |
@bitbug42 Ah great thanks! |
For DAO transactions there's little reason to use the same values used in the trade's transactions. A better solution seems to be to use instead the custom value that we can set for withdraws. |
My self-hosted mempool fee estimation API service is now live at http://xxh4i4lbbrh6mzy2.onion/api/v1/fees/recommended After a few more btcnode operators start this service as well, I will make a PR to add those hostnames to the pricenode code and remove earn's API. The API functionality should be the same. |
looks good wiz, where can I find the source for this? |
@mrosseel I think if we all self-host we'll be good, but let's discuss in #btcnode channel on keybase |
My self-hosted mempool fee estimation API service is up at |
Created a project for this bisq-network/projects#27 |
Have you considered using the estimatesmartfee call from Bitcoin Core? |
Fixed by bisq-network/projects#27 |
As we have seen in the recent spam attack and blockchain congestion the fee estimation is difficult to get right.
We use an API from https://bitcoinfees.earn.com but it was usually overpaid quite a lot. So we reduced a while back to get more to an optimum. That worked pretty well until recently when in 1 or 2 days the mempool grew from 20k to 200k unconfirmed transactions. That rapid rise was not handled well by the current model.
One reason was the average function. We used the average of the last hour, which kicked us always to the lower end and with rising fees the chance to get those txs confirmed decreased.
We changed now to more aggressive and expensive fees (lower max blocks param and only last 10 min taken for average) but I think that will lead to overpay again. Why we should pay the Bitmain and co more as absolutely needed? They do a great disservice for Bitcoin since long and it really hurts to pay them extra. So we should find a way to get back to the min. fee required to get the tx confirmed in < 3 blocks.
We could manually adjust the parameters and once we observe mempool getting filled up we have to be more aggressive again. But that manual adjustment is not a good solution of course.
So we should find a way how to influence the parameters based on those observations we would do manually, namely the size of the mempool as well the dynamics (fast rise or more organic behavior).
First approach could be to simply request the mempool size and use that as influence for adjusting our parameters.
Anyone who is expert in that field would be very welcome to give input. Alternative estimations services would be great as well as ear.com does not work well from my experience (e.g. I often observed the they suggest a high fee and I got txs with much less confirmed immediately).
io.bisq.provider.fee.providers.BtcFeesProvider is the class which implements our estimation.
It simply takes the maxDelay as param and adds the average function to not be too much exposed to spikes.
The text was updated successfully, but these errors were encountered: