Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EEB267AA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 14:36:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 539701BD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 14:36:50 +0000 (UTC)
Received: from mail-ig0-f181.google.com ([209.85.213.181]) by
	mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
	0LlXVp-1YtOI20vJ9-00bNaw for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 16:36:49 +0200
Received: by igfj19 with SMTP id j19so56789718igf.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 07:36:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.50.175 with SMTP id d15mr16873943igo.18.1439822208626;
	Mon, 17 Aug 2015 07:36:48 -0700 (PDT)
Received: by 10.50.104.198 with HTTP; Mon, 17 Aug 2015 07:36:48 -0700 (PDT)
In-Reply-To: <64C86292-6671-4729-8A77-63C081797F62@gmail.com>
References: <20150817100918.BD1F343128@smtp.hushmail.com>
	<1439815244.89850.YahooMailBasic@web173102.mail.ir2.yahoo.com>
	<20150817133438.DDD4243128@smtp.hushmail.com>
	<64C86292-6671-4729-8A77-63C081797F62@gmail.com>
Date: Mon, 17 Aug 2015 15:36:48 +0100
Message-ID: <CALqxMTHfzWr24qELKyYMQ5fy48C1Q-SExCL49w-VMCq2JOdRoQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:95XvfTwdJauS0ykpMMJSGRpGMZ4Sl3q8OtAg8rh9xgPkO9Sl8Q3
	0frZ7oEBPraGPWUXUveOcO9ZvYstWZ2rjuB0Gy0dRRFkebT8vxoNcbLb1DTkXRDLm29zv7X
	iHfpb+hvnV74qfLkFwC83BkS3cqAJRBmOCKer9aQha+QfZ2cGqwlAWdW7VY9fChdjP7Emxj
	kRynpPxUttBxeHlIj0YMQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:RZ1wiXbnl0E=:o/O2rLYB8bh8Q7dF3d6r2A
	OeXxXTPgzndbeIoy7Petu+Jh7oVSApAc1x992OyboVORmqDpi5+lwtyAk7gfDX5Vq8+TDjay2
	unx64iRp/xVoDxMzNCFGSHuJ9YfMFnX+Ni6rnkpKKuqj/Nii/Zu2Wd8rqMqyAZDCZU+PDDPwl
	8EdKZ/E/rfdu9d4B25rTQnTJ/eDLaHAMe5uVx7QhGwU0cwc14Kt2RQN6Sn/8vhBCTF8AgVjpx
	ZKghgsGsfgmwh9saWP7XaFx9xa3lbUa38s4pAbMDWk8CgT+epiS3i3FqsOo0uiuZSCiDx5Z5d
	rA0umWVKiy/GUgG1Ws6HTcSDoe99wVfrkDYxJ8RA1HMvdwMFxANZuVBszg8kd8zOJVrqjUz6S
	I7GOxcVEsmUyTROtoXIMMMNhY2VsIcZKbJT9ACqJRTDuNcky1qO82svDg4baU8pbBONvDLK9B
	KMtzUJ25AFSsbC+nlH/FkLLe0zbXbDfgLfD+Hw6MbB22sVTpn0MmtR1RoBDtkrnEWKMC9NvWa
	qlpyzGKZb/uRywv7ZWYAT/i0Ga1GzLgkoOeSqAX3h5YaNERTXBfvps5Jwz3h4ZLDLVqWy1IM6
	edq0fCCuesvAueT0ZEUOvpuU+z0eeZ4U5Spf2obkDU6JP4IRpWmKvLrHNFQCtaMo+GAsI1Ptd
	IS+VHxaw4Vah7TaQIlvphNdCZj4IzCskSi5LLPqpNGRa3o08dho69AbGM1N0xj/VOlkBGJGsU
	XHy19ikuFXvwZqOX
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2015 14:36:52 -0000

Thank you Eric for saying what needs to be said.

Starting a fork war is just not constructive and there are multiple
proposals being evaluated here.

I think that one thing that is not being so much focussed on is
Bitcoin-XT is both a hard-fork and a soft-fork.  It's a hard-fork on
Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
SPV nodes that did not opt-in.  It exposes those SPV nodes to loss in
the likely event that Bitcoin-XT results in a network-split.

