I do not trust them to increase the block size, that is why it should be implemented by an alternative client. Unless the Core devs increase the blocksize, I will not trust them to do it.
I don't trust Gavin/Hearn to implement anything, since the basis for scaling in BIP101 is Moore's Law (unproven, unscientific, failing) and nothing more than the baseless assumption that we can address issues of scaling on an exponentially increasing schedule. Literally, the only answer provided to questions of delayed block propagation times is that "technology gets better over time." Never mind the basic premise in large scale systems that conditions in small scale =/= conditions in large scale, and how this basic oversight could force us to fork the limit down after a serious security lapse. One cannot test a regime in a .4MB block environment and simply assume that it is stable in an 8GB block environment.
We are simply supposed to believe that "technology gets better over time, therefore exponentially increasing block size limit presents no threats to bitcoin."
Pfff.....
If you believe a block size limit increase is necessary, it doesn't logically follow that you should accept the first reckless proposal that comes along.
You do not need to trust Gavin and Hearn, they have already released the code and everyone can see for themselves what is in there and what the schedule for the increase will be.
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.
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 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.
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.