Lower the default relay fee, create a fee estimation algorithm

Hm perhaps you could be right.

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

Ah yeah. Case in point.

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

Opened thread for collecting CDD information and benefits:

2 Likes

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.

1 Like

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.

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)

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.

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

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.

1 Like

In related news:

Specific comments about that CHIP please within its own thread…

2 Likes

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.

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.

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

1 Like

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.

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.

6 Likes

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.

4 Likes

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.

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.

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

1 Like

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:

image

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:

image

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.

3 Likes

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.

Users, or the “buyers” of block space, have a number of things of value that can’t be spoofed.

Users have cash. This is the default method of payment. We’re solidly in a simple cash phase where everyone just pays 1 sat/byte because coins are cheap.

Users also have coin days. I’m not exactly sure how it was implemented, but the legend of the old days is that users burning sufficient coindays were exempt from paying fees.

Users also, generally, have access to some kind of low grade horribly inefficient hashing mechanism. Users could grind for a low transaction hash to prove they weren’t simply spamming the network at no cost, but the efficiency disparity between an ASIC and a CPU would make it easily abused by miners, and useless to broke users on budget hardware. The user experience would be horrific.

However, miners, or specialist MEV harvesting outfits could write software to grind for a low hash to save a few sats. Offering a network discount for hashrate wouldn’t really work in practice however, because the miner with the winning block nonce can choose to replace an MEV transaction with a low fee for their benefit.

So, ignoring hashing, we want a minimum cost equation like:

(cash + coin_days_destroyed * k) * difficulty_price >= C


To solve for k, the constant normalizing coindays to sats, it’s worth noting that offering a network discount to holders is essentially offering a yield.

Given what I’ve seen on our various yield protocols, it might be interesting to look at a k of 1 sats per coin block or 144 sats per coinday. That works out to a yield of 0.05% APY. It would allow a person with 1 coin to make a simple transaction 125 times a year for free 99.

EDITED to cut k in half.

Boiled down, you list 3 unforgeable proofs the users may offer:

  • Cash (sats): proof of fee payment, the default, what we use now
  • Coindays: proof of holding
  • Hashing (grinding low TX hashes): proof of work at the user level

and claim all of these have value and could therefore be used as “payment” for fees. I disagree. Cash is king, and only cash contributes to common security, because only the fee adds to blockchain’s chainwork state, which underwrites the immutability property. Now let me dismantle both coindays and hashing :smiley:

What do users “have” in coindays? Why should coindays be worth something to anyone?

I never understood the obsession with coindays as if they imbue coins with some magical extra value. A coin having high coindays means the owner held on to it for a long time, that’s it. Doing nothing is all it takes to accrue them. How much is doing nothing worth? Why should “we” (the network as a whole) give someone credit for that?

If anything, maybe we should charge them. They were away from the network while “we” kept their coin safe, at a non-zero cost to “us.” Gold vaults don’t pay interest on long-held deposits. They charge fees, because maintaining a vault has costs. The presence of a long-held UTXO in the state imposes a small ongoing cost on every other user’s transaction processing. The least someone can do when finally moving their coin is pay the fee like everyone else, rather than expect a discount.

To this you may retort that gold coins have greater numismatic value as time goes on. But it is not comparable, because our UTXOs are indistinguishable (no TXID:vout has special value), and whatever coindays a coin accrued will be lost on transfer. It can’t be a payment when nobody receives it, it is destruction, all the metrics pages correctly call it coindays-destroyed. Compare to gold coins, where the coin’s history gets transferred together with the coin.

Users, or the “buyers” of block space

Are users really “buyers of block space,” or are they buyers of hashes?

Fees pay for hashes, nothing more, nothing less. When you go to a bazaar, you bring cash and leave with goods. Did you have to buy your slot for the trade first? No. The bazaar is maintained by volunteers who also happen to have stands where they sell goods, so helping maintain it serves their interest.

Users pay a fee, but it’s not for space, it’s for enforcing the common security policy of the bazaar: no returns. Only the security enforcers (hashers) get paid. The minimum relay fee isn’t the bazaar demanding payment for space: it’s congestion control. We don’t let you browse around only to buy nothing. Without block subsidy, our security will depend on this one-for-all-and-all-for-one pact. Each user’s transaction fee will contribute to security of not just his own TX, but everyone else’s TXs. Of course “we” want to allow as much contributions to this commons as we can handle, and in case of congestion favor higher contributions over lower.

There are 2 aspects of fee here:

  1. Contributing to common security
  2. Congestion control

Coindays and user-PoW may be useful only for #2, as they contribute 0 to common security but are still fundamentally unforgeable by spammers. But if we already have the fee for #1, why introduce a second mechanism for #2? The fee already handles congestion, a spammer must burn real resources either way. Adding coinday discounts just complicates the equation without buying us anything.

