Quote from: coalitionfor8mb on September 18, 2015, 02:39:34 PM

Haha!

"stay in 1" -> (stain)
"go for 8" -> (gr8)

Gr8ness Awaits!
(psheyshtation)

For those of you wondering what to think of leftovers in the above.
Let's take a look.

"stay in 1" -> (stain) + (y 1) -> "Why One?" -> "Why Alone?" -> "Go out and create and bring all things back to me!"
"go for 8" -> (gr8) + (foo) -> "metasyntactic variable" usually comes with "bar" -> "raising the bar!" <- sounds gr8!

Quote from: DarkHyudrA on September 18, 2015, 06:34:41 PM

Quote from: adamstgBit on September 18, 2015, 02:17:39 PM

whats disheartening is seeing how poeple are so afraid of the tiniest changes, bitcoin development grinds to a halt.

Even if people make a hard fork to 1.5MB, it wouldn't be tiniest of changes.
Stopping mining pools to run a new daemon is easy and all, but the problem is that the world wouldn't update all at once, and the whole Bitcoin "ecosystem" would have a temporary problem with the "2 blockchains".

That's why 1.5 or 2 or even 4 are not the options for the hard fork, as they simply won't justify the hassle.
Small limits like these would already begin alienating home-based full nodes due to the increased load, but won't provide enough commitment to handle larger user base. That's why they won't "resonate" with the whole ecosystem and agreeing on them will be problematic. They are not "stable orbits" in that sense.

There are two ways to approach this.

1) Stay with 1MB blocks long enough and let the technology advance to the point that jumping to 8MB (for example) would still allow full nodes to continue running on home networks. There is a chance, however, that other similar systems become more attractive as the time passes and there will be no reason to bother with the changes at all. That's where Bitcoin stops being the master of its own game.

2) Jump to 8MB (as a new limit) in the near future and let the internal competition figure out the appropriate block size. This may alienate home-based full nodes during the transition stage, however, due to the increased potential to handle larger user base and therefore higher overall value (market cap) of the network, people who are committed to running a node should still be able to afford it (using other methods: cloud services or dedicated servers).

In general, there is a need to have a static limit in place as a common background representing the interests of the whole ecosystem, as it allows to keep the costs of running a node manageable and therefore provide enough validation for blockchain rules. However, if the rules are compact and simple enough, people might just want to keep them in their memories and associate them with the brand, in which case only one (single!) honest validator (or full node) would be enough to keep the integrity of the whole system intact, but since the costs of doing that are manageable (thanks to a static limit) there will be many (validators).

The risk of pushing the home-based demographic of full nodes out of the system resides in the potential, that the new static limit doesn't last very long and a few large and most active players in the ecosystem collude to keep raising it, while pushing more and more smaller players out of the validation field. The only reasonable way to prevent that is to bake the new limit into the brand itself for at least half a decade and ensure that people are aware and responsible for their actions in choosing a complying full node (or any other service) when transacting in the network.

In order words, if even your cat knows that Bitcoin is capped at 8MB per block till at least 2020, then you can rest assured that the network is holding up nicely.