From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6383EE12 for ; Thu, 17 Dec 2015 02:06:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 443F7A9 for ; Thu, 17 Dec 2015 02:06:10 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id cs9so36682889lbb.1 for ; Wed, 16 Dec 2015 18:06:10 -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=uWrZL1OHOwyWOyclbQua+XzuMzpLWAW2aH5u6S0+mTw=; b=s5flOBmD4b0W43OFZpHpkqpj9uGT9hIMq6lTW4YKU3FjHdC6Akrz6AGTuGkneH+hdS V6P/QKXB0n1WCbidc2QY11TRAMwab4azU5nbFv+G/pDWHA7KghpWw1CTzL0BQs0+4U4w VbqQ6LWcjVIk5kMECpEqB69WXzEZpIVrNhELrB8voG7OMVr1FXXdu9N5/GPAkQPW5Tpz thWHW0wjFX67LqZj6DX6KkwMbXMQaLepxiDFbK5c4lO08B0UhS7YykjiA1MuB2K8v6mB 8bf779os8xsUiwVlwYOw/sW1HRc4LhBABRYzns0z34eaOLwGT2aLh/BvO/yEUIX/MgiA 1gOA== MIME-Version: 1.0 X-Received: by 10.112.166.33 with SMTP id zd1mr16797992lbb.113.1450317968312; Wed, 16 Dec 2015 18:06:08 -0800 (PST) Received: by 10.25.21.228 with HTTP; Wed, 16 Dec 2015 18:06:08 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2015 18:06:08 -0800 Message-ID: From: Jameson Lopp To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a11c37c5450116c05270e77cd 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 X-Mailman-Approved-At: Thu, 17 Dec 2015 12:33:58 +0000 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: Thu, 17 Dec 2015 02:06:11 -0000 --001a11c37c5450116c05270e77cd Content-Type: text/plain; charset=UTF-8 On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik wrote: > >> 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. > > We are not avoiding a choice. We don't have the authority to make a choice. > > > 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. > > I indeed think we can communicate much better that deciding consensus > rules is not within our power. > Indeed, because I sometimes find these statements to be confusing as well - I can completely understand what you mean if you're speaking from a moral standpoint. If you're saying that it's unacceptable for the Bitcoin Core developers to force consensus changes upon the system, I agree. But thankfully the design of the system does not allow the developers to do so. Developers can commit amazing code or terrible code, but it must be voluntarily adopted by the rest of the ecosystem. Core developers can't decide these changes, they merely propose them to the ecosystem by writing and releasing code. I agree that Core developers have no authority to make these decisions on behalf of all of the network participants. However, they are in a position of authority when it comes to proposing changes. One of my takeaways from Hong Kong was that most miners have little interest in taking responsibility for consensus changes - they trust the Core developers to use their expertise to propose changes that will result in the continued operation of the network and not endanger their business operations. A non-trivial portion of the ecosystem is requesting that the Core developers make a proposal so that the network participants can make a choice. Jeff noted that we can expect for the economic conditions of the network to change significantly in 2016, barring higher throughput capacity. If the year+ deployment timeframe for hard forks proposed by Matt on another thread is what we can expect for any proposed consensus change, then it should be non-contentious to announce that there will be no hard fork in 2016. This will give clarity to the rest of the ecosystem as to how they should prepare. > -- > Pieter > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a11c37c5450116c05270e77cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Wed, Dec 16, 2015 at 1= 0:08 PM, Jeff Garzik <jgarzik@gmail= .com> wrote:
>> You present this as if the Bitcoin Core development team is in cha= rge
>> of deciding the network consensus rules, and is responsible for ma= king
>> changes to it in order to satisfy economic demand. If that is the<= br> >> case, Bitcoin has failed, in my opinion.
>
>
> This circles back to Problem #1:=C2=A0 =C2=A0Avoidance of a choice is = a still a choice
> - failing to ACK a MAX_BLOCK_SIZE increase still creates very real Eco= nomic
> Change Event risk.

We are not avoiding a choice. We don't have the authority to mak= e a choice.

> And #3:=C2=A0 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 t= erm,
> the core dev team should communicate that position clearly to users an= d
> media.

I indeed think we can communicate much better that deciding consensu= s
rules is not within our power.

Indeed, = because I sometimes find these statements to be confusing as well - I can c= ompletely understand what you mean if you're speaking from a moral stan= dpoint. If you're saying that it's unacceptable for the Bitcoin Cor= e developers to force consensus changes upon the system, I agree. But thank= fully the design of the system does not allow the developers to do so. Deve= lopers can commit amazing code or terrible code, but it must be voluntarily= adopted by the rest of the ecosystem. Core developers can't decide the= se changes, they merely propose them to the ecosystem by writing and releas= ing code.=C2=A0

I agree that Core developers have = no authority to make these decisions on behalf of all of the network partic= ipants. However, they are in a position of authority when it comes to propo= sing changes. One of my takeaways from Hong Kong was that most miners have = little interest in taking responsibility for consensus changes - they trust= the Core developers to use their expertise to propose changes that will re= sult in the continued operation of the network and not endanger their busin= ess operations.

A non-trivial portion of the ecosy= stem is requesting that the Core developers make a proposal so that the net= work participants can make a choice. Jeff noted that we can expect for the = economic conditions of the network to change significantly in 2016, barring= higher throughput capacity. If the year+ deployment timeframe for hard for= ks proposed by Matt on another thread is what we can expect for any propose= d consensus change, then it should be non-contentious to announce that ther= e will be no hard fork in 2016. This will give clarity to the rest of the e= cosystem as to how they should prepare.


--
Pieter
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a11c37c5450116c05270e77cd--