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 E7CD671E for ; Wed, 22 Jul 2015 18:45:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 096641AF for ; Wed, 22 Jul 2015 18:45:01 +0000 (UTC) Received: by obre1 with SMTP id e1so140036866obr.1 for ; Wed, 22 Jul 2015 11:45:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6H663wGPSWOQosT0UKp+rt7JAhc3wWEAf1htziy3QHs=; b=Ma2oVp6TWNR5H8mfUanvetoiYSmi3ogn34xYbNL/MxcvqubL5rwAvxDv1S9hxxXHXP h2NTop+Qb4L0guprJ4ygfw9nktn+Qdue0MTByn+0B/wSrkIx6s2QX5xuVzLMNm66jBtB AinlA+WERlTChHooAUSV/ngm2r3GZ0v4adHVVrxgN7YXkfhMF4ISJeXzIS+mCMc8bFQ2 RwIW7cQpC+pb3Pv/zM36KLr1srlXOwkcK5FCamttdFYjInPqyA4t8oEnDXTBGe/eHv55 eboLhpyyzjjc1mZAE2RIl7CO1RRQMho4f9QyLQDk+vfPOslMMqggLwilk2fwqP7Jvkmu 9bgA== X-Gm-Message-State: ALoCoQnSV7etwQNydOj0zUUCqa7CMQmzRGYJmZYo9PEi6FDe7rScr4e3tNJJRmbUGScTy3qouwfI MIME-Version: 1.0 X-Received: by 10.202.95.138 with SMTP id t132mr3899300oib.55.1437590701461; Wed, 22 Jul 2015 11:45:01 -0700 (PDT) Received: by 10.182.206.16 with HTTP; Wed, 22 Jul 2015 11:45:01 -0700 (PDT) In-Reply-To: <55AFD390.9060306@bitcoins.info> References: <55AFD390.9060306@bitcoins.info> Date: Wed, 22 Jul 2015 11:45:01 -0700 Message-ID: From: Bryan Cheng To: pieter.wuille@gmail.com Content-Type: multipart/alternative; boundary=001a113cd41a17fabd051b7b2b3b X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks 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, 22 Jul 2015 18:45:03 -0000 --001a113cd41a17fabd051b7b2b3b Content-Type: text/plain; charset=UTF-8 Pieter, I agree with the overall gist of your statement (that Bitcoin is a consensus-driven protocol that's incompatible with certain forms of central governance) but I respectfully disagree with some of the conclusions you're drawing. > Consensus changes should be done using consensus, _and the default in case of controversy is no change_. (emphasis mine) I think that there's a disconnect between the idea that Bitcoin Core making a consensus-driven change in turn means that the network is being forced down a certain path. This takes away a great deal of the individual agency that makes Bitcoin what it is today. Upgrading to a version of Bitcoin Core that is incompatible with your ideals is in no way a forced choice, as you have stated in your email; forks, alternative clients, or staying on an older version are all valid choices. If the majority of the network chooses not to endorse a specific change, then the majority of the network will continue to operate just fine without it, and properly structured consensus rules will pull the minority along as well. (For example, re: block sizes, if the majority of hashing power remains on a version or fork that does not mine >1MB blocks, a chain of <1MB blocks will continue to be the longest, and up to date clients will still respect that. That is consensus at work, pure and simple.) Obviously Core is in a unique position as a reference client and ignoring that would be irresponsible. If broad consensus among the developers cannot be reached, then Core should not make a given change. However, freezing Core's ability to make changes in light of _any_ controversy is allowing a few voices to dictate direction and is counter to any kind of consensus-driven decision making. Placing Core and its developers on some sort of pedestal where we believe that they dictate policy and therefore shouldn't be allowed to take any risks will create the very situation that you're advocating against- that a small group of developers have control over Bitcoin's policies. Instead, we should strive to treat Core as _just another Bitcoin Client_, we should educate users to make informed choices about the version of software they are running and the choices implicit in that, and we should allow consensus at the protocol level to make the decisions on the overall direction of the network. > My personal opinion is that we - as a community - should indeed let a fee market develop, and rather sooner than later I will keep this brief because this is straying off topic of the idea of this thread- but I don't believe that increasing Bitcoin's capacity as a network is inherently incompatible with the development of a fee market, and considering a fee market to be formed of only a single set of variables (transaction rate versus block size) is not sound economic analysis. On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > default in case of controversy is no change. >> > > I think the result of this would probably be that no controversial changes > ever get implemented via this process so others will hard fork the code and > eventually make this process irrelevant. Since you need close to 100% > agreement the irrelevance would have to come as a step function which will > manifest itself in a rather disruptive manner. > > The question is really is this hark-forking disruption worse than coming > up with some kind of process to handle controversial changes. > > Russ > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113cd41a17fabd051b7b2b3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pieter, I agree with the overall gist of your statement (t= hat Bitcoin is a consensus-driven protocol that's incompatible with cer= tain forms of central governance) but I respectfully disagree with some of = the conclusions you're drawing.

>=C2=A0Consensus changes should be done using consensus, _a= nd the default in case of controversy is no change_.=C2=A0

(emphasis mine)

I think that = there's a disconnect between the idea that Bitcoin Core making a consen= sus-driven change in turn means that the network is being forced down a cer= tain path. This takes away a great deal of the individual agency that makes= Bitcoin what it is today. Upgrading to a version of Bitcoin Core that is i= ncompatible with your ideals is in no way a forced choice, as you have stat= ed in your email; forks, alternative clients, or staying on an older versio= n are all valid choices. If the majority of the network chooses not to endo= rse a specific change, then the majority of the network will continue to op= erate just fine without it, and properly structured consensus rules will pu= ll the minority along as well. (For example, re: block sizes, if the majori= ty of hashing power remains on a version or fork that does not mine >1MB= blocks, a chain of <1MB blocks will continue to be the longest, and up = to date clients will still respect that. That is consensus at work, pure an= d simple.)=C2=A0

Obviously Core is in a unique= position as a reference client and ignoring that would be irresponsible. I= f broad consensus among the developers cannot be reached, then Core should = not make a given change. However, freezing Core's ability to make chang= es in light of _any_ controversy is allowing a few voices to dictate direct= ion and is counter to any kind of consensus-driven decision making.

Placing Core and its developers on some sort of pedestal = where we believe that they dictate policy and therefore shouldn't be al= lowed to take any risks will create the very situation that you're advo= cating against- that a small group of developers have control over Bitcoin&= #39;s policies. Instead, we should strive to treat Core as _just another Bi= tcoin Client_, we should educate users to make informed choices about the v= ersion of software they are running and the choices implicit in that, and w= e should allow consensus at the protocol level to make the decisions on the= overall direction of the network.

>=C2=A0My personal opinion is that we - as a community= - should indeed let a fee market develop, and rather sooner than later

I will keep this brief because this is straying = off topic of the idea of this thread- but I don't believe that increasi= ng Bitcoin's capacity as a network is inherently incompatible with the = development of a fee market, and considering a fee market to be formed of o= nly a single set of variables (transaction rate versus block size) is not s= ound economic analysis.

On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
default in case of controversy is no change.

I think the result of this would probably be that no controversial changes = ever get implemented via this process so others will hard fork the code and= eventually make this process irrelevant.=C2=A0 Since you need close to 100= % agreement the irrelevance would have to come as a step function which wil= l manifest itself in a rather disruptive manner.

The question is really is this hark-forking disruption worse than coming up= with some kind of process to handle controversial changes.

Russ



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

--001a113cd41a17fabd051b7b2b3b--