You already discarded this idea yourself by saying spammers could abuse the network due to access to better hardware, but that’s not the only issue. The fundamental issue is that this user PoW doesn’t contribute to common security, no amount of user-PoW in a block would increase difficulty of a reorg. It’s just proof-of-sacrifice, the user did something at a cost to himself and 0 value to us, and would make such offering to “us” to make an exception and let him do his business on the bazaar without paying for common security. But why would anyone need to make this sacrifice when they already have coins they can use for fees? Without coins, how would they do any business on the bazaar?

Miner’s PoW actually buys “us” something: the immutability property. It’s not just a sacrifice (or “waste”), each hash purchased adds to the network’s chainwork. User’s PoW buys us nothing. But users can also buy us immutability: by buying their PoW directly from miners. That’s the brilliance of Bitcoin’s design. Each satoshi paid as fee is actually a user-bought-PoW (at the current exchange rate given by difficulty/coinbase). Cash is king.

1 Like

We agree that letting users hash to meet the relay minimum is silly. We don’t have to waste further time on that. It would destroy the low-end experience and add no security or cost savings.


But on a coindays discount…

Time is a finite resource, a valuable resource, and something easily measured by our timestamp service. It’s not really an emotional obsession, it’s just a matter of finance that money and time are closely related. Contracts and instruments are almost always concerned with rates in time rather than totals.

The question is whether miners should offer holders a slight discount on the purchase of hashes, I think it would actually be in the best interest of miners on a total cash basis to have the discount.

Consider two credit unions. One offers NO interest on savings accounts, the other offers a 0.05% APY―nothing really, but not nothing. It would be 50 cents on every thousand dollars held.

A credit union is made of it’s members, it’s shareholders. The policy and purpose is determined by the folks who keep their money there.

The more valuable credit union would be the one paying 50 cents a year for every grand on deposit, because that credit union would have smarter members. And people generally like if they can get X number of transactions a year for “free”.

If any non-zero return is going to break the bank, the bank is already done. It will be crushed by competitors that have levers.


From a monetary policy perspective, of whether or not we should allow these free loading savers to get cash discounts for their coindays, the policy is already settled squarely in the affirmative.

We DO allow any user to convert coindays accumulated into tokens, and those tokens into cash, and to do all that instantly at the same time Alice is paying Bob.

And anyone who thinks our stablecoin with yield will be more valuable than a stablecoin without can choose to accept or deal in the coinday commodity tokens to help the value of the base asset.

The question now is just about how clean or efficient that process is on chain.

Does Alice have to claim rewards and sell tokens on a dex to pay Bob without paying a fee, OR can the miners (and the maintainers of the network) see the value in baking in a 50 cent annual allowance to pay Alice’s initial fees?

2 Likes

Credit unions pay yield from lending revenue. Where does the coinday “yield” come from? It’s a discount, meaning other users or miners subsidize it. Who pays for Alice’s free transactions security? Everyone else paying full fees. You correctly call it “discount”, just thought to highlight this.

On second thought I’m not really against carving out a discount for coindays-destroyed. It can’t really hurt us because coindays-destroyed are a scarce “resource”. Even if everyone wakes up one day and uses the option at the same time, I wonder how many TXs that could be. Spending all the high-coindays UTXOs in the same day, what happens? Maybe some mempool backlog, but fee-paying TXs would have priority so no problem, miners would slot in these only if there’s room after the last min. fee TX.

This sounds good, actually. Some thought should be given to min. dust limit, and IMO we should NOT discount min. dust limit for new outputs but we should allow spending old outputs below dust. This way, smaller dust could be cleaned up for 0-fee once it ages enough, and contribute to creating fresh UTXOs with enough sats in them that they can carry their own weight.


Now, on the role of miners.

It’s not the miners who are offering any discounts, they don’t hash each transaction individually; they hash whole block headers which commit to whole bundle of transactions. The DAA fixes the amount of hashes they get to “sell” at the current height, and without subsidy it will be just the state of mempool that determines how much they can get for it, take it or leave it. Every TX that pays a non-0 fee will increase the price of hashes. They can take what is offered (current state of mempool, fill the block with whatever is available) or leave it. Leaving it will drive the price down by reducing difficulty, until price becomes acceptable to them. But we have to stop thinking of “them” as a homogeneous collective. Some have ASICs with 80% margin, some have ASICs with 20% margin. If fee offering is too low, the 20% ones may refuse to mine, but 80% will continue and still be profitable - and it will drive the price down until some equilibrium. This ties in well with what @tom was talking about:

With current DAA, this would be problematic in some edge cases (ALL miners starting/stopping) - because someone has to mine the next block to feed in the fresh information into DAA. You need those high-margin miners to still mine when it becomes less attractive to mine, because our DAA won’t reduce difficulty in real-time. Network could indefinitely hang if mempool is starved of fees, and difficulty for the next block would remain the same until someone finally mines a block to update the DAA.

I like the idea of real-time difficulty targeting. The target for the block yet-to-be-mined could be reduced in real-time as time since last block elapses. But to make it work I think we’d have to tick the other things off this list with it: https://github.com/zawy12/difficulty-algorithms/issues/30