Oh, just noticed another line from the lyrics I quoted on the first page.

"The track is on some battling raps, who want some static?"
(the static in question is obviously that of a block size cap)

Hey, Bitcoin! Want some static? Of course you do!

Haha, the (Uni)Verse has some nice sense of humor.
Enjoy!

One more thing, reaching consensus isn't about respecting the differences in opinions or popular voting, it's about finding a single underlying layer of truth and sticking to it. Not everyone will be able to see it or understand it, but if enough of the brightest of us do, the rest will follow.

That's how mathematicians prove their theorems.
Let's look at what isn't the correct solution first:

---

1) Arguments against removing the limit or placing it too high.

The home-based demographic of Bitcoin is important. That's where Bitcoin was born, that's how it gained its value. The large network of nodes enforces the rules of the game by its mass. It creates a solid playground for other participants (miners, merchants, exchanges) to make their moves and flex their muscles. It's like a boxing match, where the home-based nodes are the spectators. Don't forget about the butterfly effect, where a subtle change to the configuration of the system may have a tremendous effect on the outcome.

2) Arguments against keeping the limit unchanged or too low.

Bitcoin gained its value by slowly increasing its effective capacity, while being guarded by a high enough static hard limit. That's the only configuration that managed to survive to this point and the only one that is known to work reliably so far. There are no precedents of a crypto-currency that has been effectively capped on its transaction volume and become successful. Don't forget about the competition either, being arrogant and ignorant about it is the best way to get out of business quick.

3) Arguments against floating/flexible limit.

Letting miners or any other full nodes to meddle with the limit will create the situation, where everyone begins pursuing their own interests, while the idea of consensus would start falling apart. A single static limit (which is easy to implement, easy to enforce, easy to follow) is the only guardian of the consensus that represents the interests of Bitcoin as a whole. If in this contingency situation we put those interests above our own, we will all agree.

---

This reduces the space of correct solutions to a single static hard limit, which is not too high and too low. Now, taking into account the limitation expressed by Chinese miners and the current pre-fork capacity of Bitcoin's closest PoW competitor, the actual figure is not that hard to come by.

The current situation is not caused by mistakes of the devs, their misunderstanding or any other circumstances. It's the test for the community. You see, the truth is simple. Only the best of the best deserve to have Bitcoin and now is the time for us to prove that we do.

Remember, you are not done until you're running the software that represents the idea of consensus as outlined above, so let's get busy. In the game of Chess only when you commit to a move, the clock starts ticking on the other side. I'll see you there.

I invite you to re-assess the parameters of the system (including the block size cap) not only based on technological considerations, but from the perspective of incentives structure as well. The fact, that we haven't seen enough consolidation in the space of full nodes, is because the rules of the game clearly indicate that there is a ceiling on the level of bandwidth that the network is willing to tolerate with its current size. Don't sign up to the rules, that you likely won't be able to follow in the future.


Why shoot in the dark? It's like trying to solve the problems of 2020 or 2036 today, without even knowing what they are. Don't underestimate the psychological effect of the limit. That's the only reason we are having this conversation about the change. It's a sync-point (or barrier in pthread terminology) at which we all arrive to see who is running and where we are going. Without these the inertia of the process might build up to the point, that any attempts to hold it within the path, that best represents the goal it was created for, simply won't gain any momentum and instead fall on deaf ears.

There must be a single static limit firmly cemented into our perception of Bitcoin in order for it to have any effect whatsoever, but big enough not to limit Bitcoin's growth within the safety threshold determined by the current state of technology.

Reaching consensus requires finding a common ground.

In the case of a block size increase that common ground becomes the interests of Bitcoin (as a whole), but not the interests of its different parties, which often conflict with each other.

In order to agree on that one thing, we need to look at how Bitcoin started and how it gained value, what purposes different parameters of the system serve and how Bitcoin stands against the competition in the foreseeable future.

So, basically, consensus is not about differences of opinions and voting, but rather about finding a single underlying truth, sticking to it and understanding that benefiting Bitcoin (by agreeing) will actually benefit all of the parties involved.

Bitcoin shows us that being able to negotiate on complex issues and acting in goodwill is actually a mathematical necessity for progress and evolution.

Thanks!

The main objection to BIP101 is that it moves too fast (not too slowly) in order for home-based full nodes to keep up.
If we approximate BIP101's curve with a series of 4-year-lock-steps of a static limit, each requiring a hard fork, then the home-based demographic (which I consider important) can be salvaged.


