> The above decision may quickly become very controversial. I don't think it's what most users had/have in mind when they discuss a "2MB+SegWit" solution.
> With the current 1MB+SegWit, testing has shown us that normal usage results in ~2 or 2.1MB blocks.
> I think most users will expect a linear increase when Base Size is increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. With normal usage, the expected results would then be ~4 or 4.2MB blocks.
I think Calvin is correct here, the secondary limit is not what people anticipated with the segwit + 2mb agreement. It would not kill the agreement for me, but it might for others.
What is the justification for the secondary limitation? Is there hard data to back this? The quadratic hashing problem is frequently brought up, but that is trivially handled with a hard 1mb transaction limit and on the other thread there's talk/suggestions of an even lower limit. Are there any other reasons for this limitation, and is there data to justify those concerns? If not, this should be left out in favor of a transaction size limit. If so, hard data would go a long way to dealing with the conversy this will create.
> Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to:
> > cause the existing "segwit" deployment to activate without needing to release a new deployment.
> Both of the aforementioned activation options (“fast-activation” and “flag-day activation”) serve to prevent unnecessary delays in the network upgrade process, addressing a common criticism of the Scaling Agreement and providing an opportunity for cooperation and unity instead.
This is likely to cause more controversy and unfortunately has the tightest timelines. Unlike the SW2mb working group's timelines, a hard-coded timeline couldn't be changed with mutual agreement from the signers.
Given the chance of bit1 accidental activation without clear signaling for the required bit4 2mb hard fork, I don't think the fair or acceptable tradeoff is for flag day to require bit1 signaling only.
Flag day should be modified to accept either bit1 signaling, OR to accept bit4 signaling IF the 80% threshold hasn't been met. In this way the anti-segwit working group members are not in danger of an activated bit1 segwit without also getting their portion of the compromise, the bit4 signaled HF. If flag day accepts bit4 OR bit1, AND bit4 requires both bit1 and bit4 once 80% is reached, flag day is nearly guaranteed to get its stated desire within 1750 blocks (bit4 accepted until block 800; bit4+bit1 signaled afterwards until 95%), but without the chance that the WG signers won't get what they agreed to.
That seems like a minor compromise for BIP148. Thoughts on this change to flag day / BIP148?
In addition, the aggressiveness of the timelines and the complexity of the merged COOP proposal may require the BIP148 flag day to be pushed back. I would think some day in September is achievable, but I'm not sure if August 1st will be.