Can't we see what Luke Jr. releases first?
I doubt that Luke Jr. is going to include hardfork language in the coding unless it appears that there is consensus for such... I thought that Luke Jr. already pretty much said that a hardfork would not be necessary in order to implement a 2 mg increase in the blocksize limit, so long as there is consensus for such protocol changes? And, even right now, there doesn't even seem to be any kind of consensus that an increase in the blocksize is actually needed prior to seg wit going live for some time.
luke JR was explaining that segwit has changed the parameter. there is no longer a MAX_BLOCK_SIZE variable in segwit
(well its there just renamed)
instead segwit is set as MAX_BLOCK_SERIALIZED_SIZE = 4000000 (all data tx and signatures)
but to not break consensus and cause a hard fork, segwit works by separating the tx and witness
this is done by
MAX_BLOCK_BASE_SIZE = 1000000
meaning traditional transactions(full tx of nonsegwit) and the non-witness(tx part of segwit) fits into MAX_BLOCK_BASE_SIZE
leaving 3mb spare for the signature area.
in short/layman MAX_BLOCK_BASE_SIZE is the same as MAX_BLOCK_SIZE
now to increase the capacity for traditional transactions is to increase the MAX_BLOCK_BASE_SIZE to 2000000
this will however need consensus because it is a hardfork(basically its the same as other imps increasing MAX_BLOCK_SIZE to 2000000)
for luke to forfil his agreement as a *cough*"independent core contributor"*cough* he has to release code for the MAX_BLOCK_BASE_SIZE=2000000
currently this (MAX_BLOCK_BASE_SIZE=1000000(1mb hard block))
https://github.com/bitcoin/bitcoin/commit/395521854efd5804433d57aaf69f46676e4b6efcneeds to change
Likely I will need to accept your representations regarding some to of these technicalities, but still my point stands that we would need to see the code that is released before your earlier propositions would even come into play.
Accordingly, none of the individual developers can bind core, but yeah, they are free to make various code proposals, and whether consensus can be achieved regarding code language may suggest what reasonable next steps would be taken. Even the author of a code could chose to amend his code if others suggest that there are problems with the code, so suggesting that Luke Jr would be insisting upon either a hard fork or an alt coin spin, seems to be considerably premature.
In fact, developers may have fairly intense disagreements regarding what are the problems, if there are problems and the importance of various proposed solutions, so even if one developer takes a fairly strong position concerning what he perceives to be a problem, he may also change his mind regarding the degree or extent of the problem and whether the proposed solution is a reasonable measure in respect to the problem.
So, it makes little sense to me, to attempt to lock in positions, and even describe hostilities and combativeness between developers when the assessments about problems and solutions are works in progress, and code proposition (by Luke Jr.) has not even been released yet. He could also release his code with a lot of passion and advocacy for such code or he could release it without taking a strong stance in regards to his beliefs regarding the code as a one size fits all solution.
well the code changes are simple. but the ultimate "idea" is that its not going to be a bitcoin-core release. but code on luke Jr's personal github.
literally making it an independent non-core release just like BU, XT, classic and the several other non-core implementations.
so the overall decision is, accept the harkfork because luke is more trusted "independent" coder.. or.. vilify luke the same way as the other non-core implementations