path: root/f4/5f726e8da5cdbc009351ef8ce89e5a4dac5b1c

Return-Path: <post@levinkeller.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 485EF7F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 14:09:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f41.google.com (mail-la0-f41.google.com
	[209.85.215.41])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD49D18E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 14:09:29 +0000 (UTC)
Received: by labd1 with SMTP id d1so80283231lab.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 07:09:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc:content-type;
	bh=/w6bEYZijs8kX04veGY/h3TrvJdxoniCpomHCn0ruyA=;
	b=Jxd8dVXQ/5vxd6ciwQ+28Tbyg/CsNGw8mpLkcIUW3eZzBLkNc5FSuy7bdNj1XyTlr9
	mVKx8Ja+J0NSF/y7CKbTxvZFjRXVIVHoFsIvXINAqMpjdVimSMUz7ie/sAYRVlqcwPDq
	16okME2JSSXjvCu9bvsUFLJOlHztOE2lOhSqxZKmeVhH0w3XCL8n2N5SkAPskCzIHMd5
	K4vg8/x4EGRckaDPw28s/KVOZjDPa2pZ5sFG11GRpPDecwFBY9PZDxP9iUoHvXHVRBTL
	JtRdOZWZ/caz3wpbLiVhXqYj1Um1zp7jC5+0DJbU1nKVKBz5z1K1sjk10+4wkgWE87Iu
	DXuw==
X-Gm-Message-State: ALoCoQnmeDUni8dlSChenibsvlS1m/MK3LB4Rqk8gwPWnFTCscUJvfYyt/bE7c6wOV8+5zq4/BYY
X-Received: by 10.152.43.228 with SMTP id z4mr1115052lal.99.1439820567771;
	Mon, 17 Aug 2015 07:09:27 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <64C86292-6671-4729-8A77-63C081797F62@gmail.com>
From: Levin Keller <post@levinkeller.de>
Date: Mon, 17 Aug 2015 14:09:17 +0000
Message-ID: <CAG86ZOxWBMaBKzgRUp=Q5TvaT1v3OjNRFx2Xofd4FdLvpg9dGQ@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>, NxtChg <nxtchg@hush.com>
Content-Type: multipart/alternative; boundary=001a11c2280c7b97c0051d8259a0
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	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@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:09:31 -0000

--001a11c2280c7b97c0051d8259a0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
schrieb am Mo., 17. Aug. 2015 um 16:03 Uhr:

> 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
> 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=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 Bitcoin with one of its mos=
t powerful
> attributes: very well-defined settlement guarantees that cannot be sudden=
ly
> 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 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 thi=
s. If even
> fairly uncontroversial soft forks have caused problems, can you imagine t=
he
> 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 merit=
s of this
> or that to death=E2=80=A6but the fact remains that we have NEVER attempte=
d 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 havin=
g tested
> the plane? This is what attempting a hard fork mechanism that=E2=80=99s N=
EVER 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 t=
he 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 th=
e 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 abo=
ut 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 b=
een
> attempted before (and which as many have pointed out is potentially fraug=
ht
> 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 cl=
ose 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 o=
f
> 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 belie=
f
> that goodwill amongst network participants is more important than trying =
to
> push some pet feature some of us want.
>

Yadayadayada.

If someone could threaten the network by releasing a hard-forking bitcoind
version, then already all is lost. Bitcoins stability does not (and cannot)
depend on the "good will" of anyone. If it would, we should all abandon
this silly project. Relying on the good will of people is the worst idea
one could have.

So please (please please) go ahead and release your hardforking bitcoinds
you have been holding back. Competition is everything.

Cheers

Levin


>
> 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 r=
ight.
>
>
>
> > On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >
> >> We should have the highest respect for what these people are doing, an=
d
> we should try to do something constructive, not waste time with anger and
> disrespect.
> >
> > 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)?
> >
> > From 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.
> >
> >
> >> Nobody should be forced to do anything.
> >
> > Great, so how about you go tell theymos to stop censoring XT posts and
> banning the other side on /r/Bitcoin?
> >
> > Let users decide what Bitcoin is or isn't.
> >
> >
> >> 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.
> >
> > The developers & Co are doing their best to stay in power, so they coul=
d
> continue imposing their will on Bitcoin ecosystem. This is the real power
> grab, not Gavin and Hearn, who merely provided an alternative.
> >
> > And the fear they show is most telling.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Eric L=
ombrozo via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; schrieb am Mo., 17.=
 Aug. 2015 um 16:03=C2=A0Uhr:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">NxtCh=
