Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_3A40EF2E-722A-4E7B-86EA-1BEF054F06B6";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <20150817133438.DDD4243128@smtp.hushmail.com>
Date: Mon, 17 Aug 2015 07:03:02 -0700
Message-Id: <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>
To: NxtChg <nxtchg@hush.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Precedence: list


--Apple-Mail=_3A40EF2E-722A-4E7B-86EA-1BEF054F06B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

NxtChg,

In the entire history of Bitcoin we=E2=80=99ve never attempted anything =
even 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 =
protocol=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=A6i=
t 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 =
Bitcoin 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 =
for the most part these changes have been pretty uncontroversial=E2=80=A6o=
r at 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 goodwill 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 =
like this. If even fairly uncontroversial soft forks have caused =
problems, can you imagine the kinds of potential problems that a hard =
fork over some highly polarizing issue might raise? Do you really think =
people are going to want 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 attempted any hard forking change=E2=80=A6not even with a =
simple, totally uncontroversial no-brainer improvement that would not =
risk any sort of ill-will that could hamper remedies were it not to go =
as smoothly as we like. *THIS* is the fundamental problem - the whole =
bigger block thing is a minor issue 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 environment basically amounts to=E2=80=A6but it=E2=80=99s even =
worse. We=E2=80=99re basically 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 flown 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 divisive 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. smaller blocks at this point, to be quite honest - =
that=E2=80=99s such a petty thing compared to what I=E2=80=99m talking =
about here. If we attempt a novel 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 easily lead to a =
war, tanking the value of everyone=E2=80=99s assets on both chains. 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 =
touching big payment processors like Visa. It=E2=80=99s hard to imagine =
a protocol 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 forks right now without facing these problems. And different people =
obviously have different priorities and preferences as to which of these =
changes would be best to do first. This whole XT thing is essentially =
giving *one* proposal special treatment above those that others have =
proposed. Many of us have 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 =
doing our best, given what we understand and know, to do what=E2=80=99s =
right.


> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
>=20
>> We should have the highest respect for what these people are doing, =
and we should try to do something constructive, not waste time with =
anger and disrespect.
>=20
> Why, exactly, should I have any respect for what these people are =
doing (and supposedly not have any respect for what the other side is =
doing)?
>=20
> =46rom my point of view, the XT side _does_ something constructive. =
It's the Core side that resorts to dirty tactics and tries to sabotage =
community's free choice instead.
>=20
>=20
>> Nobody should be forced to do anything.
>=20
> Great, so how about you go tell theymos to stop censoring XT posts and =
banning the other side on /r/Bitcoin?
>=20
> Let users decide what Bitcoin is or isn't.
>=20
>=20
>> The developers are not telling you what to do, they are trying to do =
what they consider is best for the ecosystem given their technical =
abilities.
>=20
> The developers & Co are doing their best to stay in power, so they =
could continue imposing their will on Bitcoin ecosystem. This is the =
real power grab, not Gavin and Hearn, who merely provided an =
alternative.
>=20
> And the fear they show is most telling.
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_3A40EF2E-722A-4E7B-86EA-1BEF054F06B6
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV0emWAAoJEJNAI64YFENUMzcP/0Z8e7+zXpj0J5NE+ypH1dCz
IutU1zCrTKSmz6EGsKtVttrWeyKuj6enTtJaY50DtpeUGkUq1kNOiTg+DbLOiMc7
YbhuQqigN7b5Jiu3bOkuonRV440atekQ16JAgHT2qKueLp51eulivO7nylnyKByc
pzG9f3J8BfvPObOeqdgKjePPhFEo3XFvWMV30nFUb7PVtIFJj8U0d4AvlYOwrakx
OICivRNoic6ncX7hNKAA79eLueep+ZOyAxMgsniCeuM0H2ZEOExdlUALt2AB3skI
IuRL4meD25602iW6PYjeEJlAj0Xu37V0vbCJAuEDnIn4PZeoqmmIeU8NXmcfS88H
Vahcst92Oa1ZdzGa3XskZRSlwJivcFrwBhIMvH9v/zLPer6DyaYO3LgcBNYuaygL
Og05GZNbcjkdUNGYX9JfZyIti+uNHJaZUcYgRzAFWgmeX0Ut5RYeObm3JbQ1e/LZ
XAhOfujVfRSdL5aHFYDkDx1w88wXISaIhfH8J0zQwqkeO9G3GGq9lwsYoqCOx/iV
IjjENkPL1g7UjGYTwsOh3qWLsdY4YKwq94kxYEuTD5vUkQYXAK6v8fuQQofSF7rw
W8msyCf3jDJDtr9RL2Xje5t12CQTxQ24R/TZtDHf0LeP3LUX3Sq7tn94t7Gb9tyR
D4Y/EnhqgAIXKaAWL4fr
=2KxU
-----END PGP SIGNATURE-----

--Apple-Mail=_3A40EF2E-722A-4E7B-86EA-1BEF054F06B6--