path: root/98/7689edd8de155eade9fe404db85b230fdf7b7d

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1Z4R8K-00026A-I4
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jun 2015 09:56:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.49 as permitted sender)
	client-ip=74.125.82.49; envelope-from=mh.in.england@gmail.com;
	helo=mail-wg0-f49.google.com; 
Received: from mail-wg0-f49.google.com ([74.125.82.49])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z4R8I-0004VN-Pw
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jun 2015 09:56:48 +0000
Received: by wgez8 with SMTP id z8so64382836wge.0
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 15 Jun 2015 02:56:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.104.197 with SMTP id gg5mr30264874wib.27.1434362200785; 
	Mon, 15 Jun 2015 02:56:40 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Mon, 15 Jun 2015 02:56:40 -0700 (PDT)
In-Reply-To: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com>
References: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com>
Date: Mon, 15 Jun 2015 11:56:40 +0200
X-Google-Sender-Auth: zhqN9Ez25T7hvemS3OTM6M2VpYk
Message-ID: <CANEZrP31AEson9DZ=ZU7d4t=DvmGodh1ja6EaZ6xQZ3bFEXeVA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=f46d041825bc7509bb05188b793e
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: 1Z4R8I-0004VN-Pw
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &
	non-consensus hard-fork
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 09:56:48 -0000

--f46d041825bc7509bb05188b793e
Content-Type: text/plain; charset=UTF-8

Hi Adam,

Provisional answers below!

- Are you releasing a BIP for that proposal for review?
>

The work splits like this:

   - Gavin is writing the code and I think a BIP as well

   - I will review both and mostly delegate to Gavin's good taste around
   the details, unless there is some very strong disagreement. But that seems
   unlikely.

   - I have been handling gitian and the patch rebases, the code signing
   and so on, so far. I've also been doing some work to setup the basic
   infrastructure of the project (website etc).


- If the reviewers all say NACK will you take on board their suggestions?
>

Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
aren't scored in any way. The final decision rests with the maintainer as
in ~all open source projects.



> - On the idea of a non-consensus hard-fork at all, I think we can
> assume you will get a row of NACKs.  Can you explain your rationale
> for going ahead anyway?  The risks are well understood and enormous.
>

Yes, I have been working on an article that explains how we got to this
point from my perspective. It is quite long, but only because I want it to
be readable for people who weren't following the debate.

Anyway, I think I've laid out the gist of it over and over again, but to
summarise:

If Bitcoin runs out of capacity *it will break and many of our users will
leave*. That is not an acceptable outcome for myself or the many other
wallet, service and merchant developers who have worked for years to build
an ecosystem around this protocol.



> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks?  Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.
>

The approach is the same for other forks. Voting via block versions and
then when there's been >X% for Y time units the 1mb limit is
lifted/replaced.




> - If you're going it alone as it were, are you proposing that you will
> personally maintain bitcoin-XT?  Or do you have a plan to later hand
> over maintenance to the bitcoin developers?
>

Good question!  I have various thoughts on this, but let's wait and see
what happens first. Perhaps the new chain won't get the majority on it.

In the event that the >1mb chain does eventually win, I would expect Core
to apply the patch and rejoin the consensus rather than lose all its users.
That would take XT back to being a fairly small patchset to improve the
network protocol.



- Do you have contingency plans for what to do if the non-consensus
> hard-fork goes wrong and $3B is lost as a result?
>

Where did you get the $3B figure from? The fork either doesn't happen, or
it happens after quite a long period of people knowing it's going to happen
- for example because their full node is printing "You need to upgrade"
messages due to seeing the larger block version, or because they read the
news, or because they heard about it via some other mechanisms.

Let me flip the question around. Do you have a contingency plan if Bitcoin
runs out of capacity and significant user disruption occurs that results in
exodus, followed by fall in BTC price? The only one I've seen is "we can
perform an emergency hard fork in a few weeks"!



> As you can probably tell I think a unilateral fork without wide-scale
> consensus from the technical and business communities is a deeply
> inadvisable.


Gavin and I have been polling many key players in the ecosystem. The
consensus you seek does exist. All wallet developers (except Lawrence), all
the major exchanges, all the major payment processors and many of the major
mining pools want to see the limit lifted (I haven't been talking to pools,
Gavin has).

