bitcoinfees / bitcoin-feemodel

Bitcoin transaction fee modeling and estimation
https://bitcoinfees.github.io
MIT License
9 stars 2 forks source link

New mintxfee #4

Open OverlordQ opened 8 years ago

OverlordQ commented 8 years ago

Which 0.12.0 which has the new mempool code, would it make sense to drop the mintxfee minimum back to 1000 and then base it on mempoolminfee of a 300mb mempool??

bitcoinfees commented 8 years ago

Ah I didn't know the minrelaytxfee default was dropped back to 1000, thanks for letting me know.

You're right, in that by dropping the minrelaytxfee you'll be able to get estimates for fee rates lower than 5000.

To make the charts look nice however, minrelaytxfee should be set to the level at which the mempool queue is stable (i.e. the backlog gets cleared out regularly). Otherwise, the mempool size chart will be, for example, stuck at 300 MB all the time, and no longer useful as a quick gauge of how much backlog there is.

So currently it looks like the "stable fee rate" is less than 5000, but I'm not sure what it is exactly. I'll do some checks to see if it's safe to lower the minrelaytxfee.

OverlordQ commented 8 years ago

Wasn't meaning to set the chart fixed to 300 mb, but just use the 300mb mempool size to regulate mempoolminfee.

bitcoinfees commented 8 years ago

Sorry then I must have misunderstood you. What do you mean by using the 300mb size to regulate the min fee?

OverlordQ commented 8 years ago

They changed the mempool in 0.12.0 to not have an unlimited size anymore. By default it's fixed to 300mb. When a new transaction comes in, if there's room in the mempool, it accepts it. If the mempool is full, it looks at the fee the new transaction pays, and the lowest-paying transaction in the mempool. If the new one is greater, it chucks out the old transaction and inserts the new one. It then adjusts the mempoolminfee to track how much any new transactions need to pay to get accepted into the mempool.

EG: right now my bitcoind is thus:

$ bitcoin-cli getmempoolinfo
{
  "size": 22334,
  "bytes": 304845384,
  "usage": 654992736,
  "maxmempool": 800000000,
  "mempoolminfee": 0.00000000
}

Since there's room in the pool still there's no minimum. But once it fills up, it'll start creeping up like:

$ bitcoin-cli getmempoolinfo
{
  "size": 18624,
  "bytes": 137991214,
  "usage": 299990688,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00002013
}

So in this case, if the fee isn't over 2013 satoshis, that node wouldn't accept the transaction. So now you're not only dealing with the minrelaytxfee, but also what the mempoolminfee is. So it might be helpful to graph that information as well.

bitcoinfees commented 8 years ago

Ah, I see -maxmempool is the memory usage, not the serialized size of mempool txs.

But then your mempool still contains > 100 MB of txs, whereas mine is regularly cleared to zero, at a minrelaytxfee of 5000. Even if you knew the mempool min fee was 2013, is it practical to pay such a low fee though? You would have 100 MB of txs ahead of you in the queue, and the time to confirmation would be quite unpredictable.

It would be nice to know the mempoolminfee based on the 300MB limit, but it seems to be not relevant to the task at hand, which is to estimate fees for confirmations in < 60 min.

Am I understanding your proposal better now?