Trying to understand Feerates

[barrybecker4]

I'm trying to understand the code in fr.acinq.eclair.blockchain.fee. I've searched the internet to try and get some background, but haven't found too much. Also some things, like weighting, seem to be changing over time.

First, some things that I have come to understand from external sources. Hopefully, these statements are correct.

• The transaction fee doesn't depend on the amount being transferred. It depends on the amount of data being transferred.
• The size of a block is limited to 4,000,000 weight units which corresponds to 1,000,000 virtual bytes.
• When space on a block is tight, there is competition for space, so transactions with higher fees get preference.

Now some questions about things I don't understand based on the code.

1. The reference.conf, which is loaded in Setup.scala defines default-feerates in terms of sats per kb per target block as a step function. What are target blocks? Do they somehow relate to the space available? Should I intuitively interpret this as fees are less when there is more space available? Are target blocks the same as block targets?
2. Is there any special significance to the thresholds of 1, 2, 6, 12, 36, 72, 144, 1008? How high could the block values go? Would it be a good idea to encapsulate these values in an enum instead of repeating them in variables in the different fee providers?
3. What is the purpose of the SmoothRateProvider? It seems to be providing a moving average of FeeRatesPerKb over time. Are these FeeRates volatile and change significantly over time? Why do they change and why is it important that they change smoothly?
4. Why are the FeeProviders regular classes instead of case classes? Since they are immutable (as far as I can tell), would it not be slightly better to have them be case classes?

[DerEwige]

Eclair needs to connect to a bitcoin core.

Bitcoin core knows the history of the blocks and how many transactions are in the mempool.
Based on those information bitcoin core can make estimations (educated guesses) about the minimum fee required to be included in the next X blocks.

Different kind of transactions eclair wants to make are more or less important.
For example if a peer wants to cheat you have to publish a punishment transaction with very high priority.

So the target will be to be included in the next block.
If you open a channel, this might wait a bit, so the target is to include it in the next 6 blocks.

To figure out how hight the fee should be, eclair just asks bitcoin core for the fee estimation for the target amount of blocks.

Do they somehow relate to the space available? Should I intuitively interpret this as fees are less when there is more space available? Are target blocks the same as block targets?

Fees are less when there are less transactions waiting in the mempool to be included.

Is there any special significance to the thresholds of 1, 2, 6, 12, 36, 72, 144, 1008? How high could the block values go? Would it be a good idea to encapsulate these values in an enum instead of repeating them in variables in the different fee providers?

The only significance about 1, 2, 6, 12, 36, 72, 144, 1008 blocks is:
10 minutes, 20 minutes, 1 hour, 2 hours, 6 hours, 12 hours, 1 day, 1 week.
This is the time eclair expects this transaction to take to be included into a block.

What is the purpose of the SmoothRateProvider? It seems to be providing a moving average of FeeRatesPerKb over time. Are these FeeRates volatile and change significantly over time? Why do they change and why is it important that they change smoothly?

Yes fee estimations can jump around quite a lot and you don’t want to overpay by a lot, as that would drive up overall fees for everyone.

[barrybecker4]

OK. Thanks. I understood some of that.
The mempool contains pending transactions. Fewer pending transactions means lower fees.
I didn't see anything about cheating/punishing transactions or the understand details of that scenario.
I think it would be good to capture the relation between blocks and timing in the code - I was thinking an enum.