Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

From: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
To: Jared Lee Richardson <jaredr26@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
	CalvinRechner <calvinrechner@protonmail•com>
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
Date: Fri, 2 Jun 2017 17:57:12 -0400	[thread overview]
Message-ID: <CAKzdR-om+A1wrPSPTNT6AqtZjEw3hqjWKjgDoAQwggDYF3PH+A@mail.gmail.com> (raw)
In-Reply-To: <CAD1TkXtHmcZHGcOR3RiLhh8orB0L7Tn=yEwPLhrAZyS+qr-GZw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 10147 bytes --]

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 <https://protonmail.com> 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 <calvinrechner@protonmail•com>
>> Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
>>
>> >>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
>
>

[-- Attachment #2: Type: text/html, Size: 14180 bytes --]