Quote from: poeEDgar on September 03, 2015, 10:54:49 PM

I've stated pretty clearly why no one should run that code. It's reckless and completely lacks technical forethought. And neither Gavin nor Hearn will address legitimate criticism from the community nor update their code to reflect it.

I do not see what is so reckless about running Core with a BIP101 patch, since that is all that it is. BIP101 being a proposal with the Core client after all. Unless you are refering to the scedule of the blocksize increase which is a fair critisism. I would adopt a middle ground between these extremes as soon as it becomes real, even if it is because Core capitulates and increases the block size. https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

Quote from: VeritasSapere on September 03, 2015, 11:07:31 PM

Quote from: poeEDgar on September 03, 2015, 10:54:49 PM

The Core team however will not even give us a definitive time line for when they plan to increase the block size, so trusting that Core will increase the block size is just that, trust.

This has nothing to do with whether bitcoin is trustless. It's just a red herring. This is a controversial issue and I see no problem with Core devs refusing to throw their weight behind Team BIP100, Team BIP102 or Team BIP103. The emphasis should be on finding a robust solution that can achieve consensus, not panicking on the basis of unwarranted urgency and implementing a "fix" that could end up crushing confidence in bitcoin.

I never said that this had anything to do with the trustless aspect of Bitcoin and it is therefore not a red herring. Choosing an alternative client should be a way for people to express this consensus and how ultimately consensus should be reached as well. The consensus of the Bitcoin network should not be synonymous with the consensus of the Core development team.

I do think that some urgency is warranted, since if there is a significant global event it could possibly lead to a spike in adoption, then the network would become overloaded. the consequences of this would seriously hamper adoption and public perception. It would also not be good to do a hard fork at short notice when this does become a problem since that would lead to a situation that would be much more chaotic and confusing, and might indeed "crush" confidence in Bitcoin for many people.

Quote from: VeritasSapere on September 03, 2015, 11:07:31 PM

Quote from: poeEDgar on September 03, 2015, 10:54:49 PM

I do believe that a block size increase is necessary, therefore it does logically follow that I should support the first proposition to do so.

In the absence of an acceptable solution, the status quo is the only acceptable solution. That doesn't mean the debate is over, but that it is irresponsible to back code that is a) severely untested, b) necessarily completely untested in environments that are remotely similar to those that are hard-coded (conceivably, we can test a 2MB block regime in a .5MB environment -- can we test an 8GB block regime in a .5MB environment? no, that's insulting), c) peer reviewed by one person, d) lacking in technical explanation for the basis for its scaling schedule (why Moore's Law?) or how we can assume that all forms of technological throughput will improve at the rate of (or faster than) the exponential scaling schedule in BIP101, e) the list goes on but I don't have time for this.

I do not think the debate is over. I am looking at this from a realist political perspective. We have a choice, you can vote for an increased blocksize or you can vote to keep it the same. I think that keeping one megabyte blocks forever would be very bad for Bitcoin from my ideological perspective, I am not saying that this is the position of the Core development team, irregardless however they do not have a plan in place to increase the block size now. So being forced between these two extreme choices I choose BIP101, but I appreciate that I do have the choice, the very existence of BIP101 is acting as a catalyst for change as well, and like I said I would adopt a proposal that would represent the middle ground between these two extremes as soon as it becomes reality.

I also believe that when you look at this problem from a philosophical political perspective you can get a different answer compared to looking at this from a purely technical point of view, and in my opinion the technical ideal needs to be compromised for political goals. It might be true like you say, that some of these things can not be tested. This is true, but because they are unprecedented in history, that is why it is inconceivable to attempt to factor in all of the variables into mathematical models. It would make more sense to stay true to the philosophical principles that make Bitcoin what it is while keeping a grounding in the technical realities to help guide us through its evolution.

Quote from: VeritasSapere on September 03, 2015, 11:07:31 PM

Quote from: poeEDgar on September 03, 2015, 10:54:49 PM

Right now we only have two choices, and even if it is a choice between the lesser of two evils, we do still have to choose.

No, we don't.

As a miner and a full node operator I do have to choose, you literally can not do these things without casting a vote to either side, therefore it is impossible to be neutral under these circumstances.