Topic: Block Increase Controversy - A Way Forward? (Read 788 times)

In regard to this topic, interesting post from satoshi from way back:


Reference

do you know what scalability is? of course it will increase the scalability, because there will be the possibility to move transactions, in a more wider range

you are not stuck with 05-0.9 MB range as it is right now

Kneel in some other forum.
I doubt you will find much non-troll support for such idolatry.

Reasonable debate is almost never harmful; and almost always a requirement of a "free" institution.

---

Frankly, I believe Bitcoin and "crypto" is already in the process of scaling itself

Though, I doubt many of the faithful will agree.

An alternative conceptual understanding of the "altcoin" markets, by Paul Grignon:
https://www.youtube.com/watch?v=XyWfUqEyIZc

The video isn't perfectly on target - but an interesting take none-the-less.

STOP WITH THIS BULLSHIT we must increase blocks !

over!

Increasing the maxblocksize to 20MB is just increasing throughput,  that won't make Bitcoin more scalable in any way.

So rather say : decentralization or throughput.

This post was a suggestion of two main concepts:

1. Forks should not be feared, and need not be feared, if they are expected.
 - They are an important balancing mechanism in the system.
 - They should be implemented, then have consensus applied, as Gavin has suggested, via block version activation.

2. Consensus should be a clean and fair choice. 
 - If there must be a "Core" client, it should be agnostic concerning controversial or priority setting changes.
 - To be fair, such a client should provide the ability for users to easily select which "features"/forks they run/support.
 - There should be no bias in "official" builds or the official client for such possible "features"/forks.

---

In short, make it easy for everyone to make their choice, program it to only "turn on" if a majority of users make that choice, and remove the politics from the actual development commits, labels, and releases.

Politics can and should exist in arguing for user adoption of a given feature/fork.
Politics should not exist via forcing a controversial update into what is regarded as the "official" reference client.

---

That said, Gavin has earned respect for suggesting that if he did move forward with the protocol change, he would do so in his own fork, and not the official reference client.

---

Yes.
This is not an immediate emergency.

It may become so in the mid-term future.
However, better to handle it down the road a ways once need and impetus has forced better alternatives to be explored.

Recommending caution is never a poor course of action.
 

What you are saying is 100% correct... In a emergency situation like that, someone has to take the lead, to get things done. The problem with applying that rule to this situation is problematic.

The general perception is that Bitcoin are not centralized in ANY way... Not just NODE count, but also in the development. They should be represented by a global team of people with NO leader.

If Gavin stepped up to be that guy, we would sacrifice that principle. {Even though the nodes are still decentralized, the "Management" is centralized, and that is NEVER a good thing}

Individuals with that amount of power can be targetted and corrupted. {IMO there should be NO single person with that much SAY, and Bitcoin should still be represented by a global team, with the same weight}

It makes things difficult, but it keep things clean. 

Higher bandwidth requirements lead to a lower nodecount. Next time use a search engine.

Can someone please explain how increasing the block size makes Bitcoin more centralized? I can't seem to understand this, and it doesn't make any sense to me at all.

lol, this thread is so much bullshit i think my brain bleeds.

You're out in the woods with a group of friends sitting around the campfire (drinking bud lite swill), when a group member accidentally cuts off his hand with an axe while gathering wood. You'll notice that in these situations someone always rises up and takes command. If we wait on consensus, the guy bleeds to death. Gavin is stopping the blood - now, he's our designated driver, so let him navigate this ride - this is the natural way.

That is a complete misunderstanding.  Coins will not be doubled.  This is the kind of nonsense that is being spread that Litecoinguy is talking about.  Check out this thread.  There is an interview with Gavin and he explains everything pretty clearly.  It seems that our backs are against the wall and we can not afford any more delay on the issue.  That migh tbe why Gavin is being so aggressive:  something needs to be done soon or we will have real problems

yeah, lots of drama and debate over fork vs anti-fork, im content to sit and wait to see what the community will lean towards in the near future. I think many will lean towards the fork though, something about doubling your coins or something i dont understand.

i guess i have to leave this forum for some days. I can't take it any longer. all threads are full with this shit about a fork...and the worst part: most infos about this are wrong 





.......okay....i will stay 

I was gonna say that too.  I think that the increase in block size is a temporary solution to a problem that needs to be solved.  However doing nothing is worse than upgrading the block size.  It seems pretty obvious that the upgrade is needed as it will take some time to implement and there seems to be no legit alternative out there.

I was going to say this, that it isn't a problem since people vote by running nodes, but maybe OP means something else that I don't understand.

Didn't Gavin already said he would never do the hard fork unless 90% (super majority) is reached? if this premise is right, I dont really see the big fuzz all over this. People is still deciding and it's still as decentralized as ever, the devs can't force you to run XT or Core, the majority wins.

Possible alternative way forward, concerning simultaneous variations in the core Bitcoin client:

- Super-Majority(90%?) to initiate forks via rolling window.
- All tested and implemented BIPs are compiled/tagged for release immediately.
- Users(Miners) select the protocol/feature set they agree with.

Poor Example for Illustration:
http://jqueryui.com/download/

---

- All possible outcomes are fairly "allowed", given support.
- Forking(improvement) becomes a fact of life, and is thus prepared for and monitored.
- Ossification of the protocol ceases (similar to proposed "yearly" forks).

---

This has almost certainly been previously suggested, but thought it might be an interesting discussion considering the recent controversy concerning BitcoinXT and Gavin's possible exodus from core development.