The hassle of a hard fork is an important feature of the process, not a burden.
Ever wondered why evolutionists cannot wrap their heads about the fact that sexual reproduction consumes that much energy?
Well, here is your answer. Erecting the new 8Mb limit is definitely pointing you in the right direction, Peter R.

I appreciate the compliment.

Regarding the actual 8Mb figure.
The hassle of a hard fork (implied by the idea of a single static limit) should be enough to prevent individual nodes from meddling with the limit (via user-definable option or by recompiling the client), but because of the same reasons (the hassle of a hard fork) we don't want to do that every now and then. So we must future-proof it with regards to the competition and the current state of technology. That's why evolution has stages, it's not a continuous smooth process. You can look at it as a game of Chess as well, if you will. Now is Bitcoin's turn to make a move.

More on 8Mb justifications here.

It's not that much of a technical discussion.
The limit ultimately determines the size of the consensus network.
If nodes cannot keep up, they will be pushed out.

Whether we want to keep our favorite toy or let it slip out of our hands is really up to us.

The limit determines the size of the consensus network.
If nodes cannot keep up, they will be pushed out.

On one hand, operators of full nodes have the right to decide what the limit should be, on the other hand, there must be a single static limit agreed upon via consensus. Otherwise more important full nodes (large miners, exchanges, merchants) might want to increase their limit via user-definable option and begin pushing home-based full nodes out of the consensus.

8Mb is a reasonable middle point for the next 4 years.

With suggested 4-year manual steps of block size increase, we might as well approximate the curve suggested in BIP101, but only for as long as it serves the interests of Bitcoin.

Who decides what those interests are? We do.
The ones who populate the network with full nodes.


Correct.
But only if it's shown to not significantly shift the incentives structure, that has proven to work so well for the original Bitcoin.

"a plaque and platinum status is whack if you're not the baddest"

By the way, I don't think that devs' intentions are anything else than good, but their judgments may have been overshadowed.
They are welcome to finally see the truth and help propel Bitcoin onto the next stage of its evolution.

Let's look at the symbols.

1) Bitcoin XT
Allows the block size to increase exponentially to the point, where home-based nodes will no longer be able to participate in consensus.
Wanna vote yourself out of Bitcoin? Great, this way! Head for the >> (e)X(i)T (check the actual logo).

2) Bitcoin Core
Wants to artificially cap the block size in order to popularize sidechains solution, which by design introduces systemic risks to a single transparent unified ledger, as it intends to take most of bitcoins out of circulation. "Bitcoin Core Released" anagrams to "deliBerate CoeRcions". That doesn't sound very good, does it?

3) Bitcoin as Satoshi created it.
Doesn't have any suffix, prefix or any other strings attached to it. That's the one that has a static limit on block size baked in, but big enough not to limit Bitcoin's growth until it is reached. I argue, that the path of the original true Bitcoin is the one, where static limit is raised to 8Mb.

If we look at the table below from the perspective of a block size increase, we will see one simple truth:

Option              Action               Result
Bitcoin XT       CHANGE           CHANGE
Bitcoin Core    NO CHANGE     CHANGE
Bitcoin            CHANGE           NO CHANGE

Sometimes things need to change in order to stay the same.
Note, that option [NO CHANGE -> NO CHANGE] doesn't exist, that's how evolution is built into the system.

Do we always need celebrity figures to provide it for us, to spoon-feed us everything we need?
How many of you have built the software you are running? The instructions are out there, it's not rocket science.

The path has been shown. Are you the ones to walk the talk?
Time to grow up.

Here.

Why change?

Bitcoin, as it currently stands, has never operated under a permanent EFFECTIVE limit on block size. The original 1Mb limitation put there by Satoshi 5 years ago has not been effective up until recently, but instead smaller soft limits (250Kb, 500Kb, 750Kb) were all hit and raised in order for Bitcoin to continue. This has proven to work and gained value.

Capping Bitcoin at the permanent EFFECTIVE limit of 1Mb is a CHANGE to how Bitcoin has operated for the last 5 years and has no precedents in history and in altcoin space to gauge on the effects of such behavior. Similarly, Bitcoin has never operated under an exponentially growing limit or the one that is being voted on by the miners.

The static hard limit on the block size is the only measure that non-mining full nodes have in order to prevent themselves from being pushed outside of the consensus network by profit-driven miners, which (no matter how benevolent) may have no other choice as to keep increasing the capacity and consolidate in order to break even.

So, we are now in a paradoxical situation, where NOT CHANGING Bitcoin actually means CHANGING THE WAY it has operated all this time. We have simply run out of smaller soft limits that were timely increased in the past and are now approaching the hard limit of 1Mb, which requires a different procedure to continue (hard fork).

