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