This notion that the change has no consensus is based on you polling the
people directly around you and people who like to spend all day on this
mailing list. It's not an accurate reflection of the wider Bitcoin
community and that is one of the leading reasons there is going to be a
fork. A small number of people have been flatly ignoring LOTS of highly
technical and passionate developers who have written vast amounts of code,
built up the Bitcoin user base, designed hardware and software, and yes
built companies.

How do you think that makes Bitcoin Core look to the rest of the Bitcoin
world? How much confidence does that give people?



Of the overall process, I think you can agree we should not be making
> technical decisions with this level of complexity and consensus risk
> with financial implications of this magnitude under duress of haste?
>

This debate will never end until a fork makes it irrelevant. There is no
process for ending it, despite me begging Wladimir to make one.

And there is no haste. We have been debating the block size limit for
*years*. We have known it must be lifted for *years*. I kicked off this
current round of debates after realising that Wladimir's release timeline
wouldn't allow a block size limit to be released before the end of the
year. The reason we're talking about it now and not next year is exactly to
ensure there is plenty of time.




> I can sincerely assure you everyone does want to scale bitcoin and
> shares your long term objective on that


I really wish you were right, and I definitely feel you are one of the more
reasonable ones Adam. But the overwhelming impression I get from a few
others here is that no, they don't want to scale Bitcoin. They already
decided it's a technological dead end. They want to kick end users out in
order to "incentivise" (force) the creation of some other alternative,
claiming that it's still Bitcoin whilst ignoring basic details ... like the
fact that no existing wallets or services would work.

Scaling Bitcoin can only be achieved by letting it grow, and letting people
tackle each bottleneck as it arises at the right times. Not by convincing
ourselves that success is failure.

--f46d041825bc7509bb05188b793e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Adam,<div><br></div><div>Provisional answers below!<br>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
- Are you releasing a BIP for that proposal for review?<br></blockquote><di=
v><br></div><div>The work splits like this:</div><div><ul><li>Gavin is writ=
ing the code and I think a BIP as well<br><br></li><li>I will review both a=
nd mostly delegate to Gavin&#39;s good taste around the details, unless the=
re is some very strong disagreement. But that seems unlikely.<br><br></li><=
li>I have been handling gitian and the patch rebases, the code signing and =
so on, so far. I&#39;ve also been doing some work to setup the basic infras=
tructure of the project (website etc).</li></ul></div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">- If the reviewers all say NACK will you take on board their sug=
gestions?<br></blockquote><div><br></div><div>Feedback will be read. There =
are no NACKS in Bitcoin XT. Patch requests aren&#39;t scored in any way. Th=
e final decision rests with the maintainer as in ~all open source projects.=
</div><div><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex">- On the idea of=
 a non-consensus hard-fork at all, I think we can<br>
assume you will get a row of NACKs.=C2=A0 Can you explain your rationale<br=
>
for going ahead anyway?=C2=A0 The risks are well understood and enormous.<b=
r></blockquote><div><br></div><div>Yes, I have been working on an article t=
hat explains how we got to this point from my perspective. It is quite long=
, but only because I want it to be readable for people who weren&#39;t foll=
owing the debate.</div><div><br></div><div>Anyway, I think I&#39;ve laid ou=
t the gist of it over and over again, but to summarise:</div><div><br></div=
></div></div></div><blockquote style=3D"margin:0px 0px 0px 40px;border:none=
;padding:0px"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv>If Bitcoin runs out of capacity <b>it will break and many of our users w=
ill leave</b>. That is not an acceptable outcome for myself or the many oth=
er wallet, service and merchant developers who have worked for years to bui=
ld an ecosystem around this protocol.</div><div><br></div></div></div></div=
></blockquote><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">- How do you propose to deal with the extra=
 risks that come from<br>
