Lets say hypothetically we both support BIP103 and so does the economic majority, we would most likely still need to go against the "developer consensus" of Core. In order to have it implemented. This of course changes when or if Core changes their tune, though presently that does not seem to be the case. Surely there would even be a limit to your patience in regards to increasing the blocksize, even if just hypothetically, since we can not predict the future.
So you are suggesting the developers can never find consensus with any modest scaling proposal ?.. Segwit is already proving you wrong there... but good thing the developers are irrelevant when it comes to deciding on increasing the blocksize anyways , they just write the code... and this is what you don't seem to understand ... the reason the miners haven't agreed with 101 or Xt is because they don't agree with it and think its too aggressive. They respect the developers opinions because they aren't obtuse and are very knowledgeable in the incentive structures and risks with scaling themselves.
Miners are the ones that hold the majority of the power. Right now I see up to 5% hashing power possibly supporting XT.
I am not saying that the developers can never find consensus I am saying that they have not found consensus so far. I do not believe Segwit has proven me wrong since it is not going to make any difference whatsoever over the short term, and over the long term the gains are insignificant. After all, blocks are presently full and Core does not have any definite plans in place to increase the blocksize.
I believe it is the economic majority that holds all the power. The way this works in practice is not well understood by most people, it can also not be simplified in such simple terms as you have put it. It is a difficult position that the miners are presently in, and in regards to you thinking they have rejected BIP101 for good I think it is to early to know this, not that I am even in a position to know such a thing and I doubt that you are in such a position yourself, though of course I do not know who you are so you might have access to this type of insider information.
It is also good to keep in mind that the feedback loop for Bitcoin governance is very slow, and without an abundance of well respected alternative implementations, this governance mechanism is still incomplete. This situation is changing rapidly however, in the long run I am confident that the original vision of Satoshi Nakamoto will triumph.
While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.
Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section Cool to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.
The eventual solution will be to not care how big it gets.
But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore.
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users.
It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.
Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
