Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A507CE22 for ; Fri, 18 Dec 2015 05:11:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2BACE0 for ; Fri, 18 Dec 2015 05:11:48 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id to18so27354203igc.0 for ; Thu, 17 Dec 2015 21:11:48 -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=aex761AUiCLaeJBUTpmr5obGzCQAM3E4hcZqkh+Y7qM=; b=Pvr8OMduwA4Y5G07D26ZE6Q9Z/NyIVwTOStDqWp0M40ckfbHkBWyrR1d0dgGwVJFSR uSuwYv4wbqFkXyjN1BU4eTca3nPMHSrY+wZXopDoyKRGCHSpDCqisC2sz4EyDDn88vgS MfiSdZFDheVKUaxv3cn93ThONuGOnVQ0q9Qmr0cBRu1QYlu4KtSLbas80YptKn6bKbWd Q2M7yaN7V2Y0gdH4xKW8sXQsuQIuzpX2JPIC5ohnatklAx8EgWGwJpQjUqixnu13V5pz HVLin73T5BX4qt9Av9qBFs4Km0IMyDWGbSlByq/opRJGrPhhlIO0Y9BWKP0egIOt8UwN v1Vw== MIME-Version: 1.0 X-Received: by 10.50.36.105 with SMTP id p9mr741076igj.54.1450415508325; Thu, 17 Dec 2015 21:11:48 -0800 (PST) Received: by 10.79.8.198 with HTTP; Thu, 17 Dec 2015 21:11:48 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 00:11:48 -0500 Message-ID: From: Jeff Garzik To: Pieter Wuille Content-Type: multipart/alternative; boundary=089e01176343268d5e0527252d3b 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 05:11:49 -0000 --089e01176343268d5e0527252d3b Content-Type: text/plain; charset=UTF-8 On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille wrote: > On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev > 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. > Diverging from the satoshi block size change plan[1] and current economics would seem to require a high level of months-ahead communication to users. > all. Yes, old full nodes after a soft fork are not able to fully > validate the rules new miners enforce anymore, but they do still > verify the rules that their operators opted to enforce. Furthermore, > they can't be prevented. For that reason, I've proposed, and am > working hard, on an approach that includes Segregated Witness as a > first step. It shows the ecosystem that something is being done, it > kicks the can down the road, it solves/issues half a dozen other > issues at the same time, and it does not require the degree of > certainty needed for a hardfork. > Segregated Witness does not kick the can, it solves none of the problems #1, #3 - #8 explicitly defined and listed in email #1. 1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there will be no Fee Event, because the core block size is still heavily contended -- 100% contended at time out SW rollout. 2) We are only 100% certain that bitcoin works in the blocks-not-full-on-avg state, where there is a healthy buffer between the hard limit and the average block size. There is remains major ECE risk due to the core block size freeze, possibly pushing the system into a new, untried economic state and causing major market and actor disruption. Users of the Service can still drift randomly and unpredictably into a Fee Event. SW mitigates this - only after several months - only assuming robust adoption rates by up-layer ecosystem software, and - only assuming transaction volume growth is flat or sub-linear Those conditions *must* go as planned to fulfill "SW kicked the can" -- a lot of if's. As stated, SW is orthogonal to the drift-into-uncharted-waters problem outlined in email #1, which a short term bump does address. --089e01176343268d5e0527252d3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <p= ieter.wuille@gmail.com> wrote:
=
On Wed, Dec 16= , 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> 2) If block size stays at 1M, the Bitcoin Core developer team should s= ign a
> collective note stating their desire to transition to a new economic p= olicy,
> that of "healthy fee market" and strongly urge users to exam= ine 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 charg= e
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.

Diverging from the satoshi block size change plan[1] and current economic= s would seem to require a high level of months-ahead communication to users= .


=C2=A0
all. Yes, old full nodes after a soft fork are not able to fully
validate the rules new miners enforce anymore, but they do still
verify the rules that their operators opted to enforce. Furthermore,
they can't be prevented. For that reason, I've proposed, and am
working hard, on an approach that includes Segregated Witness as a
first step. It shows the ecosystem that something is being done, it
kicks the can down the road, it solves/issues half a dozen other
issues at the same time, and it does not require the degree of
certainty needed for a hardfork.

=
Segregated Witness does not kick the= can, it solves none of the problems #1, #3 - #8 explicitly defined and lis= ted in email #1.

1) =C2=A0A plan of "SW + no hard fork" is gambling wit= h ECE risk, gambling there will be no Fee Event, because the core block siz= e is still heavily contended -- 100% contended at time out SW rollout.

2) We are = only 100% certain that bitcoin works in the blocks-not-full-on-avg state, w= here there is a healthy buffer between the hard limit and the average block= size.

There is remains major ECE risk due to the core block size freeze, possibl= y pushing the system into a new, untried economic state and causing major m= arket and actor disruption.=C2=A0 Users of the Service can still drift rand= omly and unpredictably into a Fee Event.
SW mitigates this
- only after several months
- onl= y assuming robust adoption rates by up-layer ecosystem software, and=C2=A0<= /div>
- only assuming transaction volume growth i= s flat or sub-linear

Those conditions=C2=A0must=C2=A0go as planned to fulfill "SW kicked the can" -- a lot of = if's.

As stated, SW is orthogonal to the drift-into-uncharted-waters problem = outlined in email #1, which a short term bump does address.










--089e01176343268d5e0527252d3b--