Lower the default relay fee, create a fee estimation algorithm

[ShadowOfHarbringer]

@freetrader

That’s an opinion mixed with what looks like a genetic fallacy (“becomes it came from Core, it must be devoid of sense”).

Actually I meant it was devoid of sense regardless, not because it came from Core.

I am here for a very long time and I remember Coin Days Destroyed working splendidly in 2015 and before. I did not even know it got removed before this discussion.

Removal of CCDs was dumb, regardless whether Core did it or somebody else did it. But surely it all comes together and makes exponentially more sense when you add that Core wanted to destroy on-chain transactions and this was their hidden goal all along.

@freetrader

I’m not sure that’s true, it may be more an impression you got?

Well, so far I think that Tom Zander, you, Calin, mtrycz and somebody else agreed that CCDs need come back.

Maybe I overexxgerated a little with “strongly” agreeing (I do that for more dramatic effect like Filmmakers add CGI effects in their movies because otherwise long discussions get boring), but generally yes, we almost universally agreed that CCD needs to come back in some form.

[freetrader]

@ShadowOfHarbringer

I did not even know it got removed before this discussion.

This is how small it’s impact on usage is. You didn’t even notice for 2+ years that someone removed it. And you ARE a person who transacts on the network, I know that. So this is more an indication that it’s not a significant thing.

[ShadowOfHarbringer]

@freetrader

You didn’t even notice for 2+ years that someone removed it.

Uh.

I did not notice it, because I stopped using BTC after 2017. And in BCH congestion/high fees were never a problem so CDDs were (initially) not needed.

I did notice it disappearing from charts on blockchain.info (and others) though and always was wondering why did it disappear.

Well now I know.

[freetrader]

@ShadowOfHarbringer

And in BCH congestion/high fees were never a problem so CDDs were (initially) not needed.

So this makes no sense to me as an argument for reintroducing it.

The whole point is to keep congestion / high fees from happening, if CDD’s only use is in that situation, it is effectively of no use on BCH.

I’m not saying that it might not have some use (in fact I played devil’s advocate for it yesterday on BCHN’s telegram-bridge) but I think this discussion belongs in a separate thread to explore exactly what those uses are.

I did notice it disappearing from charts on blockchain.info (and others) though and always was wondering why did it disappear.

Chart sites can still compute it. Blockchain.com doesn’t even have BCH charts (I wish they would)

[ShadowOfHarbringer]

@freetrader

The whole point is to keep congestion / high fees from happening, if CDD’s only use is in that situation, it is effectively of no use on BCH.

Hm perhaps you could be right.

But what about spam prevention in relaying transactions? CDD could be used as an additional countermeasure.

@freetrader

I think this discussion belongs in a separate thread to explore exactly what those uses are.

Ah yeah. Case in point.

Reintroduction of CDDs is offtopic in this discussion and should be done in another thread.

[freetrader]

Opened thread for collecting CDD information and benefits:

Coin Days Destroyed used as part of priority - exploring the utility as a basis for further decisions

I’ve created this topic in order to spin the CDD discussion out from the ‘Lower the default relay fee’ thread and into its own thread so we can get a clearer picture of who is employing it in their software right now? what are the benefits? Those points at the very least are worth documenting as part of the ongoing discussions.

[tom]

@freetrader

The whole point is to keep congestion / high fees from happening, if CDD’s only use is in that situation, it is effectively of no use on BCH.

There is a clear fallacy in tihs logic.

The basic fact is that there is no guarentee that block-space supply will outspace demand. All those < $0.01 transactions will find companies exploiting it. With chain success I can almost guarentee blocks will be full.
So what you put up as 'the whole point" is an unattainable goal. Congestion WILL happen in a space where the price of a transaction is lower than the competition, and with the current codebase this WILL lead to high fees. The only question is the timeline.

I’m personally arguing for more levers to make A not automatically lead to B. To avoid the connection that full blocks lead to high fees and lead to cutting off the people living on $2 a day.

The ability to use more features (coin-days and inputs vs outputs) will allow us to not fall in the same trap of success that BTC and ETH have stepped into.

[freetrader]

@tom

All those < $0.01 transactions will find companies exploiting it.

There is also a clear fallacy here, in that this space isn’t inevitably used by others - this has not happened on other blockchains (even very similar ones like BSV).

It could of course happen to BCH, but I think it is more likely to be in the form of a hostile action than everyone rushing to use our competitively priced block space.

I mean, costs right now are < $.0.01 for average transactions. And we can see that our 32MB’s are not being filled up. And haven’t been for the past 3 years or so.

@tom

Congestion WILL happen in a space where the price of a transaction is lower than the competition, and with the current codebase this WILL lead to high fees. The only question is the timeline.

I’ll acknowledge that congestion WILL happen if we don’t stay ahead of demand.
But there’s a condition in there, I’m not going to argue that the effect of people rushing to use our lower-fees chain is necessarily so quick that we cannot meet it.

