Return-Path: <opetruzel@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1E36A941 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 29 May 2017 23:50:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD291F3 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 29 May 2017 23:50:00 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id h4so92782741oib.3 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 29 May 2017 16:50:00 -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=Yj/VilyPXb9nWAbmy3T4iiAgnISXM5Hqq1oJdsc+aB4=; b=AH+uxqafwsGZO5SCwqmBFeBtzCAVP5y6GaeHwljHTAQlw7oIWI3r0V8UPN8jkfvzkw A53My7pWZ9LJUN5H8yO+Mffolh5vfZOiy2aebAinfVEvgoiGbMfKG2b+o7mscT595D4E Z5QPZixA240B57GfSoeFlj/hE9Uz6AJoOk66OLPmQaShw/qkRgbkm7M8tAKqryghWRgz FZ+uIE4I+lEkqDcBQivbhpnP3fB84CYlAgNozSTfrhxR1ip7TUmei0b1rABhbVc7Nmo4 bgWcYTKvzzNycJUMcTQ3/QCbQtZHOj5Vz/3XPk4kzghvmK60thoQxdkZ9TfxPqcto6av yYrg== 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=Yj/VilyPXb9nWAbmy3T4iiAgnISXM5Hqq1oJdsc+aB4=; b=KzkiAzfRNNUF1NBGsS1DFjToGHhRMZyijD8ZQQQmBMFddkzku2u+GDFpzfHNsDpZO3 G25vuX1lwcCsQKVajLK3YqeXShcMRQEkOg3ZIxo8HwjiR9Yoojua7WgSvZ98TGqwX68L uF/WN4mxc+oWr9M4NEfPZugLvfRH3UwZ9pNCrq+Gt3t4GygueVtCQAm82hTwZFCxD/w+ zup4PzRqLBqp5+GnC/siS/ajTmz+qH+iVnj4q2M+E/N7YfFyofPVPaImXb0i1YyqCQjR hkrzcDapulGxn4Mt5Ct43J81Jq0YGgF1VaL8yqQ2o55IzSUFf4+j/W4rfP2EDpU96e2C uqKw== X-Gm-Message-State: AODbwcAYSLsIC9049FhGruQ9u3qKBaArVrDFtcsOJ7Io2Z6bG+UjWFGl GuNFUdywtPzmlRGbYFeOgbwOMlp/Kg== X-Received: by 10.202.207.141 with SMTP id f135mr8620569oig.211.1496101800062; Mon, 29 May 2017 16:50:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.34.15 with HTTP; Mon, 29 May 2017 16:49:59 -0700 (PDT) Received: by 10.157.34.15 with HTTP; Mon, 29 May 2017 16:49:59 -0700 (PDT) In-Reply-To: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com> References: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com> From: Oliver Petruzel <opetruzel@gmail.com> Date: Mon, 29 May 2017 19:49:59 -0400 Message-ID: <CALhpmH3sUxa=MYtCdNMGO3AMGgmT=Tc2kcJzzpoY84syjgtP_A@mail.gmail.com> To: CalvinRechner <calvinrechner@protonmail.com> Content-Type: multipart/alternative; boundary="001a113ad55e5735940550b25887" 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 X-Mailman-Approved-At: Mon, 29 May 2017 23:51:21 +0000 Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Mon, 29 May 2017 23:50:01 -0000 --001a113ad55e5735940550b25887 Content-Type: text/plain; charset="UTF-8" >>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 --001a113ad55e5735940550b25887 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div style=3D"font-family:sans-serif;font-size:18.048px" = dir=3D"auto"><span style=3D"font-size:18.048px">>>if the community wi= shes 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.<= <</span><br></div><div style=3D"font-family:sans-serif;font-size:18.048p= x" dir=3D"auto"><span style=3D"font-size:18.048px"><br></span></div><div st= yle=3D"font-family:sans-serif;font-size:18.048px" dir=3D"auto"><span style= =3D"font-size:18.048px"><br></span></div><div style=3D"font-family:sans-ser= if;font-size:18.048px" dir=3D"auto">The above decision may quickly become v= ery controversial. I don't think<span style=3D"font-size:18.048px">=C2= =A0it's what most users had/have in mind when they discuss a "2MB+= SegWit" solution.=C2=A0</span></div><div style=3D"font-family:sans-ser= if;font-size:18.048px" dir=3D"auto"><span style=3D"font-size:18.048px"><br>= </span></div><div style=3D"font-family:sans-serif;font-size:18.048px" dir= =3D"auto">With the current 1MB+SegWit, testing has shown us that normal usa= ge results in ~2 or 2.1MB blocks.</div><div style=3D"font-family:sans-serif= ;font-size:18.048px" dir=3D"auto"><br></div><div style=3D"font-family:sans-= serif;font-size:18.048px" dir=3D"auto">I think most users will expect a lin= ear increase when Base Size is increased to 2000000 bytes and Total Weight = is increased to 8000000 bytes. With normal usage, the expected results woul= d then be ~4 or 4.2MB blocks.</div><div style=3D"font-family:sans-serif;fon= t-size:18.048px" dir=3D"auto"><br></div><div style=3D"font-family:sans-seri= f;font-size:18.048px" dir=3D"auto">Am I missing something here, or does Luk= e's suggested 2MB cap completely nullify that expected linear increase?= If so, why? What's the logic behind this decision?</div><div style=3D"= font-family:sans-serif;font-size:18.048px" dir=3D"auto"><br></div><div styl= e=3D"font-family:sans-serif;font-size:18.048px" dir=3D"auto">I'd love t= o be armed with a good answer should my colleagues ask me the same obvious = question, so thank you ahead of time!</div><div style=3D"font-family:sans-s= erif;font-size:18.048px" dir=3D"auto"><br></div><div style=3D"font-family:s= ans-serif;font-size:18.048px" dir=3D"auto">Respectfully,</div><div style=3D= "font-family:sans-serif;font-size:18.048px" dir=3D"auto">Oliver Petruzel</d= iv><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"auto"><b= r></div><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"aut= o"><br></div></div> --001a113ad55e5735940550b25887--