Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E424B8E for ; Fri, 2 Jun 2017 21:57:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9827E13D for ; Fri, 2 Jun 2017 21:57:53 +0000 (UTC) Received: by mail-qk0-f169.google.com with SMTP id y201so69616933qka.0 for ; Fri, 02 Jun 2017 14:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=68EpzLGjCWBJ7B6eBcrCLNDXBjpHXyUebi7J4+C++9E=; b=Wzk4Gx9aoghULKNH7MJB2s/9jIbJzMxmszhDPpRnKgcFjzps2jgSNXZH53jvUTwAnF H4zlqStRGSsphsf+5oo02UYOR0vryAvpznlCw7huDN9ELw58VXXbqcBMSzBeZlMPkFK4 Hl8mbSFpfO2ZPmrjfAq8rMT572HFBQ4plwtQ07Fs+8WpmkOMlZua/UXpt/8gVy/2FZrM F/B9jPCqbDj2VwhIwKYTcbV5Yud2shP6u+hiK/VL2lVmQH8V2OVG4sY1jm3fJhBja3K5 Hvr2/qZU1TbObLhnKve+OMZ7Dgb+R1Y9jvb+xz51Yru6tAlt4W/O0aopsLvy6qaoOXkd 4AQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=68EpzLGjCWBJ7B6eBcrCLNDXBjpHXyUebi7J4+C++9E=; b=fXwgDm9tTwR+TRKewRfSROPwPfT9DyCAo7JXWuokpzzZcXopsFLVhXp8taR/yNYCkM 07eYvk8nnUIwsAWI9MokvKg6kUJQPommAAQI/fNBq7R/QY0m1VNcQBciv+I5TH8ceEjK ex5PtpPLm+/fvQjF6YxJtGkbQYQSrN2yMJPrDcSEyN09tdSfalrYw2zPpDaJCiZ3oAmI YduG8R4y56O0LxkbsTp5aXBtnhvjWyo0JNJTRLxDP9lQK8GktW6nurDnESAF5o8sp4FL d09xgseDNJku5H4pNWGkcKXvoltTm7lxUp4DCCI6Up+LNiB/xugcuup5C2W+BQZuHBRy 4+GQ== X-Gm-Message-State: AODbwcA51eKhnxbKujL+x7JvIAYMGZTx+v0o9ff8rfxjaOMuBYg69zmk cQlUe0kJUrTz7rCZY9HCGQ8366R4Rsom X-Received: by 10.55.186.132 with SMTP id k126mr11456891qkf.243.1496440672786; Fri, 02 Jun 2017 14:57:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.150.249 with HTTP; Fri, 2 Jun 2017 14:57:12 -0700 (PDT) In-Reply-To: References: <-r9BgtNAp6_SNVwmPiOER08eMpERnuWioUbNVIQJhyIas29hC5VpWmWP5z4hcC8xtWcAPcFqyxNl9I0Ile6mpY8-ZuHr8jxERXKXKo8WYQE=@protonmail.com> From: Sergio Demian Lerner Date: Fri, 2 Jun 2017 17:57:12 -0400 Message-ID: To: Jared Lee Richardson Content-Type: multipart/alternative; boundary="94eb2c043626ba9e4c0551013eee" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , CalvinRechner Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 21:57:55 -0000 --94eb2c043626ba9e4c0551013eee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 u= p, > but that is trivially handled with a hard 1mb transaction limit and on th= e > 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=E2=80=99s =E2=80=9CMandatory activation of segwit deploymen= t=E2=80=9D[3] is included > to: > > > cause the existing "segwit" deployment to activate without needing to > release a new deployment. > > Both of the aforementioned activation options (=E2=80=9Cfast-activation= =E2=80=9D and > =E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary delay= s in the network > upgrade process, addressing a common criticism of the Scaling Agreement a= nd > 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 fo= r > 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 bi= t1 > 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+bit= 1 > signaled afterwards until 95%), but without the chance that the WG signer= s > 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 th= e > 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 Augu= st > 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 specifi= c >> consensus details of the hard fork. One common suggestion has been to ph= ase >> 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-rebalanc= ing >> was to satisfy the conditions of the Scaling Agreement while ensuring >> maximum safety, minimum code discrepancies, and minimum controversy amon= g >> 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 templat= e >> 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 risk= s >> 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 avo= id >> any chain-split potential for as long as possible. Under the Omnibus >> Proposal, once SegWit is activated, the terms of the hard fork are locke= d >> in automatically, set to activate 6 months later. The proposal guarantee= s >> 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 th= is >> 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 t= he >> 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 exist= ing >> 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 th= e >> 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 Omnib= us >> Proposal, designed in exact accordance with a powerful industry agreemen= t >> and incorporating the feedback and suggestions provided from within both >> the developer community and the community-at-large, stands the best chan= ce >> 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... Legac= y >> Bitcoin transactions are given the witness discount, and a block size li= mit >> 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" soluti= on. >> >> 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 byte= s. >> 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 behi= nd >> 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 > > --94eb2c043626ba9e4c0551013eee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't see LukeJr 2MB limit to be compatible with the= NY agreement. For the rest, seems fine for me.



On Fri, J= un 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 n= ormal 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 T= otal Weight is increased to 8000000 bytes. With normal usage, the expected = results would then be ~4 or 4.2MB blocks.

I think Calvin is c= orrect here, the secondary limit is not what people anticipated with the se= gwit + 2mb agreement.=C2=A0 It would not kill the agreement for me, but it = might for others.

