Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5Yx4-0008UD-4G for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 12:29:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.175 as permitted sender) client-ip=209.85.217.175; envelope-from=pieter.wuille@gmail.com; helo=mail-lb0-f175.google.com; Received: from mail-lb0-f175.google.com ([209.85.217.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5Yx2-0006g4-IY for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 12:29:50 +0000 Received: by lbbvz5 with SMTP id vz5so3086865lbb.0 for ; Thu, 18 Jun 2015 05:29:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.44.225 with SMTP id h1mr12705119lam.5.1434630582199; Thu, 18 Jun 2015 05:29:42 -0700 (PDT) Received: by 10.112.19.7 with HTTP; Thu, 18 Jun 2015 05:29:42 -0700 (PDT) In-Reply-To: <20150618111407.GA6690@amethyst.visucore.com> References: <55828737.6000007@riseup.net> <20150618111407.GA6690@amethyst.visucore.com> Date: Thu, 18 Jun 2015 14:29:42 +0200 Message-ID: From: Pieter Wuille To: "Wladimir J. van der Laan" Content-Type: multipart/alternative; boundary=089e0160b7be3c6df70518c9f696 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z5Yx2-0006g4-IY Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 12:29:50 -0000 --089e0160b7be3c6df70518c9f696 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan wrote: > Like in any open source project there is lots of decision making ability > for code changes. I'd say look at the changelog for e.g. 0.11 > https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log, > or follow pull requests for a while, to see how many decisions about > changes are made from day to day. No, I'm not sitting on my hands, and so > is none of the other contributors that you'd like to get rid of. > The analogy goes further even. Even though I disagree with some of the changes you're making, I respect Mike's (and anyone's) right to make a fork of Bitcoin Core. That's how open source works: if people disagree with changes made or not made, they can maintain their own version. However: > Consensus changes are *much* more difficult, on the other hand. Even > relatively straightforward softforks come with a long discussion process > (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone > needs to upgrade their software!), and simply not possible if almost the > entire technical community disagrees with you. > Consensus changes - in particular hardforks - are not about making a change to the software. You are effectively asking users of the system to migrate to a new system. Perhaps one which is a philosophical successor to the old one, but a different system, with new rules that are incompatible with the old one. I believe this is something that can only be done if there is no controversy about the change, for different reasons: * Risk: no matter how you determine the switchover date, there is no way of knowing when (and whether at all) everyone changes their full nodes (and perhaps other software), and even very high hash power votes cannot prevent an actual fork from appearing afterwards. At best, people lose the guarantee that their confirmations are meaningful (because at some point it becomes clear that the other side will get adopted, and they need to switch). At worst, a fork persists, and two partitions appear, in each of which you can spend every pre-existing coin. This defeats the primary purpose Bitcoin was designed for: double spend protection. * Philosophy: Bitcoin is not a democracy. The full node security model is designed to minimize trust in other parties in the system. This works by validating as much as possible according to the consensus rules. In particular, there is no "majority vote" that can override things (contrary to what some people think, it is not "longest chain wins, and a majority of miners decide"; even a majority of miners cannot steal your coins or produce more than the allowed subsidy, unless they convince others to change their software). Changing the rules should be possible if there is wide consensus, but nobody should feel forced to change their code against their will. * Governance: being able to push for a controversial change to the system sets an incredibly dangerous precedent about who is in charge of the system's rules. What if next time it is a change demanded by parties with less good intentions (and yes, I believe people in this discussions all have good intentions to improve the system in a way they think is most useful)? I can promise you that I will say anything in mail to this list if someone points a gun at me, and I think you should make the same assumption about other people here. By avoiding controversial changes, you avoid external and potentially invisible manipulation. Of course, sometimes changes to the consensus rules may be wanted. The presence of a bug is a good reason, and widespread agreement about one of the system's limitation is too. As I said before, I think technological growth in network bandwidth, processing power, and storage, are a good reason why the system should be able to scale proportionally. I think there are good technical and economic reasons why we should be cautious about this, but the primary requirement is consensus, and aligning people's expectation about what they can expect from network's evolution. -- Pieter --089e0160b7be3c6df70518c9f696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan = <laanwj@gmail.com> wrote:
Like in any open sourc= e project there is lots of decision making ability for code changes. I'= d say look at the changelog for e.g. 0.11 https://github.com/bitcoin/bitcoin/blob/0.11/doc/rel= ease-notes.md#0110-change-log, or follow pull requests for a while, to = see how many decisions about changes are made from day to day. No, I'm = not sitting on my hands, and so is none of the other contributors that you&= #39;d like to get rid of.

The analogy g= oes further even. Even though I disagree with some of the changes you'r= e making, I respect Mike's (and anyone's) right to make a fork of B= itcoin Core. That's how open source works: if people disagree with chan= ges made or not made, they can maintain their own version. However:
=C2=A0
Consensus changes are *much* more difficult, on the other hand. Even relati= vely straightforward softforks come with a long discussion process (see BIP= 62, BIP66). A hardfork is hard to do at the best of times (everyone needs t= o upgrade their software!), and simply not possible if almost the entire te= chnical community disagrees with you.

C= onsensus changes - in particular hardforks - are not about making a change = to the software. You are effectively asking users of the system to migrate = to a new system. Perhaps one which is a philosophical successor to the old = one, but a different system, with new rules that are incompatible with the = old one.

I believe this is something that can only be don= e if there is no controversy about the change, for different reasons:

* Risk: no matter how you determine the switchover date, there= is no way of knowing when (and whether at all) everyone changes their full= nodes (and perhaps other software), and even very high hash power votes ca= nnot prevent an actual fork from appearing afterwards. At best, people lose= the guarantee that their confirmations are meaningful (because at some poi= nt it becomes clear that the other side will get adopted, and they need to = switch). At worst, a fork persists, and two partitions appear, in each of w= hich you can spend every pre-existing coin. This defeats the primary purpos= e Bitcoin was designed for: double spend protection.

* Ph= ilosophy: Bitcoin is not a democracy. The full node security model is desig= ned to minimize trust in other parties in the system. This works by validat= ing as much as possible according to the consensus rules. In particular, th= ere is no "majority vote" that can override things (contrary to w= hat some people think, it is not "longest chain wins, and a majority o= f miners decide"; even a majority of miners cannot steal your coins or= produce more than the allowed subsidy, unless they convince others to chan= ge their software). Changing the rules should be possible if there is wide = consensus, but nobody should feel forced to change their code against their= will.

* Governance: being able to push for a controversi= al change to the system sets an incredibly dangerous precedent about who is= in charge of the system's rules. What if next time it is a change dema= nded by parties with less good intentions (and yes, I believe people in thi= s discussions all have good intentions to improve the system in a way they = think is most useful)? I can promise you that I will say anything in mail t= o this list if someone points a gun at me, and I think you should make the = same assumption about other people here. By avoiding controversial changes,= you avoid external and potentially invisible manipulation.

Of course, sometimes changes to the consensus rules may be wanted. The p= resence of a bug is a good reason, and widespread agreement about one of th= e system's limitation is too. As I said before, I think technological g= rowth in network bandwidth, processing power, and storage, are a good reaso= n why the system should be able to scale proportionally. I think there are = good technical and economic reasons why we should be cautious about this, b= ut the primary requirement is consensus, and aligning people's expectat= ion about what they can expect from network's evolution.

--
=
Pieter

--089e0160b7be3c6df70518c9f696--