From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5ZvF-0005YB-Uu for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 13:32:01 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.43 as permitted sender) client-ip=74.125.82.43; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f43.google.com; Received: from mail-wg0-f43.google.com ([74.125.82.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5ZvE-0007ON-Cy for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 13:32:01 +0000 Received: by wgfq1 with SMTP id q1so17195631wgf.1 for ; Thu, 18 Jun 2015 06:31:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.209.130 with SMTP id mm2mr15420375wjc.64.1434634314368; Thu, 18 Jun 2015 06:31:54 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.28.14.196 with HTTP; Thu, 18 Jun 2015 06:31:54 -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 15:31:54 +0200 X-Google-Sender-Auth: AEzoNtA1xpEgIJFqFVDAuWfmLFs Message-ID: From: Mike Hearn To: "Wladimir J. van der Laan" Content-Type: multipart/alternative; boundary=047d7b3a82e2b0cc7e0518cad43e X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Z5ZvE-0007ON-Cy 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 13:32:02 -0000 --047d7b3a82e2b0cc7e0518cad43e Content-Type: text/plain; charset=UTF-8 OK, let's agree to unpack the two things. The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people with commit access? Is it a 100% agreement of "core developers" and if so, who are these people? Is it "whoever reverts the change last"? Could I write down in a document a precise description of how decisions are made? No, and that's been a fairly frustrating problem for a long time. But let's leave it to one side for a moment. Let's focus on the other issue: what happens if the Bitcoin Core decision making process goes wrong? For the sake of argument let's pretend we're discussing a different change, let's imagine there is a proposal to change the block format to include a Widget, where a Widget is some potentially desirable thing. And this change means a hard fork. Let's put the block size to one side for a second to avoid getting distracted. Imagine that 90% of people in Bitcoin want their Widgets, but one of your committers refuses to accept it. I am not saying the block size debate has such proportions but pretend Widgets do. What is the process for resolving this problem? Gavin and I say - there is a process, and that process is a hard fork of the block chain. What you're saying is - there is no process because a contentious hard fork must never happen. Such a change is simply impossible. Now which is a better description of this situation? Is the "it must never happen end of story" really the cuddly warm democracy that you seem to suggest? Or is it more like a dictatorship where the opinions of one or two people can override all the others? The typical answer I'm seeing to this is that Bitcoin Core's own decision making process is so fantastic that it never goes wrong, even though "consensus" is not defined and "technical majority" is not defined and we have serious long time contributors on this mailing list (such as wallet developers) disagreeing with this consensus yet our feedback is being ignored. You guys *must* accept that your preferred process for resolving disputes is, itself, in dispute. That leaves the block chain itself as the only remaining method for bringing this saga to a close. So this is why we keep disagreeing: - If Bitcoin Core has reached a formal decision made by the maintainer via whatever mechanism he likes to not accept the block size increase, then alright, technical disputes will happen. But .... - You should agree that the next step is a fork of both the software and the block chain. And you should welcome such a thing because it is the ONLY check on your own power. It's the one thing that allows the community to reject the decision making process you are using in case it goes wrong. I keep reading that Bitcoin cannot survive a hard fork. Well, we've survived an accidental fork that happened without anyone being prepared, and even with a planned soft fork "never upgrade" isn't really an option for either miners or businesses, so ultimately node operators must know about upgrades and make them. Both myself and Gavin think this process can work out OK. Do you at least understand where we're coming from here, even if you disagree? And if you disagree, is it because you think a hard fork to resolve a dispute can't work technically, or is it some other reason? --047d7b3a82e2b0cc7e0518cad43e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, let's agree to unpack the two things.

The= first issue is how are decisions made in Bitcoin Core? I struggle to expla= in this to others because I don't understand it myself. Is it a vote of= people with commit access? Is it a 100% agreement of "core developers= " and if so, who are these people? Is it "whoever reverts the cha= nge last"?=C2=A0 Could I write down in a document a precise descriptio= n of how decisions are made? No, and that's been a fairly frustrating p= roblem for a long time.

But let's leave it to = one side for a moment.

Let's focus on the othe= r issue: =C2=A0 what happens if the Bitcoin Core decision making process go= es wrong?=C2=A0

For the sake of argument let's= pretend we're discussing a different change, let's imagine there i= s a proposal to change the block format to include a Widget, where a Widget= is some potentially desirable thing. And this change means a hard fork. Le= t's put the block size to one side for a second to avoid getting distra= cted.

Imagine that 90% of people in Bitcoin want t= heir Widgets, but one of your committers refuses to accept it.=C2=A0 I am n= ot saying the block size debate has such proportions but pretend Widgets do= .

What is the process for resolving this problem?<= /div>

Gavin and I say - there is a process, and that pro= cess is a hard fork of the block chain.

What you&#= 39;re saying is - there is no process because a contentious hard fork must = never happen. Such a change is simply impossible.

= Now which is a better description of this situation? Is the "it must n= ever happen end of story" really the cuddly warm democracy that you se= em to suggest? Or is it more like a dictatorship where the opinions of one = or two people can override all the others?

The typ= ical answer I'm seeing to this is that Bitcoin Core's own decision = making process is so fantastic that it never goes wrong, even though "= consensus" is not defined and "technical majority" is not de= fined and we have serious long time contributors on this mailing list (such= as wallet developers) disagreeing with this consensus yet our feedback is = being ignored.

You guys must=C2=A0accept th= at your preferred process for resolving disputes is, itself, in dispute. Th= at leaves the block chain itself as the only remaining method for bringing = this saga to a close.

So this is why we keep disag= reeing:
  • If Bitcoin Core has reached a formal decision mad= e by the maintainer via whatever mechanism he likes=C2=A0to not accept the = block size increase, then alright, technical disputes will happen. But ....=

  • You should agree that the next step is a fork of both the = software and the block chain. And you should welcome such a thing because i= t is the ONLY check on your own power. It's the one thing that allows t= he community to reject the decision making process you are using in case it= goes wrong.
I keep reading that Bitcoin cannot survive a har= d fork. Well, we've survived an accidental fork that happened without a= nyone being prepared, and even with a planned soft fork "never upgrade= " isn't really an option for either miners or businesses, so ultim= ately node operators must know about upgrades and make them. Both myself an= d Gavin think this process can work out OK.

Do you= at least understand where we're coming from here, even if you disagree= ? And if you disagree, is it because you think a hard fork to resolve a dis= pute can't work technically, or is it some other reason?
--047d7b3a82e2b0cc7e0518cad43e--