4 ms·

What is the downside to moving from 1MB to 2MB blocksizes, instead of moving up to 8MB or 20MB? If the reasonable maximum number of trades per minutes is 3 at

What is the downside to moving from 1MB to 2MB blocksizes, instead of moving up to 8MB or 20MB? If the reasonable maximum number of trades per minutes is 3 at the moment, does a doubling of the blocksize merely double the allowable number of trades per minute, or is it somehow a logarithmic change?

martinko 11y ago
It does just double it. The problem with increasing it more is propagation speeds around the planet (this needs to be as fast as possible or another miner may get the block reward), especially if the miner is sitting in china.
- kobayashi 11y ago
  So is increasing the blocksize beyond 2MB expected to favour Chinese minors more so than average users? And if that's the case, would you mind explaining how so, exactly?
  - simoncion 11y ago
    I'm fairly certain that the problem is that users with catastrophically slow or spotty internet connections are the ones that stand to lose in that situation, and that > 50% of Bitcoin's miners are in China, which partially explains the rabid past support for a refusal to increase the max blocksize.
  - martinko 11y ago
    The dynamic is not one in which when miners win, users lose. The issue is that users want more transactions per second and therefore want bigger blocks to be created, however, when miners create larger blocks, they have a hard(er) time propagating them to the entire network and thereby run the risk of their block being orphaned (someone else's block will be accepted first, and the miner's block and work done on that block will be wasted).
    - kobayashi 11y ago
      Oh I see, which is why Chinese miners would be especially hesitant about moving to larger block sizes, because the GFoC significantly limits speeds.
epmatsw 11y ago
That was my first thought. Why go through all this hassle to just put off the problem until the traffic merely doubles? This seems like when you see something silly in code like: // const MAX_SIZE = 1; // make it bigger to fix crash const MAX_SIZE = 2;
- kobayashi 11y ago
  fantastic analogy!
CyberDildonics 11y ago
Many people have said the same thing. Right now a group of people has gone to a lot of trouble to control the main repository and forums. At the same time, many algorithms have been proposed. The most pressing problem at the moment is making sure there is room to grow, proving that a fork can happen, and getting the software out of the control of the people who have incentives that are opposing the vast majority of actual users. Once these problems are worked out more sophistication is much more likely.
- kobayashi 11y ago
  Ah, okay. So it's a matter of getting the ball rolling for now. And then XT-type changes may occur in the future?
  - CyberDildonics 11y ago
    I think that is likely although that is predicting the future territory. Fundamentally the block size limit is about consensus, which bitcoin is very good at. I personally think consensus about the block size limit should be amended constantly through each block mined. Some would agree and some would disagree.

martinko 11y ago

It does just double it. The problem with increasing it more is propagation speeds around the planet (this needs to be as fast as possible or another miner may get the block reward), especially if the miner is sitting in china.

kobayashi 11y ago
So is increasing the blocksize beyond 2MB expected to favour Chinese minors more so than average users? And if that's the case, would you mind explaining how so, exactly?
- simoncion 11y ago
  I'm fairly certain that the problem is that users with catastrophically slow or spotty internet connections are the ones that stand to lose in that situation, and that > 50% of Bitcoin's miners are in China, which partially explains the rabid past support for a refusal to increase the max blocksize.
- martinko 11y ago
  The dynamic is not one in which when miners win, users lose. The issue is that users want more transactions per second and therefore want bigger blocks to be created, however, when miners create larger blocks, they have a hard(er) time propagating them to the entire network and thereby run the risk of their block being orphaned (someone else's block will be accepted first, and the miner's block and work done on that block will be wasted).
  - kobayashi 11y ago
    Oh I see, which is why Chinese miners would be especially hesitant about moving to larger block sizes, because the GFoC significantly limits speeds.

epmatsw 11y ago

That was my first thought. Why go through all this hassle to just put off the problem until the traffic merely doubles? This seems like when you see something silly in code like: // const MAX_SIZE = 1; // make it bigger to fix crash const MAX_SIZE = 2;

kobayashi 11y ago
fantastic analogy!

CyberDildonics 11y ago

Many people have said the same thing. Right now a group of people has gone to a lot of trouble to control the main repository and forums. At the same time, many algorithms have been proposed. The most pressing problem at the moment is making sure there is room to grow, proving that a fork can happen, and getting the software out of the control of the people who have incentives that are opposing the vast majority of actual users. Once these problems are worked out more sophistication is much more likely.

kobayashi 11y ago
Ah, okay. So it's a matter of getting the ball rolling for now. And then XT-type changes may occur in the future?
- CyberDildonics 11y ago
  I think that is likely although that is predicting the future territory. Fundamentally the block size limit is about consensus, which bitcoin is very good at. I personally think consensus about the block size limit should be amended constantly through each block mined. Some would agree and some would disagree.