Hacker News Reader

Comment by kain_niak | Hacker News Reader

Still limited to 1 000 000 bytes per 10 minutes and then some for segwit which was a unnecessary hack job that actually makes blocks bigger without much added throughput.

View on HN

That isn't true.

In Bitcoin the block size limit was eliminated and replaced with a block weight limit which better reflects the long term operating costs for node. The raw 'size' of transactions inherently is becoming less meaningful in the long term with things like transaction compression and compact encodings.

The weight limit doesn't map perfectly to any size limit because its limiting different things, this evening most blocks have been about 1.3 MB.

Probably technically true, but, it is just a part of the dishonest language-shell-game to fool people into thinking BTC can really scale to become a real peer-to-peer electronic cash for the world's people. 1.3 MB is still tiny! Pretending a small difference matters is so disingenuous.

Blocksize is a rate.

If you were traveling at 120 MPH and then accelerated to 156 MPH you would not say that this was a small difference without consequences.

It mattered significantly, in several respects. E.g. https://bitinfocharts.com/comparison/bitcoin-transactionfees...

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.

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