I was in the Gavin-train for a good period of time, but recently I have come to the conclusion that I was a bit wrong and that the Core is currently on the right track. This doesn't mean that I will support them no matter what, but trying to find out if my choice is good or not I am constantly trying to find a weak spot by asking myself questions and then searching for the answer. I will apply that to your post too in order to have some constructive discussion.
Core working on the code doesn't mean only power to do whatever they want. They are also responsible and accountable if something goes wrong. If we get to a point where the blocks are always full it is their responsibility to manage that situation. If they will not be able or if they won't do anything then everyone else will simply fork the code, change the blocksize limit to whatever they agree upon as long as it is bigger than 1MB and they will do anything in their power to continue using bitcoin the same way as they did before. Remember that it only takes one single line to change the blocksize and that is something that everyone can do so we don't depend on Core to do that.
The rage will start from the normal users who will simply reduce their number of transactions and that will impact everyone. If everyone will be impacted by the reduced number of transactions then they will take measures and the easiest way is to simply fork the Core software, bump the blocksize limit with one single line of code.
I think its good to have alternative clients though that enable a way to 'vote' on changes in a real way (rather than in reddit and forums with no real polling methods). AFAIC, I want classic to succeed in creating a fork (or at least signalling >50% hashrate support as a signal to core devs that perhaps segwit alone isnt sufficient) to a simple 2MB blocksize and otherwise identical to BTC-Core (0.12 or anything that comes after)
How would voting work? Based on what? Are we able to have a fraud proof voting system?
besides a modest 30-50% space gain through segwit that takes a few months to really be noticed, i think we will start seeing a lot of full blocks and rising fees soon. at this point, fees are already moving above what spam transactions would pay, and if this continues it will start to push out microtransactions and make important transactions more costly. without a maxblocksize increase at that point, it basically forces bitcoin users into blockstream-designed sidechains under imposed economic conditions, rather than through appealing natural improvements/benefits that the blockchain cant provide (like 1min validation)
I have learned that the wheels of change from an ecosystem move slower and slower directly proportional with its size. Since bitcoin is today much bigger than it was 5 years ago it will take a bit of time for the wheels to turn when blocks will be full and the fees will start to rise. Fortunately we already have a solution to that here and now (SegWit) which also opens the door for new improvements and buys us time in order to deploy a bigger and more complex solution (like the hardfork).
http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork 2mb is not a simple one-line change, and the implementation used for btc/classic is about 900 lines, based largely on coding crafted for XT. A lot of that is simply testing code, but even the core change of 2mb is almost 20 lines:
The first commit is “Minimal consensus/miner changes for 2mb block size bump”, and is small – under twenty lines of new code. You can see the one-line change of MAX_BLOCK_SIZE from 1,000,000 bytes to 2,000,000 bytes; the rest of the changes are needed by miners so they know whether it is safe to produce bigger blocks.
a node can easily do the 1-line change and it will accept and relay blocks <2mb, but most other nodes will see it as invalid and not relay them, hence making mining >2mb infeasible. Thats why it makes sense to include a "trigger" so that the client only accepts <1MB until the 2MB rule change is implemented. Otherwise XT would have made a few dozen 1-2 block chainforks already (before switching back to the main longest chain). The consensus mechanism only ensures that the 2mb fork will be successful when activated 28days after 75% majority.
As for core; I like thier roadmap. segwit has benefits to offer but they may be smaller and further away then currently anticipated, in the face of a growing network. Other improvements of the code that are planned are also generally quite good, but without an actual blocksize scaling event its easy to envision a path where blockstream is dedicated to making bitcoin a high-fee settlement layer with massive segwit sideblocks that power sidechains and lightning. Its a good direction, but I disagree with limiting bitcoin in its infancy to a 1mb limit that has gone without incident for years around improved computing and networking, particularly as it makes blockstream's business model more attractive
I firmly beleive in segwit+2mb and i think theres a developing similar consensus. in fact, segwit could make 2mb blocks much simpler by removing the complex validation needs of a small-but-many-signatures transaction.
I think its good to have alternative clients though that enable a way to 'vote' on changes in a real way (rather than in reddit and forums with no real polling methods). AFAIC, I want classic to succeed in creating a fork (or at least signalling >50% hashrate support as a signal to core devs that perhaps segwit alone isnt sufficient) to a simple 2MB blocksize and otherwise identical to BTC-Core (0.12 or anything that comes after)
How would voting work? Based on what? Are we able to have a fraud proof voting system?
its quite simple, you can identify your client (such as classic-0.11.2.b1) and you can view node count at
https://coin.dance/nodes (IIRC they filter out nodes if they detect multiple on a single address (ie: someone pretending to run 10 nodes on one computer)). If you are a miner, you can follow BIP009 to include a modified versionbits, or you could simply include a message or code in the coinbase transaction (almost every miner out there does this already, and many even include BIP100 voting tags)
hashrate is pretty much the most secure method of voting as it requires control over bitcoin mining. Of course, only miners can vote this way.