What is the justification for the secondary limita= tion?=C2=A0 Is there hard data to back this?=C2=A0 The quadratic hashing pr= oblem is frequently brought up, but that is trivially handled with a hard 1= mb transaction limit and on the other thread there's talk/suggestions o= f an even lower limit.=C2=A0 Are there any other reasons for this limitatio= n, and is there data to justify those concerns?=C2=A0 If not, this should b= e left out in favor of a transaction size limit.=C2=A0 If so, hard data wou= ld go a long way to dealing with the conversy this will create.


> Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation = of segwit deployment=E2=80=9D[3] is included to:
> > cause the exi= sting "segwit" deployment to activate without needing to release = a new deployment.
> Both of the aforementioned activation options (= =E2=80=9Cfast-activation=E2=80=9D and =E2=80=9Cflag-day activation=E2=80=9D= ) serve to prevent unnecessary delays in the network upgrade process, addre= ssing a common criticism of the Scaling Agreement and providing an opportun= ity for cooperation and unity instead.

This is likely to caus= e more controversy and unfortunately has the tightest timelines.=C2=A0 Unli= ke the SW2mb working group's timelines, a hard-coded timeline couldn= 9;t be changed with mutual agreement from the signers.

Given the cha= nce of bit1 accidental activation without clear signaling for the required = bit4 2mb hard fork, I don't think the fair or acceptable tradeoff is fo= r flag day to require bit1 signaling only. =C2=A0Flag day should be m= odified to accept either bit1 signaling, OR to accept bit4 signaling IF the= 80% threshold hasn't been met. =C2=A0In this way the anti-segw= it working group members are not in danger of an activated bit1 segwit with= out also getting their portion of the compromise, the bit4 signaled HF.=C2= =A0 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 afte= rwards until 95%), but without the chance that the WG signers won't get= what they agreed to.

That seems like a minor compromise for BIP= 148.=C2=A0 Thoughts on this change to flag day / BIP148?

<= div>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.= =C2=A0 I would think some day in September is achievable, but I'm not s= ure if August 1st will be.

Jared


On Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitco= in-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
In principle, there is complete flexibility when it com= es to the specific consensus details of the hard fork. One common suggestio= n 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 wa= nt. The reasoning behind incorporating Luke-Jr's 2MB limit and discount= -rebalancing was to satisfy the conditions of the Scaling Agreement while e= nsuring maximum safety, minimum code discrepancies, and minimum controversy= among the community; these priorities seem imperative, considering the ext= reme timeline constraints we are working under and the goals of the proposa= l. To put it more simply, the intent of the proposal was to serve as a temp= late for the minimum viable fork that can achieve true consensus. A gradual= increase to a larger size cap, especially if it were reasonably conservati= ve, would be wholly in accordance with the Omnibus Proposal if that is what= it takes to achieve the cooperation between community, industry, and devel= opers in this critical moment of Bitcoin's history.

<= /div>

The purpose of the Omnibus Proposal is singlefold:= to achieve the goals of the Consensus 2017 Scaling Agreement in the most m= aximally-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-spli= t 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 i= nstead. The most rational option is to join forces and avoid any chain-spli= t potential for as long as possible. Under the Omnibus Proposal, once SegWi= t is activated, the terms of the hard fork are locked in automatically, set= to activate 6 months later. The proposal guarantees that a successful SegW= it activation is followed by a hard fork. Beyond enforcing the hard fork ru= les beginning at block height HardForkHeight, the Omnibus Proposal simply r= epresents compatibility with the existing SegWit-activation deployment appr= oaches.


By committing to this p= roposal, we can ensure unity, at least for now. There do not appear to be a= ny arguments to the contrary. Why squander this opportunity for consensus a= nd harmony? We can leverage the momentum of several disparate movements, an= d 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 gui= ding approach to your development effort. Almost every component of the cod= e exists, in some form or fashion, in the various constituent proposals'= ; reference implementations, most of which have already undergone a signifi= cant degree of peer review.


We = cannot afford to delay, nor to reimplement; the launch timeline is aggressi= vely 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 pr= oposals for the job. We can solve our problems properly, cooperatively.
=


I humbly ask that Jeff Garzik, Bar= ry Silbert, Mike Belshe, and all of the other wonderful, intelligent collab= orators on this project step forward and support the cooperative, compatibi= lity-oriented approach of the Omnibus Proposal.


This is the best way to maximize value for everyone. We ha= ve a real opportunity to collaborate and work together on the same team. Th= e Omnibus Proposal, designed in exact accordance with a powerful industry a= greement and incorporating the feedback and suggestions provided from withi= n 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 co= operate.





Sent with ProtonMail Secure Email.

-------- Original Message --------
Subj= ect: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
Local Time: May 29, 2017 6:49 PM
UTC Time: May 29, 2017 11:= 49 PM
To: CalvinRechner <calvinrechner@pr= otonmail.com>

>>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=C2=A0it's wha= t most users had/have in mind when they discuss a "2MB+SegWit" so= lution.=C2=A0

With the current 1M= B+SegWit, testing has shown us that normal usage results in ~2 or 2.1MB blo= cks.

I think most users will expect a linear increase when Base Si= ze is increased to 2000000 bytes and Total Weight is increased to 8000000 b= ytes. With normal usage, the expected results would then be ~4 or 4.2MB blo= cks.

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 than= k 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


--94eb2c043626ba9e4c0551013eee--