Hacker News Reader

Comment by j23450n | Hacker News Reader

Blocksize is clearly not literally a rate; that's a ridiculous statement. When you artificially cap it, like putting a limiter on your car in your analogy, it can be rate limiting, i.e. limiting the transaction rate - an actual rate. That chart you posted in meaningless in this context, but clearly just greg being greg, trying to manipulate; are you seriously trying to suggest that the tiny increase from segwit shenanigans is responsible for that (cropped) decrease in tx fees? That's demonic.

View on HN

It is literally a rate. It is the rate of bytes added per block (which by the system's design is once per ~10 minutes).

Increasing supply above demand radically drops fee rates. That is the logical, predicted, and observed behavior-- both in Bitcoin and in other similar systems.

Of course the fees would drop after raising the blocksize.

The current fees are well above the marginal transaction costs of processing and storing those transactions. (I estimated it was 3cents/kB, assuming GB scale blocks on ~1000 4U (36 bay) servers with 10Gbps networking distributed world-wide.) Other analysis I have seen erroneously assumes the POW is a marginal cost: which is only true with a tiny, limited, block-size.

During the September 1, 2018 "stress test" on the BCH network, the average transaction cost actually went down. All while the network processed 2 million transactions in a day.

Pretty much this. I don't think greg has read any economic theory, let alone introductory microeconomics where you would see the idea of 'marginal analysis'. I mean his reply suggests that demand is entirely static, or inelastic, which would be interesting to study, but certainly shouldn't be assumed, and is likely completely false.

Look, I'm not one to harp on semantics, but this is bullshit, you can't* just make something a rate by using the word 'per'. If I'm a doughnut shop, and I sell 12-packs of doughnuts, my doughnut-box-size is not a rate, the amount of doughnuts I sell in an hour, or a day etc., is a rate. If my store has a policy of only fulfilling orders once every 10 minutes on average, but only up to one box, or 12 doughnuts per 10 minutes, the doughnut-box-size is still not a fucking rate, even though the shop could say they only sell 12 doughnuts per 10 minutes. Edit: Let me rephrase this somewhat; it's clear greg is trying to use semantic chicanery and multiple definitions and senses of the word 'rate' to obfuscate any actual points. Rate is typically used and understood (let's say in STEM anyhow) to be a measure of 'flow'. Thus his speed example, distance per time, is a rate, or tx per second. It doesn't have to use time as measure, but here what greg is trying to do is say that, using the most generic definition of rate, you can compare doughnuts and boxes and say that doughnuts-per-box (blocksize) is a rate, even though he's really using as example "(dougnuts-per-box)-per-((10 minute)time interval)", which is a rate, and pretending they're the same thing . Of course if you increase the size of the container, the flow, or actual rate of tx/time interval will increase, but saying that the size of the container itself is a rate, is contextually insane.

Reply on news.ycombinator.com