Topic: Coalition For 8MB (Read 3198 times)

It's the next bandwidth target for Bitcoin's unified single ledger in order to counter potential competition in this space, but only when it becomes feasible to implement over high-speed home networks. There is no need to change any time soon, as the current limit needs to prove itself in action first.

i dono what about that 8MB problem can let me know whats that problem always all are talking about the 8MB per block why we need to change the block size? in there any issues?

Yep, that's why people should be aware and responsible for their actions and choices.
It's the third "key", as I call it.

I agree, and I am happy you realized that. But make sure to differenciate between consensus changes and non-consensus change. Non-consensus changes can be implemented progressively with minimal coordination from the network (for example node broadcast policies, ...).

Shareholder-style voting where votes are weighed based on ownership percentages could address the issues of a noisy minority.
http://techcrunch.com/2015/09/21/a-solution-to-bitcoins-governance-problem/

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.

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:


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 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.

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. 



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. 

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.

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 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.

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?

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.

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".   

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.

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).

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.

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....

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