Quote from: JayJuanGee on July 02, 2016, 02:34:39 AM

Quote from: franky1 on July 02, 2016, 02:26:05 AM

Quote from: JayJuanGee on July 02, 2016, 02:05:40 AM

Quote from: franky1 on July 02, 2016, 01:42:41 AM

Quote from: JayJuanGee on July 02, 2016, 01:21:47 AM

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/395521854efd5804433d57aaf69f46676e4b6efc
needs 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

Still seems premature to me for you to assert that the proposed code language is going to be a hardfork in the way that you describe it. I will believe it when I see it. So far, even though you seem to be stretching the speculation in such a way to assume facts that have not happened, yet, you are not really saying anything much different from me. So, yeah, anyone can make a proposal, and if the proposal is hostile to Core, then maybe Core would be hostile to Luke Jr; however, if the code is merely a proposal, then there may not be any reason to be hostile to him for making a proposal that can be weighed and considered by core.

On the other hand, if Core were to release code, then yeah, it has been vetted by various PTB within core in order to suggest that it is already an endorsed version. In any event, it seems that you are getting ahead of yourself because we would need to see the extent to which the code is hostile to core and whether the code has any persuasive power in terms of either changing core or causing others to defect from core's code or vision.

Besides voluntarily bringing activation to 90%, miners could soft limit themselves to producing <1MB for as long as they wanted... thus bringing about a change, but not a fork, until they felt the economic support had formed.