Return-Path: <jgarzik@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DB126F1D for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 16 Dec 2015 21:08:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44051148 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 16 Dec 2015 21:08:30 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id to4so84162793igc.0 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 16 Dec 2015 13:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rfMyoEGKYnaMOAxBqege4rRqKarLEKpRlpAJCQKuCaw=; b=kach7HakTWnN2gx9nUAyofzfg6Vb0ftqw0j3Xs45Wp40h4Iea5+ppKRM9eV8ODqX/O NinH+/fOeAJY2tu+EidtaiUNKHM7Ud8o+9Ug9tQf1iAHLpUbZ3BXlwIMHFJH4VvvZcAj fH+9F7WQEvaV3WN+SUJBywObaG0fP7VacN+QnChd8xIhbjizJvsy8YnqGni0jfWFF70A nro518G7L82ZRERnxBY7JkhOcTffk5JRlivQYjZH/OjGJe36Tah4dLkOz+X2pO5s2O7u eF3A01X8iKGPvuPohticK67pyij4RqnwfHnzO0jJthSY/nlLIsTs0A7rg+/rilnN3fbl KgBg== MIME-Version: 1.0 X-Received: by 10.50.36.105 with SMTP id p9mr13334635igj.54.1450300109735; Wed, 16 Dec 2015 13:08:29 -0800 (PST) Received: by 10.79.8.198 with HTTP; Wed, 16 Dec 2015 13:08:29 -0800 (PST) In-Reply-To: <CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com> References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com> <CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com> Date: Wed, 16 Dec 2015 16:08:29 -0500 Message-ID: <CADm_Wcae7OK7kyXkfh+7XFrc2WYsv7T1Va3_E=5om+XYrL9pOw@mail.gmail.com> From: Jeff Garzik <jgarzik@gmail.com> To: Pieter Wuille <pieter.wuille@gmail.com> Content-Type: multipart/alternative; boundary=089e01176343dbd3a705270a4eb7 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development 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: Wed, 16 Dec 2015 21:08:31 -0000 --089e01176343dbd3a705270a4eb7 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote: > On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > 2) If block size stays at 1M, the Bitcoin Core developer team should > sign a > > collective note stating their desire to transition to a new economic > policy, > > that of "healthy fee market" and strongly urge users to examine their fee > > policies, wallet software, transaction volumes and other possible User > > impacting outcomes. > > You present this as if the Bitcoin Core development team is in charge > of deciding the network consensus rules, and is responsible for making > changes to it in order to satisfy economic demand. If that is the > case, Bitcoin has failed, in my opinion. > This circles back to Problem #1: Avoidance of a choice is a still a choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real Economic Change Event risk. And #3: If the likely predicted course is that Bitcoin Core will not accept a protocol change changing MAX_BLOCK_SIZE via hard fork in the short term, the core dev team should communicate that position clearly to users and media. Hitting a Fee Event is market changing, potentially reshuffling economic actors to a notable degree. Maintaining a short term economic policy of fixed 1M supply in the face of rising transaction volume carries risks that should be analyzed and communicated. --089e01176343dbd3a705270a4eb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <span dir= =3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">p= ieter.wuille@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">= <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Dec= 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev<br> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla= nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> > 2) If block size stays at 1M, the Bitcoin Core developer team should s= ign a<br> > collective note stating their desire to transition to a new economic p= olicy,<br> > that of "healthy fee market" and strongly urge users to exam= ine their fee<br> > policies, wallet software, transaction volumes and other possible User= <br> > impacting outcomes.<br> <br> </span>You present this as if the Bitcoin Core development team is in charg= e<br> of deciding the network consensus rules, and is responsible for making<br> changes to it in order to satisfy economic demand. If that is the<br> case, Bitcoin has failed, in my opinion.<br></blockquote><div><br></div><di= v>This circles back to Problem #1: =C2=A0 Avoidance of a choice is a still = a choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real= Economic Change Event risk.</div><div><br></div><div>And #3: =C2=A0If the = likely predicted course is that Bitcoin Core will not accept a protocol cha= nge changing MAX_BLOCK_SIZE via hard fork in the short term, the core dev t= eam should communicate that position clearly to users and media.</div><div>= <br></div><div>Hitting a Fee Event is market changing, potentially reshuffl= ing economic actors to a notable degree.=C2=A0 Maintaining a short term eco= nomic policy of fixed 1M supply in the face of rising transaction volume ca= rries risks that should be analyzed and communicated.</div><div><br></div><= div><br></div><div><br></div><div><br></div></div></div></div> --089e01176343dbd3a705270a4eb7--