g,<br>
<br>
In the entire history of Bitcoin we=E2=80=99ve never attempted anything eve=
n closely resembling a hard fork like what=E2=80=99s being proposed here.<b=
r>
<br>
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.<br>
<br>
This inability is not due to any malice on anyone=E2=80=99s part=E2=80=A6it=
 is a feature of Satoshi=E2=80=99s protocol. For better or worse, it is *ve=
ry hard* to change the rules=E2=80=A6and this is exactly what imbues Bitcoi=
n with one of its most powerful attributes: very well-defined settlement gu=
arantees that cannot be suddenly altered nor reversed by anyone.<br>
<br>
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=A6or at =
least, they have not had nearly the level of political divisiveness that th=
is block size issue is having. And even then, we=E2=80=99ve encountered a n=
umber of problems with these deployments that have at times required goodwi=
ll cooperation between developers and mining pool operators to fix.<br>
<br>
Again, we have NEVER attempted anything even remotely like what=E2=80=99s b=
eing 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 y=
ou imagine the kinds of potential problems that a hard fork over some highl=
y polarizing issue might raise? Do you really think people are going to wan=
t to cooperate?!?<br>
<br>
I can understand that some people would like bigger blocks. Other people mi=
ght 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 atte=
mpted any hard forking change=E2=80=A6not even with a simple, totally uncon=
troversial 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.<br>
<br>
Would you want to send your test pilots on their first flight=E2=80=A6the f=
irst time an aircraft is ever flown=E2=80=A6directly into combat without ha=
ving 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.<br>
<br>
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.<br>
<br>
I urge you to at least try to see the bigger picture here=E2=80=A6and to un=
derstand that nobody is trying to stop anyone from doing anything out of so=
me desire for maintaining control - NONE of us are able to deploy hard fork=
s right now without facing these problems. And different people obviously h=
ave different priorities and preferences as to which of these changes would=
 be best to do first. This whole XT thing is essentially giving *one* propo=
sal special treatment above those that others have proposed. Many of us hav=
e only held back from doing this out of our belief that goodwill amongst ne=
twork participants is more important than trying to push some pet feature s=
ome of us want.<br></blockquote><div><br></div><div>Yadayadayada.</div><div=
><br></div><div>If someone could threaten the network by releasing a hard-f=
orking bitcoind version, then already all is lost. Bitcoins stability does =
not (and cannot) depend on the &quot;good will&quot; of anyone. If it would=
, we should all abandon this silly project. Relying on the good will of peo=
ple is the worst idea one could have.</div><div><br></div><div>So please (p=
lease please) go ahead and release your hardforking bitcoinds you have been=
 holding back. Competition is everything.</div><div><br></div><div>Cheers</=
div><div><br></div><div>Levin</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<br>
Please stop this negativity - we ALL want the best for Bitcoin and are doin=
g our best, given what we understand and know, to do what=E2=80=99s right.<=
br>
<br>
<br>
<br>
&gt; On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;&gt; 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.<br>
&gt;<br>
&gt; Why, exactly, should I have any respect for what these people are doin=
g (and supposedly not have any respect for what the other side is doing)?<b=
r>
&gt;<br>
&gt; From my point of view, the XT side _does_ something constructive. It&#=
39;s the Core side that resorts to dirty tactics and tries to sabotage comm=
unity&#39;s free choice instead.<br>
&gt;<br>
&gt;<br>
&gt;&gt; Nobody should be forced to do anything.<br>
&gt;<br>
&gt; Great, so how about you go tell theymos to stop censoring XT posts and=
 banning the other side on /r/Bitcoin?<br>
&gt;<br>
&gt; Let users decide what Bitcoin is or isn&#39;t.<br>
&gt;<br>
&gt;<br>
&gt;&gt; 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 abili=
ties.<br>
&gt;<br>
&gt; The developers &amp; 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.<br>
&gt;<br>
&gt; And the fear they show is most telling.<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--001a11c2280c7b97c0051d8259a0--