I don't see LukeJr 2MB limit to be compatible with the NY agreement. For the rest, seems fine for me. On Fri, Jun 2, 2017 at 4:13 PM, Jared Lee Richardson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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. > > Jared > > > On Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> In principle, there is complete flexibility when it comes to the specific >> consensus details of the hard fork. One common suggestion has been to phase >> in a gradual blocksize increase beyond the initial 2MB cap included in >> Luke-Jr's proposal (a la BIP103); this would certainly be a welcome >> inclusion in the Omnibus Proposal, provided that is what we want. The >> reasoning behind incorporating Luke-Jr's 2MB limit and discount-rebalancing >> was to satisfy the conditions of the Scaling Agreement while ensuring >> maximum safety, minimum code discrepancies, and minimum controversy among >> the community; these priorities seem imperative, considering the extreme >> timeline constraints we are working under and the goals of the proposal. To >> put it more simply, the intent of the proposal was to serve as a template >> for the minimum viable fork that can achieve true consensus. A gradual >> increase to a larger size cap, especially if it were reasonably >> conservative, would be wholly in accordance with the Omnibus Proposal if >> that is what it takes to achieve the cooperation between community, >> industry, and developers in this critical moment of Bitcoin's history. >> >> >> The purpose of the Omnibus Proposal is singlefold: to achieve the goals >> of the Consensus 2017 Scaling Agreement in the most maximally-compatible >> way. We can minimize disruption and loss potential all around by solving >> these problems in a compatibility-oriented manner. It is possible to >> fulfill both the letter and the spirit of the Scaling Agreement, to the >> complete satisfaction of all involved, while preventing chain-split risks >> in the meantime. >> >> >> There is no justification for incompatibility with existing deployment >> approaches, when there is the possibility to work together towards our >> mutual goals instead. The most rational option is to join forces and avoid >> any chain-split potential for as long as possible. Under the Omnibus >> Proposal, once SegWit is activated, the terms of the hard fork are locked >> in automatically, set to activate 6 months later. The proposal guarantees >> that a successful SegWit activation is followed by a hard fork. Beyond >> enforcing the hard fork rules beginning at block height HardForkHeight, the >> Omnibus Proposal simply represents compatibility with the existing >> SegWit-activation deployment approaches. >> >> >> By committing to this proposal, we can ensure unity, at least for now. >> There do not appear to be any arguments to the contrary. Why squander this >> opportunity for consensus and harmony? We can leverage the momentum of >> several disparate movements, and perhaps enjoy some much-needed social >> solidarity. In a way, everyone can get what they want, and through >> cooperation, we avoid the risk of a costly fracture. >> >> >> The Segwit2x Team has begun work on an implementation of the Consensus >> Scaling Agreement, their operational timeline including the publication of >> a BIP on June 16, 2017.[1] I call upon the developers and maintainers of >> this initiative to consider and honor the Omnibus Proposal, extended or >> modified as needed, as the guiding approach to your development effort. >> Almost every component of the code exists, in some form or fashion, in the >> various constituent proposals' reference implementations, most of which >> have already undergone a significant degree of peer review. >> >> >> We cannot afford to delay, nor to reimplement; the launch timeline is >> aggressively optimistic as it is. The quickest and safest approach to >> achieving the goals set forth at Consensus 2017 is to leverage the existing >> tools and proposals for the job. We can solve our problems properly, >> cooperatively. >> >> >> I humbly ask that Jeff Garzik, Barry Silbert, Mike Belshe, and all of the >> other wonderful, intelligent collaborators on this project step forward and >> support the cooperative, compatibility-oriented approach of the Omnibus >> Proposal. >> >> >> This is the best way to maximize value for everyone. We have a real >> opportunity to collaborate and work together on the same team. The Omnibus >> Proposal, designed in exact accordance with a powerful industry agreement >> and incorporating the feedback and suggestions provided from within both >> the developer community and the community-at-large, stands the best chance >> of uniting everyone under a common front. >> >> >> Please, for the love of Bitcoin, let us do our best to cooperate. >> >> >> >> [1] https://imgur.com/a/a2oPs >> >> >> Sent with ProtonMail Secure Email. >> >> -------- Original Message -------- >> Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal >> Local Time: May 29, 2017 6:49 PM >> UTC Time: May 29, 2017 11:49 PM >> From: opetruzel@gmail.com >> To: CalvinRechner >> Bitcoin Dev >> >> >>if the community wishes to adopt (by unanimous consensus) a 2 MB block >> size hardfork, this is probably the best way to do it right now... Legacy >> Bitcoin transactions are given the witness discount, and a block size limit >> of 2 MB is imposed.<< >> >> >> 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. >> >> Am I missing something here, or does Luke's suggested 2MB cap completely >> nullify that expected linear increase? If so, why? What's the logic behind >> this decision? >> >> I'd love to be armed with a good answer should my colleagues ask me the >> same obvious question, so thank you ahead of time! >> >> Respectfully, >> Oliver Petruzel >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >