Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A2D88B7B for ; Tue, 30 May 2017 15:51:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C06B2163 for ; Tue, 30 May 2017 15:51:18 +0000 (UTC) Received: by mail-qk0-f177.google.com with SMTP id d14so31844198qkb.1 for ; Tue, 30 May 2017 08:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8FLH0/3vTNNEoI5mu+eck4qTg+91ctz8pIpmUjuadMU=; b=jxzaKoNMIwauuQzy2mhTlkteIWm02jycioiYorKnOpwIzkls02IlvH9RMTcxBZKbYp wVR5IOKKBjihYjzu9fmP/FFz87+Eb3r8FpwO9GGrFL7Rs4WOZROJ5GaFMFg+K3b2eLQL RiSKIUXErZJ5H+uHegQeJOKGDLBGHdPxRBk085eqzYTMq2d8xx4vtCmTui10+ulIRR0u rHeGTuMS58HWnayPtEmN1Twc1n6hxxb7boXP7xl3kGMd4edv7we4H0rGpTkD/BcpDPoP JIW3ci/8hNCM/TSRxe6v9e6qTwPop8X0nGFEG1XYhGyzDcbNNfGR4ugiobY4s5V70Qxl 2fQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8FLH0/3vTNNEoI5mu+eck4qTg+91ctz8pIpmUjuadMU=; b=mOUWk8JWoZL1LFtt6zW/cxGOo3iZbuDE3nPeCL6eg7jeouv9EfkhS1OWYWWRXsIZAI RMeM/EU6+XPBi7dsHVZ13jCC3r368APwKHQvKY7Xv3uwh2e/8TCGNY8iVyk5HEo+mljW 0xOiAVI63UkALWdlytE6+EINXx9+ms+gRt24KkwPPrgZUt5sPSma7/s26qjrWy4F4q7O srJTL97iSPixoAQDRLDFd3RpBdTLK9tf1Y7+EIIsGi4sskkc8Z1EyaBHKO1L06YKKiiR L5wIhoJxLaz+joBoAJZWsCQhwYfxifL3RTzL5FLAfAeb7I5/BxvBUFWjz558hNyl0w2F Auxw== X-Gm-Message-State: AODbwcDqIIApL9CCYK3E9r5OXZ5swxuGtxTXtRZFvzULTclC6xuJweCK EcPzV2w+RRAHhCCz+WZmVKefdM+R7Q== X-Received: by 10.55.141.67 with SMTP id p64mr25317796qkd.164.1496159477958; Tue, 30 May 2017 08:51:17 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.237.48.102 with HTTP; Tue, 30 May 2017 08:51:17 -0700 (PDT) In-Reply-To: References: From: Erik Aronesty Date: Tue, 30 May 2017 11:51:17 -0400 X-Google-Sender-Auth: jZfZOMkGiN0sIkcqf2g5f6f3xdQ Message-ID: To: Oliver Petruzel Content-Type: multipart/alternative; boundary="94eb2c084666360bba0550bfc6be" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 X-Mailman-Approved-At: Tue, 30 May 2017 17:32:47 +0000 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: Tue, 30 May 2017 15:51:19 -0000 --94eb2c084666360bba0550bfc6be Content-Type: text/plain; charset="UTF-8" - We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs BIP91 ... how many are there?: https://xkcd.com/927 - If some miners and exchanges collude to enact a rapid 2MB+Segwit hard fork coin... and calling it "bitcoin" on major exchanges this could swiftly fragment the network. - If this fork fails to contain an ASICBOOST defense, then this is essentially an example of core failing to appropriately respond to the CVE security vulnerability in time. - A swift BIP148 release in core seems necessary to defend against this. I am no longer in favor of adding a BIP148 option with default "false".. I think it should be merged in...enabled, and released ASAP to defend against these attacks. On Mon, May 29, 2017 at 7:49 PM, Oliver Petruzel via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > >>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 > > --94eb2c084666360bba0550bfc6be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
- We now are witnessing this... COOP vs LukeJr COOP, = vs BIP148 vs BIP149 vs BIP91 ... how many are there?:

https://xkcd.com/927

- If some min= ers and exchanges collude to enact a rapid 2MB+Segwit hard fork coin... and= calling it "bitcoin" on major exchanges this could swiftly fragm= ent the network. =C2=A0 =C2=A0

- If this fork fail= s to contain an ASICBOOST defense, then this is essentially an example of c= ore failing to appropriately respond to the CVE security vulnerability in t= ime.=C2=A0

- A swift BIP148 release in core seems necessary to = defend against this. =C2=A0 I am no longer in favor of adding a BIP148 opti= on with default "false".. =C2=A0 I think it should be merged in..= .enabled, and released ASAP to defend against these attacks.
=C2=A0

On Mon, = May 29, 2017 at 7:49 PM, Oliver Petruzel via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>if the community wishes to adopt (by unanimous consens= us) a 2 MB block size hardfork, this is probably the best way to do it righ= t now... Legacy Bitcoin transactions are given the witness discount, and a = block size limit of 2 MB is imposed.<<


<= /div>
The above decision may quickly become very controversial. I don'= t think=C2=A0it's what most users ha= d/have in mind when they discuss a "2MB+SegWit" solution.=C2=A0

With the current 1MB+S= egWit, 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 i= ncreased to 2000000 bytes and Total Weight is increased to 8000000 bytes. W= ith 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 comple= tely nullify that expected linear increase? If so, why? What's the logi= c behind this decision?

I'd love to be armed with a good answer sh= ould 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


--94eb2c084666360bba0550bfc6be--