The recent proposal here to run noXT (patch to falsely claim to mine
on XT while actually rejecting it's blocks) could add enough
uncertainty about the activation that Bitcoin-XT would probably have
to be aborted.

Adam

On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> NxtChg,
>
> In the entire history of Bitcoin we=E2=80=99ve never attempted anything e=
ven closely resembling a hard fork like what=E2=80=99s being proposed here.
>
> Many of us have wanted to push our own hard-forking changes to the protoc=
ol=E2=80=A6and have been frustrated because of the inability to do so.
>
> This inability is not due to any malice on anyone=E2=80=99s part=E2=80=A6=
it is a feature of Satoshi=E2=80=99s protocol. For better or worse, it is *=
very hard* to change the rules=E2=80=A6and this is exactly what imbues Bitc=
oin with one of its most powerful attributes: very well-defined settlement =
guarantees that cannot be suddenly altered nor reversed by anyone.
>
> We=E2=80=99ve managed to have a few soft forks in the past=E2=80=A6and fo=
r the most part these changes have been pretty uncontroversial=E2=80=A6or a=
t least, they have not had nearly the level of political divisiveness that =
this block size issue is having. And even then, we=E2=80=99ve encountered a=
 number of problems with these deployments that have at times required good=
will cooperation between developers and mining pool operators to fix.
>
> Again, we have NEVER attempted anything even remotely like what=E2=80=99s=
 being proposed - we=E2=80=99ve never done any sort of hard fork before lik=
e this. If even fairly uncontroversial soft forks have caused problems, can=
 you imagine the kinds of potential problems that a hard fork over some hig=
hly polarizing issue might raise? Do you really think people are going to w=
ant to cooperate?!?
>
> I can understand that some people would like bigger blocks. Other people =
might want feature X, others feature Y=E2=80=A6and we can argue the merits =
of this or that to death=E2=80=A6but the fact remains that we have NEVER at=
tempted any hard forking change=E2=80=A6not even with a simple, totally unc=
ontroversial no-brainer improvement that would not risk any sort of ill-wil=
l that could hamper remedies were it not to go as smoothly as we like. *THI=
S* is the fundamental problem - the whole bigger block thing is a minor iss=
ue by comparison=E2=80=A6it could be any controversial change, really.
>
> Would you want to send your test pilots on their first flight=E2=80=A6the=
 first time an aircraft is ever flown=E2=80=A6directly into combat without =
having tested the plane? This is what attempting a hard fork mechanism that=
=E2=80=99s NEVER been done before in such a politically divisive environmen=
t basically amounts to=E2=80=A6but it=E2=80=99s even worse. We=E2=80=99re b=
asically risking the entire air force (not just one plane) over an argument=
 regarding how many seats a plane should have that we=E2=80=99ve never flow=
n before.
>
> We=E2=80=99re talking billlions of dollars=E2=80=99 worth of other people=
=E2=80=99s money that is on the line here. Don=E2=80=99t we owe it to them =
to at least test out the system on a far less controversial, far less divis=
ive change first to make sure we can even deploy it without things breaking=
? I don=E2=80=99t even care about the merits regarding bigger blocks vs. sm=
aller blocks at this point, to be quite honest - that=E2=80=99s such a pett=
y thing compared to what I=E2=80=99m talking about here. If we attempt a no=
vel hard-forking mechanism that=E2=80=99s NEVER been attempted before (and =
which as many have pointed out is potentially fraught with serious problems=
) on such a politically divisive, polarizing issue, the result is each side=
 will refuse to cooperate with the other out of spite=E2=80=A6and can easil=
y lead to a war, tanking the value of everyone=E2=80=99s assets on both cha=
ins. All so we can process 8 times the number of transactions we currently =
do? Even if it were 100 times, we wouldn=E2=80=99t even come close to touch=
ing big payment processors like Visa. It=E2=80=99s hard to imagine a protoc=
ol improvement that=E2=80=99s worth the risk.
>
> I urge you to at least try to see the bigger picture here=E2=80=A6and to =
understand that nobody is trying to stop anyone from doing anything out of =
some desire for maintaining control - NONE of us are able to deploy hard fo=
rks right now without facing these problems. And different people obviously=
 have different priorities and preferences as to which of these changes wou=
ld be best to do first. This whole XT thing is essentially giving *one* pro=
posal special treatment above those that others have proposed. Many of us h=
ave only held back from doing this out of our belief that goodwill amongst =
network participants is more important than trying to push some pet feature=
 some of us want.
>
> Please stop this negativity - we ALL want the best for Bitcoin and are do=
ing our best, given what we understand and know, to do what=E2=80=99s right=
.