non-consensus hard-forks?=C2=A0 Hard-forks themselves are quite risky, but<=
br>
non-consensus ones are extremely dangerous for consensus.<br></blockquote><=
div><br></div><div>The approach is the same for other forks. Voting via blo=
ck versions and then when there&#39;s been &gt;X% for Y time units the 1mb =
limit is lifted/replaced.</div><div><br></div><div><br></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">- If you&#39;re going it alone as it were, are you prop=
osing that you will<br>
personally maintain bitcoin-XT?=C2=A0 Or do you have a plan to later hand<b=
r>
over maintenance to the bitcoin developers?<br></blockquote><div><br></div>=
<div>Good question!=C2=A0 I have various thoughts on this, but let&#39;s wa=
it and see what happens first. Perhaps the new chain won&#39;t get the majo=
rity on it.</div><div><br></div><div>In the event that the &gt;1mb chain do=
es eventually win, I would expect Core to apply the patch and rejoin the co=
nsensus rather than lose all its users. That would take XT back to being a =
fairly small patchset to improve the network protocol.</div><div><br></div>=
<div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex">- Do you have contingency =
plans for what to do if the non-consensus<br>
hard-fork goes wrong and $3B is lost as a result?<br></blockquote><div><br>=
</div><div>Where did you get the $3B figure from? The fork either doesn&#39=
;t happen, or it happens after quite a long period of people knowing it&#39=
;s going to happen - for example because their full node is printing &quot;=
You need to upgrade&quot; messages due to seeing the larger block version, =
or because they read the news, or because they heard about it via some othe=
r mechanisms.</div><div><br></div><div>Let me flip the question around. Do =
you have a contingency plan if Bitcoin runs out of capacity and significant=
 user disruption occurs that results in exodus, followed by fall in BTC pri=
ce? The only one I&#39;ve seen is &quot;we can perform an emergency hard fo=
rk in a few weeks&quot;!</div><div><br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex">As you can probably tell I think a unilateral fork without wide-scale<b=
r>
consensus from the technical and business communities is a deeply<br>
inadvisable.=C2=A0 </blockquote><div><br></div><div>Gavin and I have been p=
olling many key players in the ecosystem. The consensus you seek does exist=
. All wallet developers (except Lawrence), all the major exchanges, all the=
 major payment processors and many of the major mining pools want to see th=
e limit lifted (I haven&#39;t been talking to pools, Gavin has).=C2=A0</div=
><div><br></div><div>This notion that the change has no consensus is based =
on you polling the people directly around you and people who like to spend =
all day on this mailing list. It&#39;s not an accurate reflection of the wi=
der Bitcoin community and that is one of the leading reasons there is going=
 to be a fork. A small number of people have been flatly ignoring LOTS of h=
ighly technical and passionate developers who have written vast amounts of =
code, built up the Bitcoin user base, designed hardware and software, and y=
es built companies.=C2=A0</div><div><br></div><div>How do you think that ma=
kes Bitcoin Core look to the rest of the Bitcoin world? How much confidence=
 does that give people?</div><div><br></div><div><br></div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">
Of the overall process, I think you can agree we should not be making<br>
technical decisions with this level of complexity and consensus risk<br>
with financial implications of this magnitude under duress of haste?<br></b=
lockquote><div><br></div><div>This debate will never end until a fork makes=
 it irrelevant. There is no process for ending it, despite me begging Wladi=
mir to make one.</div><div><br></div><div>And there is no haste. We have be=
en debating the block size limit for <u>years</u>. We have known it must be=
 lifted for <u>years</u>. I kicked off this current round of debates after =
realising that Wladimir&#39;s release timeline wouldn&#39;t allow a block s=
ize limit to be released before the end of the year. The reason we&#39;re t=
alking about it now and not next year is exactly to ensure there is plenty =
of time.</div><div><br></div><div><br></div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x">I can sincerely assure you everyone does want to scale bitcoin and<br>
shares your long term objective on that</blockquote><div><br></div><div>I r=
eally wish you were right, and I definitely feel you are one of the more re=
asonable ones Adam. But the overwhelming impression I get from a few others=
 here is that no, they don&#39;t want to scale Bitcoin. They already decide=
d it&#39;s a technological dead end. They want to kick end users out in ord=
er to &quot;incentivise&quot; (force) the creation of some other alternativ=
e, claiming that it&#39;s still Bitcoin whilst ignoring basic details ... l=
ike the fact that no existing wallets or services would work.</div><div><br=
></div><div>Scaling Bitcoin can only be achieved by letting it grow, and le=
tting people tackle each bottleneck as it arises at the right times. Not by=
 convincing ourselves that success is failure.</div><div><br></div></div></=
div></div></div>

--f46d041825bc7509bb05188b793e--