Also, more levers might be useful, but they also come with costs as I have pointed out (complexity, maintenance costs etc)

[tom]

@freetrader

There is also a clear fallacy here, in that this space isn’t inevitably used by others - this has not happened on other blockchains (even very similar ones like BSV).

That is not a fallacy. This is you putting new data on the table that you draw new conclusions from that you say conflict with my conclusions. The problem with your conclusions based on BCH and BSV is your logic has another fallacy in it.
The fact that BCHs blocks are smaller than 32MB can much easier be explained by us not having grown our ecosystem to contain enough people yet that fill it.
The example is a good one, though, because on BSV and BCH both the percentage of transactions that pays very low fees is quite significant. And that proves my argument.

@freetrader

I’ll acknowledge that congestion WILL happen if we don’t stay ahead of demand.
But there’s a condition in there

Good, you do agree with my (seemingly not fallacious) conclusion.

I do agree that there is a chance we may keep innovation aheaad of usage. I personally don’t think that is going to be the case.

Adoption of successful products goes via a so called S-curve, and we hope that BCH is going to be successful and follows the same kind of adoption. Staying ahead of adoption is a nearly impossible thing and BCH frankly doesn’t work on scaling to make me think we will have no problems in the next 2 - 5 years.

I mean, even if you disagree that adoption will be lower than block-space increase, it still is good practice to plan for when your optimistic view fails.

[freetrader]

In related news:

CHIP-2021-05 Minimum Fee Rate Voting Via Versionbits

[…] a minimum relay fee adjustment mechanism driven by miner voting in block header version bits 11 and 12. This will allow hashpower to express a fee adjustment preference: increase, decrease or no change to the relay fee. The votes would be evaluated at regular intervals by full nodes and other software such as SPV wallets. A minimum relay fee change would happen if 75% or more of blocks within the last 1,008 voted in its favor. The votes would be evaluated approximately once a week, or more…

Specific comments about that CHIP please within its own thread…

[IMightBeAPenguin]

@ShadowOfHarbringer

Let’s say if the Q1 (25% lowest) fees from last 100 blocks is 10 sat per MB, then we set relay fee automatically to 50% of that, meaning 5 sat per MB.

Mined blocks should ultimately provide somewhat reliable data about real world environment and it is probably the only kind of data that is not prone to sybil-attacks.

Of course that would be the default settings, miners and nodes could change it in configuration files.

Not a dev, but what if instead of using quartiles, we use standard deviations? The minimum relay fee will be 2 or 3 standard deviations below the mean. This default could be adjusted, and we can have this adjusted in a “rolling” fashion, meaning that it is calculated per block, using the data of the last 36/72/144/etc blocks.

[ShadowOfHarbringer]

@IMightBeAPenguin

Not a dev, but what if instead of using quartiles, we use standard deviations?

Quartiles, standard deviations - it doesn’t really change much.

The end effect will be the same.

Somebody with more mathematical background should chime in and tell us which one is better.

@IMightBeAPenguin

This default could be adjusted, and we can have this adjusted in a “rolling” fashion, meaning that it is calculated per block, using the data of the last 36/72/144/etc blocks.

Yes, of course this logically can/should be done only in a rolling fashion, this is what I meant.

[IMightBeAPenguin]

@ShadowOfHarbringer

Quartiles, standard deviations - it doesn’t really change much.

The end effect will be the same.

I agree, but standard deviations make more sense intuitively. I think it’s better at pointing out outliers than using quartiles, but that’s just my opinion. I definitely will look into fee rate distributions though, and gather what I can find. I think johoe’s website is best for this. Heck, I might use blockchair.

[Mr.Korrupto]

With the talks about decreasing the minimal relay fee, I think it’s important that one particular “usage” of blockchains must be raised.

Data storage.

If we go lower than 1000 sats/kB, a very important spam/attack vector opens up, that being an increased usage of data storage on Bitcoin Cash. Currently, on Bitcoin SV there’s a culture of casually storing everything on it, such as pictures you put in a twetch, or just general files using bitcoinfiles.org
Currently, most services/users on BSV pay 500 sats/kB.
If min relay fee gets lowered down to 100 sats/kB, it will be cheaper to store on BCH than on BSV. With the unbounded tx chains now live, the Bitcoin Files protocol (that is part of SLP spec.) could be updated to support them, meaning that the limit will be only how much a person is willing to pay. As the min relay fee gets lowered, that limit increases OR those who were outpriced before, will be able to store files now.
I think it’s important this gets recognised as a point against a such rapid and steep decrease, as it can greatly hurt the Bitcoin Cash network.

[freetrader]

I agree that this could be a risk, and is definitely a reason to be very careful about decreasing fees without proper consideration or, in fact without a corresponding price increase of BCH.

[IMightBeAPenguin]

If we go lower than 1000 sats/kB, a very important spam/attack vector opens up, that being an increased usage of data storage on Bitcoin Cash. Currently, on Bitcoin SV there’s a culture of casually storing everything on it, such as pictures you put in a twetch, or just general files using bitcoinfiles.org
Currently, most services/users on BSV pay 500 sats/kB.

