For a larger block size limit, we should focus our efforts on convincing miners + developers that raising the blocksize limit much higher should be a priority.
what if i told you . . . that if all nodes in the network used clients with BU-like architecture, there would be no block size limit?
no, but seriously, we have to believe that BU's approach to the issue is the correct one. namely, there is no hard set blocksize limit, there is a soft limit that corresponds to the known capacity handling limitations of the software. if we do believe that this is the correct approach, then we need to rephrase the discussion. it is not about raising the blocksize limit. it is about optimizing the software. in so doing, we remain competive with other implementations, and to the extent we are successful, we participate in the steering of the protocol.
while we are rephrasing, perhaps norway's BUIP should have been about allocating budgetary resources to pay for capacity optimization.
on another topic: right this moment we have: coingeek 23.61%, BMG 13.19%, okminer 13.19%.
it is quite obvious okminer is acting jointly with the other two: it splits hash with BMG, and together they make up 49.99% of the network, which surely is no coincidence.
one also gleans they could add extra hashpower, not deployed yet so as not to be in control of the majority.
something large is afoot. it seems to me a mistake to ignore this fact based on a condemnation of intellectual dishonesty, or failing to keep promises, or resorting to obfuscation.
EDIT: i neglected to add SVPool, 9.03%. dang.
