I agree with raising the blocksize, but not by such a large increment. If BIP101 was simply altered to curtail the increases it would be much more likely to gain support. Chances are, most people are going to get behind a 2-4-8 increase, which seems far more prudent than 8-16-32. Personally, I'd still like to see dynamic, smaller adjustments on a more frequent basis, like every week or two if required, but the idea doesn't seem to be gaining much momentum. If I could code, I'd start an altcoin to
test this idea out. Would love to see it in action (with or without the voting part). I guess it's more complicated that way, so less appealing as a result. People seem to like whole numbers and simple concepts, so we'll probably end up with static limits. Such strict rigidity worries me a little, but being stable and predictable is important too.
I actually agree with you, I only support BIP101 until a better alternative is implemented. It would indeed be good to have BIP101 itself curtailed I would absolutely support such a change, I also think that this would help with gaining support overall.
How does that explain why you've been using dozens of demonstrably false arguments in favour of BIP101? Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB), that will invoke highly significant changes in the characteristics of the network dynamics that you claim to be a student of?
My arguments have been completely consistent. If you can find contradiction in what I have said please point it out to me and I will thank you for it. I have always said that I would most likely support a third alternative implementation especially if it strikes a middle ground between these two extreme choices we have today.
Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB)
Surely the more pragmatic approach would be to see what the average connection and bandwidth availability is later when we're approaching 8MB and have the
option to keep going
if it's safe to do so?
I agree, but that's baked into a 2-4-8 cake anyway. If 8MB was reached as you say, then the option still exists via hard forking again. Except if you're running a post-fork XT network; the hard forking mechanism can't be used once Mike's proposed blockchain checkpoints get introduced.
(another mindless XT argument debunked; they constantly claim that hard forks are possible using the proposed XT codebase, when XT has been re-designed to prevent any further hard forks)
Saying that we can not hard fork again after XT is complete conjecture, it is absolutely just not true. If that was true I would instantly become an opponent of XT lol. I have listened to the interview where he discusses checkpoints, you are just completely taking what he said out of context.