What if we were to make the user experience better by allowing minimum relay fees based on the number of coindays destroyed? For example, if a user’s transaction destroys 1 coinday, then the minimum fee can be 100 sats/KB, and if they have 10 coindays destroyed, their transaction can be completely free? Obviously, these aren’t actual figures, but it both combats spam, while also making BCH much cheaper.

[Mr.Korrupto]

It isn’t about “spam” per se, it’s rather more about the data transfered. High rate of tx/s =/= high amount of data.
You can technically do 1.5 kB per tx in terms of meaningful data storage using P2SH.
You don’t need a lot of fresh utxos to do store high amounts of data using that.
Coindays Destroyed only protects against constant re-use of UTXOs that have a small value.

[tom]

I follow your line of thought and wrote a bit more about that here;

Lower the default relay fee, create a fee estimation algorithm

Since I wrote the task about a year ago I have been giving this some thought too. First and most important part is that fees are an artificial spam-protection invented by Core. Yes, we had fees before, but our main weapon against spam was always days-destroyed. A concept that Core removed. My thinking about this is that fees make sense in the BTC world because they want high fees. But we don’t. Our goals are very different. Fees exist as a fallback only. Other metrics that can not be be faked …

[bitcoincashautist]

@read.cash

My personal suggestion would be to use multiple USD price feeds and set the default relay fee to be $0.003 for the 220 bytes transaction, so like 1.36 cents per KB.

That creates external dependencies. What if we could learn some useful information directly from our blockchain? Turns out - we can, each block is a price point for hashes/sats, derived from difficulty/coinbase. Our DAA really works like an automated-market-maker (AMM): network bids for hashes, miners sell the hashes, each block is a trade and gives us a price point for this exchange. If we plug in an ASIC-efficiency curve, then we get a price feed that loosely tracks something like MWh/BCH. More on that here: Research: Block difficulty as a price oracle

So, what if we set the fee to, say, 10Wh/TX (for a 200-byte TX)? You get this:

Notice how it would stay in 0.001-0.005 USD/TX range. Free float could be bad UX for wallets and contracts with hard-coded assumptions. What if we made it monotonic, so it can only go down sat-wise? I applied some EWMA smoothing and then “stick” to historical min. sat-wise:

This happens to near-perfectly settle on our current 1sat/byte. It would further reduce if price hits new highs, and it means we get even cheaper fees (<0.001 USD-wise) during bear markets.

[tom]

On revival of this old topic I want to update it with some thoughts;

first, the default relay fee is indeed a long term real problem. Should the price of BCH go up a lot, we can see 1 dollar fees or more. And the fees can’t be lowered by miners because the nodes in the middle simply block all reasonably paying transactions.
So I’m in full agreement that they should be very significantly lowered at one point.

The main reason it was introduced was always explained as a spam protection, and that was a sane protection since we’ve seen a lot of bad stuff being thrown at our coin over the years. But mostly this attack has not happened. It would not be too expensive to mine a bunch of 32MB blocks full with your own transactions, but no miner ever did. No group ever did such an attack of lots of big blocks. Thank $DEITY.
That does not mean we should drop the relay fee directly and completely, just making the case that our behavior should be based on long term goals and not just simply continuing the road of min-fee we started out of (realistic!) fear.

So to me the goal of mining and minimum fee is that we avoid the debate and we avoid the always problematic design by committee that comes with any sort of central pricing design. The goal instead is to make the prices be set by miners by them simply not mining when they don’t get paid enough. Which may mean they only include high fee paying transactions, or if there are not enough fee paying transactions they may simply decide to not mine Bitcoin Cash. This last part is a reality today. Miners are known to only mine if the electricity in their area is low price. Rainy season for water-power generated electricity as a good example. Winter in areas where the cold allows them to not pay so much for cooling systems, as a second example.

It is a well understood idea because it aligns with the free market. Miners choose to mine when they get paid enough to make the work worth it. And this will shift towards fees over the next decade(s) while the block reward diminishes. Miners will set the price. An idea that works in all industries in free economic systems. They will simply demand a certain income before they do the work. Too low pay, no blocks being mined. Or if we get the tools to do something more fine grained; your low fee paying transaction is ignored in the blocks that are being mined. So pay a reasonable fee and help that miner earn a living.
The free market solves the price setting without any need for an algorithm. Open any economics book, especially from Austrian economics authors, and this is explained repeatedly.

In short, I think we do need action on the minimum relay fee. It needs to be actions with the goal that moves the long term setting of the fee by the market. Supply and demand. Where the ones doing the mining actively eat the supply of transactions that need double spend protection. A free market does not work when some central property distorts it by setting a minimum fee that needs to be charged by miners. So the goal of having a free market of fees means that BCHN needs to severely lower or even remove the relay fee over the next 10 years.