Coalition For 8MB

[coalitionfor8mb]

After lurking enough on these forums and reading recent arguments,
I figured that raising the limit to 8MB is a our best chance at reaching consensus.

Pros:
1) Easy to implement in the situation when most of the developers disagree. Good for SW decentralization.
2) Static limit will stay the same over time while technology continues to improve. Reduces the risk of network instability.
3) Good for robustness of the system as the limit is known at any given moment and can be easily verified. Less obscurity.
4) Big enough to not let the competition gain momentum, but safe enough to not let the network fall apart.
5) What seems like big blocks today will become small blocks in the future. Should satisfy both camps.

Cons:
1) Will have to be adjusted down the road. However, a good precedent now will make it much easier than the first time.
2) Big blocks are currently untested. However, an occasional big block will likely get orphaned for any foreseeable future.

This thread is for those who are interested in contributing to the creation of the client,
which will have the new limit built in together with the activation code that enables it after a certain block (somewhere around year's end).

In the situation when development team is split into supporting two radical approaches neither of which represents the idea of original Bitcoin,
we need to form a small contingency group to help Bitcoin get through this uncertainty with the most simple and robust solution.

We need a few members in good standing who can built the software, cross check it and share it with the community.
The best coders that join this initiative will begin shaping up what can be called a Future Crew of Bitcoin.

I personally have never built the client, but will be interested in setting up the environment and doing it myself in the upcoming days and weeks.
However, me alone doing it will not solve the problem as it would require trust from the community, so we need some members with reputation here.

Related topic in the main forum is here.
You are welcome!

[achow101]

So kick the can down the road, but a little farther than the other proposal like it.

Just write up a BIP and ask people to contribute code for it.

[coalitionfor8mb]

So kick the can down the road, but a little farther than the other proposal like it.

When the road ahead is unclear, that's the best we can do.

Just write up a BIP and ask people to contribute code for it.

Thanks! I'll look into that.

[mmeijeri]

I like Adam Back's 2-4-8 proposal better, as it provides a gradual transition. Note that Bitfury's support for BIP 100 was based on their assessment that increasing the limit to 8MB right now is too fast. Mark Friedenbach has also warned that while 8MB is likely safe with current networking hardware, it hasn't been sufficiently tested.

I wouldn't mind accelerating Adam's schedule so that 8MB is reached in 3 years, not 6.

[coalitionfor8mb]

I like Adam Back's 2-4-8 proposal better, as it provides a gradual transition. Note that Bitfury's support for BIP 100 was based on their assessment that increasing the limit to 8MB right now is too fast. Mark Friedenbach has also warned that while 8MB is likely safe with current networking hardware, it hasn't been sufficiently tested.

I wouldn't mind accelerating Adam's schedule so that 8MB is reached in 3 years, not 6.

That might be another good candidate, especially if it comes from a respected member, like Adam Back.

The perception I got recently that people were rushing to choose between two extremes (XT-exponent and Core-1MB-forever), that's why I thought there must be a better way. This 8MB initiative, therefore, may refer to any reasonable approach that caps at 8MB for the next several years.

But there is one important thing.

If we don't have a trusted client at hand that represents a balanced approach, then when the next stress-test comes and people feel uneasy transacting, they might head for the only other eXTreme that exists out there, which eventually may as well become their (e)X(i)T from the ecosystem.

We mustn't underestimate the gravity and the inertia of the processes at hand.
Hence this thread.

[coalitionfor8mb]

I like Adam Back's 2-4-8 proposal better, as it provides a gradual transition. Note that Bitfury's support for BIP 100 was based on their assessment that increasing the limit to 8MB right now is too fast. Mark Friedenbach has also warned that while 8MB is likely safe with current networking hardware, it hasn't been sufficiently tested.

I wouldn't mind accelerating Adam's schedule so that 8MB is reached in 3 years, not 6.

After giving it a second thought, I think that "accelerated programmed 2-4-8" you mentioned might be the best way moving forward.

If in the next 2-3 years the demand for a "single PoW-secured transparent unified ledger runnable by users at home" surges tremendously, while the home-based internet infrastructure allows to satisfy that demand, Bitcoin might begin loosing momentum to its closest PoW competitor, which has 4x the theoretical capacity, while at the same time being faster (confirming) and arguably more convenient network.

Regarding BIP100, the static limit there is poorly specified and is obviously too high to be considered safe for the next several years. It opens the network up for an attack by some rogue miners who might be interested in voting the home-based population of Bitcoin out of the picture.

Smaller static limit (like 2MB) would necessitate having this discussion again fairly soon. In the constant debate about the issue we may begin melting the idea of the limit and instead achieve a diametrically opposite result (no limit at all).

All things considered, the solution space has been reduced to a single static limit of 8MB with a gentle yet quick enough schedule to achieve it. QED

[localhost]

After giving it a second thought, I think that "accelerated programmed 2-4-8" you mentioned might be the best way moving forward.
[...]
Smaller static limit (like 2MB) would necessitate having this discussion again fairly soon. In the constant debate about the issue we may begin melting the idea of the limit and instead achieve a diametrically opposite result (no limit at all).

All things considered, the solution space has been reduced to a single static limit of 8MB with a gentle yet quick enough schedule to achieve it. QED

In my experience, whenever you give away space and resources, they end up being fully consumed pretty fast even if things used to work with a small fraction of said space and resources before. Bitcoin works nice even with the current limit: I can still send fee-less transactions and they get processed usually in a few hours. Increasing to 2MB should be good enough for a while. I fear giving 8MB straight away would encourage people to just use up all that space immediately. A good rhythm could be to increase to 2MB, then when it seems not enough again, increase by 1 more MB, etc, etc. And hopefully before it gets totally out of hand we'll have a better way to handle the blockchain than trying to fit 5TB into the users' SSDs....

[coalitionfor8mb]

After giving it a second thought, I think that "accelerated programmed 2-4-8" you mentioned might be the best way moving forward.
[...]
Smaller static limit (like 2MB) would necessitate having this discussion again fairly soon. In the constant debate about the issue we may begin melting the idea of the limit and instead achieve a diametrically opposite result (no limit at all).

All things considered, the solution space has been reduced to a single static limit of 8MB with a gentle yet quick enough schedule to achieve it. QED

In my experience, whenever you give away space and resources, they end up being fully consumed pretty fast even if things used to work with a small fraction of said space and resources before. Bitcoin works nice even with the current limit: I can still send fee-less transactions and they get processed usually in a few hours. Increasing to 2MB should be good enough for a while. I fear giving 8MB straight away would encourage people to just use up all that space immediately. A good rhythm could be to increase to 2MB, then when it seems not enough again, increase by 1 more MB, etc, etc. And hopefully before it gets totally out of hand we'll have a better way to handle the blockchain than trying to fit 5TB into the users' SSDs....

We need to commit to at least 8MB (though we can do it in a nice and gentle way, like 2-4-8), because the time needed for the new limit to bake itself firmly into the brand will simply be not enough for 2MB to have any effect and we might end up reaching it prematurely, having to debate it again and in that process eventually dissolve the whole idea of the limit altogether. Agreeing on the limit is a lengthy and tiresome process, so we just don't want to do it every year or so.

I would also prefer an accelerated version of 2-4-8 (compared to Adam Back's proposal), as it would allow Bitcoin to keep an edge in the bandwidth department in case its momentum begins shifting towards other solutions, but the most simple and robust way of doing it would simply be bumping the limit to 8MB and forgetting about it for the next half-decade or so.

I agree, that leaving the limit intact for the time being is also an option (arguably a better one than raising it to 2MB), but at some point enough pressure will build up (while the competition continues to catch up) and we will have to rush for the solution in a spontaneous and chaotic way. So, we better plan ahead and begin finding some common ground on what that way should look like.

[manselr]

You left a massive con:

Con) You raise teh blocksize to 8MB and blocks can potentially become way too big for most people to hold blockchains, the full nodes drop and running nodes becomes a centralized business just like what has happened with mining, so rip to Bitcoin.

Additional Con) Potential exploits everywhere because the blocks being too big and not much of it being put to use (very technical shit to explain in a quick post but it's out there).

[coalitionfor8mb]

You left a massive con:

Con) You raise teh blocksize to 8MB and blocks can potentially become way too big for most people to hold blockchains, the full nodes drop and running nodes becomes a centralized business just like what has happened with mining, so rip to Bitcoin.

