Hacker News Reader

Comment by ac29 | Hacker News Reader

This article completely ignores the block reward -- the real cost per transaction is more like $7 [0]. The blocksize really needs to change too, last time I did a bitcoin transaction, every recent block was 95%+ full. Its an arbitrary limit, but its contentious and political to change. It really made me want to avoid Bitcoin in the future.

[0]https://blockchain.info/charts/cost-per-transaction

View on HN

The whole point of the block reward is to subsidize the network until transaction volume can grow to an equilibrium point where the network can be supported on fees alone. The fact that transaction volume is capped by the block size is troubling because it won't be able to grow to that equilibrium point.

As the value of Bitcoin grows, transaction cost grows relative to other currencies. Really transaction costs in strictly btc/byte have decreased. Pretty much everyone agrees the block size will need to grow at some point, including core devs. It is the current proposed method of introducing this change (via hardfork) that is questioned and scrutinized.

There is at least one prominent core dev that recently seriously proposed _decreasing_ the block size to 1/3rd of what it is currently. The problem is that the block size needed to be increased last year. Agreeing that it needs to be increased at some unspecified point in the future minus any specifics is just a stalling tactic.

Yes some devs believe there is centralization pressure of mining blocks caused by the propogation delay of 1MB blocks. Further increasing the size of blocks would thus increase centralization pressure. Changing any number of variables leads to emergent properties which change mining behaviors. Game theory needs to be considered before tweaking the consensus protocols of Bitcoin. The open source nature of Bitcoin allows for many opinions and critisms and hopefully many more proposals for change in the future.

The issue of propagation delays with bigger blocks was fixed with xthin blocks (aka: compact blocks) months ago. That is no longer a valid reason for limiting the block size.

There is very limited technical documentation on xthin so it is hard for the community to accept and test it. If Bitcoin were to implement xthin (or an alternative proposal such as compact blocks) it would be much better to release outside of the block increase. again the main contention is the mechanism for change that the Bitcoin unlimited enthusiasts want to impose, a contentious hard fork

And to clarify, the software may have been released (in Bitcoin unlimited's release), but is not used by the Bitcoin network as a whole. Very few nodes are running this implementation. And to many is untested/unproven

You are just spouting false propaganda now. The Core equivalent to Xthin, "Compact Blocks", has been released in Bitcoin Core since version 13.0.0

Please point out where I am spouting false propaganda.... You previously conflated xthin and compact blocks as if they were the same thing. Xthin is not being used by the network. And there are developers who have reasons to believe that increasing the block size will have a centralizing effect on mining. This is not "fixed" as you stated before.

You said: "If Bitcoin were to implement xthin (or an alternative proposal such as compact blocks) it would be much better to release outside of the block increase."

Fact: Both xthin and compact blocks are different implementations of the same idea. Both have already been implemented and released and are in active production.

Blocks are supposed to be full, otherwise fees are zero. The question is what fees should be, and what the minimum reasonably transaction amount should be for it to be included on the chain... not what blocksize should be. "Fullness" is not a thing.

Reply on news.ycombinator.com