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.
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.
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)
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. 
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:
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.
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.