Hacker News Reader

Comment by toomim | Hacker News Reader

The cost is increasing because more people are trying to use Bitcoin, but it has an artificial limit to the number of people who can use it per second. Thus, with increasing demand, and static supply, the fees rise roughly quadratically over time.

To reduce the fees, we need to remove that artificial 1mb limit. Here's the main approach to that right now: https://www.bitcoin.com/info/what-is-bitcoin-cash

View on HN

>To reduce the fees, we need to remove that artificial 1mb limit. Here's the main approach to that right now...

Removed the BCH spam link. No, this is NOT the main approach to that. The main approach to that is the Lightning Network, which is not yet in production.

Your "main approach" is a hardfork that increases the block size, run by someone who owns the bitcoin.com domain, regularly misrepresents what Bitcoin Cash (bcash) actually is, and goes on live shows yelling obscenities and flashing the middle finger very professionally when these things are pointed out.

So, no, Bcash is not the main approach to "fixing" Bitcoin. It is a wholly separate coin with trading volume less than one-third of Bitcoin.

Increasing block size is the low hanging fruit for reducing tx fees.

It's a dead-simple idea. You increase the supply side of the fee market and users don't have to compete for transaction finality anymore. It has been implemented and we know it works.

Of course, that is only kicking the can down the road and has many caveats. It still has proven effective to complete its goal (minimize tx fees).

Lightning networks is a WIP that is months, perhaps years, away from hitting production. As such, I wouldn't call them the "main approach" to scaling except in the mind of core engineers. It might drive tx costs down, it might not, at this stage it is too early to tell for sure.

As such, I think OP is right. It is completely fair to say that block size increase is the "main" approach, as in the "the one that we know for sure works right now", to making Bitcoin usable as a payment system.

Now on a side note: I don't think you needed to be that aggressive with OP. I won't address the attacks on Roger Ver because it is my belief that attempts at turning a technical debate into politics should be met with contempt.

Increasing block size definitely can solve the problem. Bitcoin Cash solves many short-term problems, I am not saying otherwise. It is NOT, however, the "main" way Bitcoin is dealing with the problem. It is the way another coin is dealing with the problem and this coin is not Bitcoin.

>I won't address the attacks on Roger Ver because it is my belief that attempts at turning a technical debate into politics should be met with contempt.

I mean, you just did, via this comment.

Bitcoin Cash is closer to the original Bitcoin implementation in code, philosophy, and community. Same thing that worked since 2009, until the blocks ran out of space.

>Bitcoin Cash is closer to the original Bitcoin implementation in code

Because it's a 99% pure fork of BTC, sure. Closer than the "original" Bitcoin? That's not possible to say.

>>philosophy

Subjective at best. Unless, you know, Craig Wright actually is Satoshi, since he's involved in BCH and has claimed to be him. In which case, it absolutely is.

>>community

Also subjective.

I think the claim that it is closer to the "original vision" has some substance if you think of Bitcoin as a peer-to-peer cash system rather than as a settlement layer.

With that said, this certainly does not imply that p2p cash is what Bitcoin could actually excel at once it reach global scale. Modifying the original vision is not some great sin, it literally happens all the time with startups and no one bats an eye.

I don't think being closer to Satoshi's original vision is any important, Bitcoin is not a religion and Satoshi isn't a prophet.

The split-up was a good thing, I'm excited that different avenues are being explored. Maybe core maintainers are wrong and p2p cash is actually the way to go. Maybe Bitcoin Cash fans are wrong and the solution lies in developing L2 solutions. Maybe both are wrong. Time will tell and we should be happy that different things are being tried.

The engineer in me says that the "real" Bitcoin is the one with the most total difficulty. I think that definition is too narrow. To me, both are the real Bitcoin, just in different timelines. The timeline that wins will overwrite reality such that it was the real Bitcoin all along. Meta!

Does causing community tensions, new user confusion, forked market cap and diversion of resources worth creating this short term fix?

The BCH camp could have contributed their resources to helping Core come up with a long term solution. Any fork that doesn't offer real groundbreaking advances is just a distraction and should be shunned. Forks that are simple recompilations of the original Bitcoin with simple config changes to the blocksize and/or algo are power/greed plays.

>>The BCH camp could have contributed their resources to helping Core come up with a long term solution.

While I think BCH is run by a bunch of nutjobs who are hellbent on doing unethical trash to ruin BTC, this isn't a fair criticism. Ver and others did try to help Bitcoin (I refuse to call it Core, it doesn't need a descriptor, Bcash does) through these methods, but BTC's developer pool is... something of a bunch of Internet arguers.

Roger Ver took his ball and went home. There's nothing wrong with that at all. He thinks he's right, and that's all well and good. What's not right is his ridiculous insistence that BCH is the real Bitcoin and the intentional methods to devalue BTC in conjunction with Jihan, and acting like a kid in public and social media going nuts.

Do you happen to know the reason why there is only talk about increasing block size to increase the number of processable transactions, and not keeping block size the same but decreasing the time window for the average block to be mined down to 5 or 1 minute instead of 10 minutes?

There are plenty of altcoins with short block times. One downside is that they increase the frequency of orphaned blocks and chain reorganizations.

Anyway, doesn’t it amount to the same thing? 2 MB every 10 minutes or 1 MB every 5 minutes, your node still has to do roughly the same amount of work to validate blocks.

The same argument against increasing the block size but even more so. It takes time for blocks to propagate across the P2P network, which puts smaller miners at a disadvantage by increasing their orphan rate, which leads to miner centralization.

I think that argument is even stronger against lower block times because latency (network, validation, etc) rather than bandwidth contributes the most to block propagation delays.

The fixed lock size cap was removed last August and block sizes increased. Now it's just the problem of making people use the newly available space. Pricing out legacy transactions is a perfectly valid method.

This isn't entirely true. There is still a fixed max block size; it is just that some bytes are counted as "bigger" than others. In particular, the maximum block weight is currently 4MB. However, most bytes count as if they were 4 bytes; which returns us to an effective blocksize of 1MB. However, bytes that are part of SegWit's witness area only count as 1 byte.

This leaves a hard upper bound of 4MB block size, with a "typical" size of ~2.3MB if everyone uses SegWit.

While technically true that the block size cap has a hard limit of 4MB, which would be a block consisting of one transaction with only inputs, a 4MB transaction isn't valid for other reasons.

So it's not meaningful to talk about a fixed block cap anymore. Perhaps it is better to talk about "typical" block sizes the way you do.

What's important is that the 1MB limit is history, unless you have to make legacy transactions for some reason.

How does litening work if it takes a transaction to open and a transaction to close, and the median fees are increasing with time?

Reply on news.ycombinator.com