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