Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1E36A941 for ; 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 ; Mon, 29 May 2017 23:50:00 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id h4so92782741oib.3 for ; 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: References: From: Oliver Petruzel Date: Mon, 29 May 2017 19:49:59 -0400 Message-ID: To: CalvinRechner 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 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: 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
>>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.<= <


The above decision may quickly become v= ery controversial. I don't think=C2= =A0it's what most users had/have in mind when they discuss a "2MB+= SegWit" solution.=C2=A0

=
With the current 1MB+SegWit, testing has shown us that normal usa= ge results in ~2 or 2.1MB blocks.

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.

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?

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!

Respectfully,
Oliver Petruzel

--001a113ad55e5735940550b25887--