Additional Con) Potential exploits everywhere because the blocks being too big and not much of it being put to use (very technical shit to explain in a quick post but it's out there).

Oh, I've just explained that part in one of the main-forum's threads. Yes, the home-based demographic might temporarily get shrunk in the transition stage, but if the new limit is rigid enough (that's why we need to place it quite far) to the point that it replaces the original 1MB (baked into the brand by Satoshi) in our perception of Bitcoin, then eventually home-based users will be able to catch up as the technology improves.

Regarding the exploits, I would leave it to technical people to figure out and miners to target a proper block size (within the outlined corridor of 8MB) in order to keep the network secure. What's important in this proposal is that it doesn't go beyond 8MB and there is no mechanism to meddle with the limit, so it must stay firm until the whole ecosystem begins feeling the need to adjust it again. I also argue, that leaving the 1MB limit in place forever isn't an option for Bitcoin in the long run, as that would change the way it has operated all this time.

[sAt0sHiFanClub]

You left a massive con:

Con) You raise teh blocksize to 8MB and blocks can potentially become way too big for most people to hold blockchains, the full nodes drop and running nodes becomes a centralized business just like what has happened with mining, so rip to Bitcoin.

Additional Con) Potential exploits everywhere because the blocks being too big and not much of it being put to use (very technical shit to explain in a quick post but it's out there).

Why do people still carry this false perception that by raising the limit to 8mb that we suddenly get blocks of 8mb? Why are people still falling for this?

Blocks will only be as big as the number of transactions entering the system. Miners are incentivized to produce the most efficient blocks as a function of fees/size.

The only con is to say things like "Something bad will happen but I dont understand what it is".   

[coalitionfor8mb]

I've now almost convinced myself that intermediate steps (in 2-4-8) aren't necessary.
The limit must define where to run, but it shouldn't tell us how fast or slow we should go.

This leaves enough entropy in the system to keep it attractive for internal competition,
while providing enough flexibility in case other similar systems begin gaining momentum.

[Laviathon]

I'm sure I am not the first to bring this up. Of all the transaction traffic what percent of those are Miner payouts going out from the pools?    I would think it would be a higher percentage than one would think.   As mining slows eventually will it really matter?  I have read all the comparison to companies like VISA and the whole transaction per second thing.  What are your guys thoughts?

[coalitionfor8mb]

The summary of arguments regarding the scalability issue has been posted here.

TL;DR - "it's 8MB but later".

The idea was to combine many valid points from both sides of the debate in a single non-contradictory way.
In that process we have figured out that "large blocks" and "small blocks" are simply different stages of Bitcoin's evolutionary path and must continuously alternate in order for Bitcoin to move forward. These stages can also be regarded as parts of the combustion engine's cycle, where the limit on block size first "pulls" the transaction volume and then the volume "pushes" against the limit until it sparks and the whole process repeats itself again.

In order for the new limit to be any good and hold long enough (to keep the costs of running a node manageable), the current one needs to prove itself in action and serve as an effective barrier to prevent the system from spreading its mass across multiple bandwidth layers and eventually disintegrating as a result. The current limit needs to be raised only when system's dominant position (within the set of properties that made it valuable in the first place) is threatened by competition aiming to provide cheaper and more convenient service, while maintaining those same properties.

[DooMAD]

The 2-4-8 route is still based on guesswork, though.  I'd still rather see a flexible and dynamic implementation based on actual traffic, but with safeguards in place to prevent dramatic increases.  That would also give the benefit of not being a temporary kludge than needs to be altered later.  BIP106 is still the best 'platform' or starting point on which to build on, but it needs tweaking a bit first, as the current proposal would likely increase too quickly.

[coalitionfor8mb]

The 2-4-8 route is still based on guesswork, though.  I'd still rather see a flexible and dynamic implementation based on actual traffic, but with safeguards in place to prevent dramatic increases.  That would also give the benefit of not being a temporary kludge than needs to be altered later.  BIP106 is still the best 'platform' or starting point on which to build on, but it needs tweaking a bit first, as the current proposal would likely increase too quickly.

The problem with 2-4-8 is the ambiguity of scheduling it right, there are multiple versions floating around (with 3 and 6 years to get to 8MB).

Anything "dynamic" that satisfies "the demand" will allow Bitcoin to slide towards high-bandwidth layers as more and more large businesses begin flipping their switches and pointing their transaction volumes with fees onto the blockchain, while miners begin picking them up in order to at least break even. This may result in an uncontrolled drop of full nodes as those are not explicitly incentivized and the whole network will become hard to validate properly and might eventually lose its core value proposition.

There is no way around a single static limit on block size no matter what other rules apply to block sizes within that corridor. But we must not over-regulate and over-complicate everything as that would make the system unattractive for internal competition and inflexible for necessary maneuvers against external competing blockchains.

The only reason to raise the block size limit is if there is a similar solution that does the job better (pushes more transactions), while maintaining the same or better decentralization properties, in which case the limit must be put high enough to at least double the theoretical capacity of the competitor and give the whole system enough time to adapt and adjust to the new ways of operating before it can return back to normal (as technology improves) and repeat the same process again.

[DooMAD]

The 2-4-8 route is still based on guesswork, though.  I'd still rather see a flexible and dynamic implementation based on actual traffic, but with safeguards in place to prevent dramatic increases.  That would also give the benefit of not being a temporary kludge than needs to be altered later.  BIP106 is still the best 'platform' or starting point on which to build on, but it needs tweaking a bit first, as the current proposal would likely increase too quickly.

The problem with 2-4-8 is the ambiguity of scheduling it right, there are multiple versions floating around (with 3 and 6 years to get to 8MB).

It wouldn't be a problem if there were smaller increases (or decreases) more frequently.  For example, there's no point doubling to 4MB if we're only going to end up averaging 2.5MB for a while. 

Anything "dynamic" that satisfies "the demand" will allow Bitcoin to slide towards high-bandwidth layers as more and more large businesses begin flipping their switches and pointing their transaction volumes with fees onto the blockchain, while miners begin picking them up in order to at least break even. This may result in an uncontrolled drop of full nodes as those are not explicitly incentivized and the whole network will become hard to validate properly and might eventually lose its core value proposition.

That's why I said "but with safeguards in place to prevent dramatic increases".  I do realise demand isn't the only concern.  Decentralisation is also vital for continued success, so the blocksize limit shouldn't be too large.  At present, the increases/decreases proposed with BIP106 are too large.  I don't see the current doubling part as viable. 

[coalitionfor8mb]

The 2-4-8 route is still based on guesswork, though.  I'd still rather see a flexible and dynamic implementation based on actual traffic, but with safeguards in place to prevent dramatic increases.  That would also give the benefit of not being a temporary kludge than needs to be altered later.  BIP106 is still the best 'platform' or starting point on which to build on, but it needs tweaking a bit first, as the current proposal would likely increase too quickly.

The problem with 2-4-8 is the ambiguity of scheduling it right, there are multiple versions floating around (with 3 and 6 years to get to 8MB).

It wouldn't be a problem if there were smaller increases (or decreases) more frequently.  For example, there's no point doubling to 4MB if we're only going to end up averaging 2.5MB for a while.  

The biggest challenge with changing the rules is getting the whole ecosystem to agree on them. We all individually have our pet theories as to how we would do it properly, but the actual solution needs to literally "resonate" with Bitcoin as a whole as it's supposed to serve the interests of that single whole.

Different parties in the system have their own considerations for themselves as the internal environment is highly competitive. In a recent days I have come to realize that Bitcoin only needs to change if something threatens it as a whole. In other words, if there is a system that can do its job better and as of right now there is no such system.

To put it simply, there are multiple ways to change the rules and only one way to keep them.
The latter always wins if there is much disagreement as it has the most gravity.

[DooMAD]

The 2-4-8 route is still based on guesswork, though.  I'd still rather see a flexible and dynamic implementation based on actual traffic, but with safeguards in place to prevent dramatic increases.  That would also give the benefit of not being a temporary kludge than needs to be altered later.  BIP106 is still the best 'platform' or starting point on which to build on, but it needs tweaking a bit first, as the current proposal would likely increase too quickly.

The problem with 2-4-8 is the ambiguity of scheduling it right, there are multiple versions floating around (with 3 and 6 years to get to 8MB).

It wouldn't be a problem if there were smaller increases (or decreases) more frequently.  For example, there's no point doubling to 4MB if we're only going to end up averaging 2.5MB for a while.  

The biggest challenge with changing the rules is getting the whole ecosystem to agree on them. We all individually have our pet theories as to how we would do it properly, but the actual solution needs to literally "resonate" with Bitcoin as a whole as it's supposed to serve the interests of that single whole.

Different parties in the system have their own considerations for themselves as the internal environment is highly competitive. In a recent days I have come to realize that Bitcoin only needs to change if something threatens it as a whole. In other words, if there is a system that can do its job better and as of right now there is no such system.

To put it simply, there are multiple ways to change the rules and only one way to keep them.
The latter always wins if there is much disagreement as it has the most gravity.

Fair point, but in the course of trying to find a solution that the whole (or at least a significant majority) of the ecosystem can agree on, how do we prepare for the inevitable accusations of "populist tactics" from that group?  The ones who are probably going to disagree just for the sake of being disagreeable because they believe that maintaining a hostile environment is the best route to enforcing ideals that would inevitably lead to an exclusive chain that the average person won't be able to transact on:

Decentralization increases if contentious forks are met with hostility: forked coins could immediately be sold, businesses who transact in them could be ostracized, individuals who support them should be discredited.

The simple fact is, there is no solution that won't come under fire simply for not being of primary benefit to a small, but decidedly noisy, minority.

[coalitionfor8mb]

The 2-4-8 route is still based on guesswork, though.  I'd still rather see a flexible and dynamic implementation based on actual traffic, but with safeguards in place to prevent dramatic increases.  That would also give the benefit of not being a temporary kludge than needs to be altered later.  BIP106 is still the best 'platform' or starting point on which to build on, but it needs tweaking a bit first, as the current proposal would likely increase too quickly.

The problem with 2-4-8 is the ambiguity of scheduling it right, there are multiple versions floating around (with 3 and 6 years to get to 8MB).

It wouldn't be a problem if there were smaller increases (or decreases) more frequently.  For example, there's no point doubling to 4MB if we're only going to end up averaging 2.5MB for a while.  

The biggest challenge with changing the rules is getting the whole ecosystem to agree on them. We all individually have our pet theories as to how we would do it properly, but the actual solution needs to literally "resonate" with Bitcoin as a whole as it's supposed to serve the interests of that single whole.

Different parties in the system have their own considerations for themselves as the internal environment is highly competitive. In a recent days I have come to realize that Bitcoin only needs to change if something threatens it as a whole. In other words, if there is a system that can do its job better and as of right now there is no such system.

To put it simply, there are multiple ways to change the rules and only one way to keep them.
The latter always wins if there is much disagreement as it has the most gravity.

Fair point, but in the course of trying to find a solution that the whole (or at least a significant majority) of the ecosystem can agree on, how do we prepare for the inevitable accusations of "populist tactics" from that group?  The ones who are probably going to disagree just for the sake of being disagreeable because they believe that maintaining a hostile environment is the best route to enforcing ideals that would inevitably lead to an exclusive chain that the average person won't be able to transact on:

Decentralization increases if contentious forks are met with hostility: forked coins could immediately be sold, businesses who transact in them could be ostracized, individuals who support them should be discredited.

The simple fact is, there is no solution that won't come under fire simply for not being of primary benefit to a small, but decidedly noisy, minority.

The actual scenario of selling forked coins seems quite moot to me, because the same transactions can then be broadcast to the competing chain and the coins will be gone forever regardless of which fork they were sold into.

The only scenario that I can envision that would force many to consider changing the rules is if there is a system with strong base of full nodes around the globe running from home networks that begins pushing competitive volumes of transactions for smaller fees and as a result gaining larger and larger user base, because the technology advanced to the point that it became possible to achieve this, while Bitcoin maintained its current limit.

That's when Bitcoin needs to move and there wouldn't be any ambiguity as to where, because the target will be clear.