---

Why 8Mb?

Despite the fact that many refuse to acknowledge this, Bitcoin isn't alone in the space that it has created for itself. There are competing crypto-currencies based on the exact same principles, that offer significantly larger pre-fork capacity than that of Bitcoin today. As a matter of fact, Bitcoin's closest PoW competitor can handle as much as 4x the transaction volume on a single transparent unified ledger without having to change anything at all.

So, shooting for anything less than an 8x increase will simply jeopardize Bitcoin's position as a leader in this space and won't justify the hassle of a hard fork. Going for the higher limit obviously has drastic implications on network's ability to converge consistently on a single chain, significantly disadvantages Chinese miners and puts existing home-based full nodes at risk of being permanently pushed outside of the consensus network.

It's a game of Chess and now is Bitcoin's turn to make a move.

---

How to proceed with the change when consensus is reached?

As we already have a simple and robust mechanism in place to statically cap the block size, the change to the code must be trivial (a one-line patch) and thus doesn't require an expertise of professional software developers in order to implement. I believe that community has enough members capable of building the existing Bitcoin software and can provide multiple recent versions of the client with the new hard limit (8Mb) baked in.

If you are presented with a binary choice where options (Core-1Mb-forever vs XT-upto-8Gb) are actively being argued and pushed upon, chances are, that neither is the correct solution and the truth has been kept outside of the loop. Vote with your feet, while you are still given that option, but be careful not to vote yourselves outside of the consensus network. You simply won't be able to vote yourselves back in anymore.

---

What does the future hold for us?

The new hard limit will have to be revised in time, probably somewhere around 2020. It can become a good tradition to re-evaluate the grounds that Bitcoin is standing on every 4 years before the halving celebration, assess the competitive landscape and the state of technological advancements (networks, storage, processing), reconcile the issues that are currently on the table and find appropriate solutions to move forward with.

There is no such thing as a permanent solution. Everything changes, everything evolves, everything adapts. There is no alternative to hard work either. It would seem that with recent BIP1xx proposals people simply want to get lazy and have a free ride on Bitcoin's back, while at the same time willing to risk the opportunity and the choice they are given to take responsibility for their own future.

This is your call and your job, bitcoiners. Prove that you, as a consensus-driven community. are worthy to have an invention as brilliant as Bitcoin.

We have been warned.

One more thing, to clarify how important this is.

If consensus network (at any one point in time) shrinks to the size, that ordinary people with home internet connections are no longer part of it, then their opinion will never be asked again. It simply won't matter anymore. The barrier to entry into consensus will simply be too high for them.

The limit needs to be treated with extreme caution.

I'm not saying it's gonna be easy, but the fork only looks hard, because the solution looks too simple.

I can explain, why anything less than 8Mb is not competitive enough to justify the fork, anything more than that is risky for network's health.
If we just get used to the idea, that we need to come together once in a while to make adjustments it will be healthy for the community.

There is nothing more stable and predictable than a static flat limit of 8Mb per block. It's actually the most simple solution to implement as well (the patch is likely a one-liner). If some merchants and exchanges use semi-custom self-compiled clients, incorporating any sophisticated BIP implementation with voting might cause some incompatibilities and forks in the future (remember BerkleyDB to LevelDB switch).

With static limit (8Mb), we will have both an increased (competitive to other PoW coins) capacity and a potential market for fees, which should satisfy both camps if they are interested in finding consensus at all. Besides, statically capped Bitcoin with gradually increasing soft limits is Bitcoin we all know and value, it's the one that is proven to do the job. Why complicate it?

If we survive the fork (by simply raising the limit to 8Mb) and succeed, it will create a precedent for future adjustments.
In 2020 we might look at this issue again and say: "Jumping from 1Mb to 8Mb worked great, let's move to 32Mb this time if the tech allows the network to be healthy".

Security of the network and the idea of there being a network in the first place, depends on how many full nodes there are, how diversely they are spread across the planet and how able they are to handle the load.

5 super-connected super-nodes with 8Gb blocks would technically still constitute a network, but I'm not sure if you want to call that Bitcoin.
We need to address the block size issue responsibly and re-evaluate network's health with regular intervals.


I too still sympathize with the idea of one-off fork to 8Mb. Clean and simple.

Don't you enjoy discussing complex problems and finding efficient solutions to them?
What are we, humans, gonna do, if Bitcoin turns into a mindless machine that does everything for us?
/sarcasm