4 ms·

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 ha

by relyio 9y ago

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.

icelancer 9y ago
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.
- qsucvatz 9y ago
  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.
  - icelancer 9y ago
    >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.
    - relyio 9y ago
      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!
- infinii 9y ago
  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.
  - icelancer 9y ago
    >>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.
oh_sigh 9y ago
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?
- umanwizard 9y ago
  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.
- tlrobinson 9y ago
  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.
xorcist 9y ago
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.
- gizmo686 9y ago
  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.
  - xorcist 9y ago
    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.

by relyio 9y ago

icelancer 9y ago

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.

qsucvatz 9y ago
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.
- icelancer 9y ago
  >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.
  - relyio 9y ago
    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!
infinii 9y ago
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.
- icelancer 9y ago
  >>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.

oh_sigh 9y ago

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?

umanwizard 9y ago
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.
tlrobinson 9y ago
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.

xorcist 9y ago

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.

gizmo686 9y ago
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.
- xorcist 9y ago
  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.