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 A240111EE for ; Wed, 23 Dec 2015 06:26:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69344148 for ; Wed, 23 Dec 2015 06:26:12 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id mv3so62258837igc.0 for ; Tue, 22 Dec 2015 22:26:12 -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=4MwlufsQsghMkzhe/ZPVlOvqq8DmBvUwV1UDz4tn65I=; b=bUZuC2berpErwj4VIKk2RF2QuJORFM92HR/WuHXhCdUlOAMFqOHdKUN6uVOeUXtcPE UbuWKGO6diHvKOsCV9rtOaENJagYZsuJZjX1BaL+SRRICq9dRyf8vDQvpLrIyoEM3cm7 R8XCBaR3fP4G4d6ZT0P9y2UXlwE1H65uezD7yWsAtORojdJz8PryLHNVJZgThvH2aa7f MdNm2OMvRhGxwOofZKDUiuiKr51Y/6Odny41rskVUdWCvbts7lhwBBlFEMaxz59/Ucwl 9rM9KF00GuNdYESImONe7DB3m+WYlpi9aldUH06SwvimCWPxIBl5E6qbXfzLX4B6byLQ XO5A== MIME-Version: 1.0 X-Received: by 10.50.65.39 with SMTP id u7mr29170453igs.85.1450851971901; Tue, 22 Dec 2015 22:26:11 -0800 (PST) Received: by 10.36.22.148 with HTTP; Tue, 22 Dec 2015 22:26:11 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 22:26:11 -0800 Message-ID: From: Aaron Voisine To: Pieter Wuille Content-Type: multipart/alternative; boundary=047d7b2e145568309705278accd1 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, 24 Dec 2015 11:21:52 +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: Wed, 23 Dec 2015 06:26:13 -0000 --047d7b2e145568309705278accd1 Content-Type: text/plain; charset=UTF-8 > 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. Pieter, what's actually happening is that the bitcoin-core release has become a Schelling point in the consensus game: https://en.wikipedia.org/wiki/Schelling_point Due to the strong incentives for consensus, everyone is looking for an obvious reference point that they think everyone else will also pick, even though the point itself isn't critical, only that everyone agree on whatever point is picked. Like it or not, the bitcoin-core release, and by extension it's committers have a great degree of influence over what the community as a whole decides to do. If core screws things up badly enough, yes, the community will settle on some other focal point for consensus, but the cost and risk of doing so is high, so there is indeed unavoidable moral hazard for whoever has control over any such focus point. Aaron Voisine co-founder and CEO breadwallet On Wed, Dec 16, 2015 at 10:34 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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. > > What the Bitcoin Core team should do, in my opinion, is merge any > consensus change that is uncontroversial. We can certainly - > individually or not - propose solutions, and express opinions, but as > far as maintainers of the software goes our responsibility is keeping > the system running, and risking either a fork or establishing > ourselves as the de-facto central bank that can make any change to the > system would greatly undermine the system's value. > > Hard forking changes require that ultimately every participant in the > system adopts the new rules. I find it immoral and dangerous to merge > such a change without extremely widespread agreement. I am personally > fine with a short-term small block size bump to kick the can down the > road if that is what the ecosystem desires, but I can only agree with > merging it in Core if I'm convinced that there is no strong opposition > to it from others. > > Soft forks on the other hand only require a majority of miners to > accept them, and everyone else can upgrade at their leisure or not at > 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. > > -- > Pieter > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --047d7b2e145568309705278accd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> You present this as if the Bitcoin Core development t= eam is in charge
> of deciding the network consensus rules, and is re= sponsible for
> making=C2=A0changes to it in order to satisfy econom= ic demand. If that is
> the=C2=A0case, Bitcoin has failed, in = my opinion.

Pieter, what's actually happening is that the bitcoin-core release = has become a Schelling point in the consensus game:

https://en.wikipedia.org/wiki/Schelling_point<= /a>

Due to the strong incentives for consensus, everyone is looking for an ob= vious reference point that they think everyone else will also pick, even th= ough the point itself isn't critical, only that everyone agree on whate= ver point is picked. Like it or not, the bitcoin-core release, and by exten= sion it's committers have a great degree of influence over what the com= munity as a whole decides to do. If core screws things up badly enough, yes= , the community will settle on some other focal point for consensus, but th= e cost and risk of doing so is high, so there is indeed unavoidable moral h= azard for whoever has control over any such focus point.

On Wed, Dec 16, 2015 at 10:34 AM, Pieter Wui= lle via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> 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.

What the Bitcoin Core team should do, in my opinion, is merge any
consensus change that is uncontroversial. We can certainly -
individually or not - propose solutions, and express opinions, but as
far as maintainers of the software goes our responsibility is keeping
the system running, and risking either a fork or establishing
ourselves as the de-facto central bank that can make any change to the
system would greatly undermine the system's value.

Hard forking changes require that ultimately every participant in the
system adopts the new rules. I find it immoral and dangerous to merge
such a change without extremely widespread agreement. I am personally
fine with a short-term small block size bump to kick the can down the
road if that is what the ecosystem desires, but I can only agree with
merging it in Core if I'm convinced that there is no strong opposition<= br> to it from others.

Soft forks on the other hand only require a majority of miners to
accept them, and everyone else can upgrade at their leisure or not at
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.

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

--047d7b2e145568309705278accd1--