path: root/d5/15b8ec215abfb6d9beb9020525558e4fc8c18a

Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6BA47E48;
	Sun,  7 Feb 2016 15:06:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com
	[209.85.213.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D40D2F;
	Sun,  7 Feb 2016 15:06:07 +0000 (UTC)
Received: by mail-ig0-f179.google.com with SMTP id y8so15682862igp.0;
	Sun, 07 Feb 2016 07:06:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=E9FcgYef3xDuPAqAOeAuGTYReS8Aun8LREUW7vRJAvM=;
	b=SamtgiJKJPKbz862v3e6/96C1DjAKEoc1NPWr0CBtPCNY6rQtHh6KRToVbrOQ9hbDm
	CtPHLkrSmFlSsZ3vUnr5nG9C7/pY7xO5yz8JgzRMHJXq7ZIlB1QpsHTkYBmtEG1K8uIT
	Z/eszQOPrU0Tp8sbXnuV2sYdEU+vUNW+4f2BjBXDoCLHuE7zzTdaq8IEuu0fq+t65oi/
	uS+33rWQ1n4+1c2cdtFCoRfygUCRP1SfF3d+lyC57DJr3Kh0e/TL4C3iVZGIK7tileLT
	FO64+RX/ALynEk0xhUYkk9e4rlKFh/W7qPTDTdDWDm8d9EmwYAJIo4obkV2PxlJ2iHzM
	6rXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=E9FcgYef3xDuPAqAOeAuGTYReS8Aun8LREUW7vRJAvM=;
	b=D3oSbobQkTHAeOivnrA9GZMZB9B4O+1QXezU+Kof9uoyxItnYets/luumAtjrUHQeh
	Hjx05Bp00ourfdaRF1TaWim7rbusJ00zb2ZLmYv5mvxH6CJOkKcEI2RaFIXsH+wsfvon
	fvcBBQlYfAbxE3l7qQywCsbMcRNboj1Um9oCFGIsQb2aEyOjeHllZ/FEf/SrPvtfxJe9
	uHx/RwakMWNydlimbZk5yIJd8xKYZ9/zwEgGE90k29UKee7nqOM2aNJdQ7QrT8/yMM95
	xev0G1nCjw8+sd5/n/+eT+ErqZi5+NBdhOa8r4XnlS8SDmWj6j35DggtFcPXM9HZe2F2
	+P8w==
X-Gm-Message-State: AG10YOShoj0czf9z6YSrqvLsVjeG9amTN0MoTN50nz0Qe5Q6XSnSygHX0nO8S4OklN8ORs3Rc/T0m9BHA33UAw==
MIME-Version: 1.0
X-Received: by 10.50.60.41 with SMTP id e9mr19810423igr.35.1454857566747; Sun,
	07 Feb 2016 07:06:06 -0800 (PST)
Received: by 10.64.113.193 with HTTP; Sun, 7 Feb 2016 07:06:06 -0800 (PST)
In-Reply-To: <CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<CABm2gDoungCbB22_SKHcedBKegWEPpjeM2woxLGchC4=om8BrA@mail.gmail.com>
	<1804222.7gVHPiWqto@kiwi> <201602062046.40193.luke@dashjr.org>
	<CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
Date: Sun, 7 Feb 2016 10:06:06 -0500
Message-ID: <CAPWm=eVG1MFygACo6Mb6iLSe=GwjygTjjKhmN1Btu9Uyw+Vc-w@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>,
	bitcoin-discuss@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=047d7b10cea577061d052b2f6c27
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
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: Sun, 07 Feb 2016 15:06:11 -0000

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

I apologize if this discussion should be moved to -discuss, I'll let the
moderators decide, I've copied both.

And Gavin, I apologize for picking on you here, because certainly this
carelessness in how people represent "facts" applies to both sides, but
much of this discussion really infuriates me.
I believe it is completely irresponsible for you to state:
"There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners"
Sure, the rest of the technical community is capable of evaluating that for
themselves, but your statements are considered authoritative by much larger
audience.  In truth, no one has any idea what would happen if the proposed
Classic hard fork activated with 75% right now.  There is some chance you
are right, but there is a very legitimate possibility that a concerted
effort would arise to maintain a minority fork or perhaps if miners don't
see nearly a complete switch over, many of them might themselves reverse
the fork if they think it would be easier to achieve consensus that way.
We as a community have never been in such a situation before and it
behooves us to speak honestly and directly about the uncertainty of the
situation.

And the back and forth discussion over your BIP has been in large part a
charade.  People asking why you aren't picking 95% know very well why you
aren't, but lets have an honest discussion of what the risks and in your
mind potential benefits of 75% are.   Important debate about parameters of
your BIP get lost because we're sniping at each other about known
disagreements.  For instance, I strongly believe 28 days is far too short.
I think its extremely unlikely that those who are opposed to a contentious
hard fork will do the development work to prepare for it as that may only
make it more likely to happen.  Thus if you did achieve activation with
75%, its almost impossible to imagine that if Bitcoin Core decided to come
along (as opposed to pursuing a minority fork) that they'd have the time to
develop and test the patch and roll it out to wide adoption.   If the goal
of your attempt is that any minority that disagreed will "choose" to follow
the majority branch, then you'd be much more likely to achieve that by
giving them time to decide that's what they wanted and roll out the
software to do so.




On Sun, Feb 7, 2016 at 9:16 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>> wrote:
>> > On Saturday, February 06, 2016 06:09:21 PM Jorge Tim=C3=B3n via bitcoi=
n-dev
>> wrote:
>> > > None of the reasons you list say anything about the fact that "being
>> > > lost" (kicked out of the network) is a problem for those node's user=
s.
>> >
>> > That's because its not.
>> >
>> > If you have a node that is "old" your node will stop getting new block=
s.
>> > The node will essentially just say "x-hours behind" with "x" getting
>> larger
>> > every hour. Funds don't get confirmed. etc.
>>
>> Until someone decides to attack you. Then you'll get 6, 10, maybe more
>> blocks
>> confirming a large 10000 BTC payment. If you're just a normal end user (=
or
>> perhaps an automated system), you'll figure that payment is good and
>> irreversibly hand over the title to the house.
>>
>
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (th=
ey
> upgrade VERY quickly from 75% to over 95%).
>
> So it will take a week to get 6 confirmations.
>
> If you are a full node, you are warned that your software is obsolete and
> you must upgrade.
>
> If you are a lightweight node, it SHOULD tell you something is wrong, but
> even if it doesn't, given that people running lightweight nodes run them =
so
> they don't have to be connected to the network 24/7, it is very likely
> during that week you disconnect and reconnect to the network several time=
s.
> And every time you do that you increase your chances that you will connec=
t
> to full nodes on the majority branch of the chain, where you will be told
> about the double-spend.
>
> All of that is assuming that there is no OTHER mitigation done. DNS seeds
> should avoid reporting nodes that look like they are in the middle of
> initial block download (that are at a block height significantly behind t=
he
> rest of the network), for example.
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">I apologize if this discussion should be moved to -discuss=
, I&#39;ll let the moderators decide, I&#39;ve copied both.<div><br></div><=
div>And Gavin, I apologize for picking on you here, because certainly this =
carelessness in how people represent &quot;facts&quot; applies to both side=
s, but much of this discussion really infuriates me.</div><div>I believe it=
 is completely irresponsible for you to state:</div><div>&quot;<span style=
=3D"font-size:12.8px">There will be approximately zero percentage of hash p=
ower left on the weaker branch of the fork, based on past soft-fork adoptio=
n by miners&quot;</span></div><div><span style=3D"font-size:12.8px">Sure, t=
he rest of the technical community is capable of evaluating that for themse=
lves, but your statements are considered authoritative by much larger audie=
nce.=C2=A0 In truth, no one has any idea what would happen if the proposed =
Classic hard fork activated with 75% right now.=C2=A0 There is some chance =
you are right, but there is a very legitimate possibility that a concerted =
effort would arise to maintain a minority fork or perhaps if miners don&#39=
;t see nearly a complete switch over, many of them might themselves reverse=
 the fork if they think it would be easier to achieve consensus that way.=
=C2=A0 We as a community have never been in such a situation before and it =
behooves us to speak honestly and directly about the uncertainty of the sit=
uation.</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">And the back and forth discussion ove=
r your BIP has been in large part a charade.=C2=A0 People asking why you ar=
en&#39;t picking 95% know very well why you aren&#39;t, but lets have an ho=
nest discussion of what the risks and in your mind potential benefits of 75=
% are. =C2=A0 Important debate about parameters of your BIP get lost becaus=
e we&#39;re sniping at each other about known disagreements.=C2=A0 For inst=
ance, I strongly believe 28 days is far too short.=C2=A0 I think its extrem=
ely unlikely that those who are opposed to a contentious hard fork will do =
the development work to prepare for it as that may only make it more likely=
 to happen.=C2=A0 Thus if you did achieve activation with 75%, its almost i=
mpossible to imagine that if Bitcoin Core decided to come along (as opposed=
 to pursuing a minority fork) that they&#39;d have the time to develop and =
test the patch and roll it out to wide adoption. =C2=A0 If the goal of your=
 attempt is that any minority that disagreed will &quot;choose&quot; to fol=
low the majority branch, then you&#39;d be much more likely to achieve that=
 by giving them time to decide that&#39;s what they wanted and roll out the=
 software to do so.</span></div><div><span style=3D"font-size:12.8px"><br><=
/span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Sun, Feb 7, 2016 at 9:16 AM, Gavin A=
ndresen via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D"">On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span>On Saturday, February 06, 2016 5:25:2=
1 PM Tom Zander via bitcoin-dev wrote:<br>
&gt; On Saturday, February 06, 2016 06:09:21 PM Jorge Tim=C3=B3n via bitcoi=
n-dev<br>
wrote:<br>
&gt; &gt; None of the reasons you list say anything about the fact that &qu=
ot;being<br>
&gt; &gt; lost&quot; (kicked out of the network) is a problem for those nod=
e&#39;s users.<br>
&gt;<br>
&gt; That&#39;s because its not.<br>
&gt;<br>
&gt; If you have a node that is &quot;old&quot; your node will stop getting=
 new blocks.<br>
&gt; The node will essentially just say &quot;x-hours behind&quot; with &qu=
ot;x&quot; getting larger<br>
&gt; every hour. Funds don&#39;t get confirmed. etc.<br>
<br>
</span>Until someone decides to attack you. Then you&#39;ll get 6, 10, mayb=
e more blocks<br>
confirming a large 10000 BTC payment. If you&#39;re just a normal end user =
(or<br>
perhaps an automated system), you&#39;ll figure that payment is good and<br=
>
irreversibly hand over the title to the house.<br></blockquote><div><br></d=
iv></span><div>There will be approximately zero percentage of hash power le=
ft on the weaker branch of the fork, based on past soft-fork adoption by mi=
ners (they upgrade VERY quickly from 75% to over 95%).</div><div><br></div>=
<div>So it will take a week to get 6 confirmations.</div><div><br></div><di=
v>If you are a full node, you are warned that your software is obsolete and=
 you must upgrade.</div><div><br></div><div>If you are a lightweight node, =
it SHOULD tell you something is wrong, but even if it doesn&#39;t, given th=
at people running lightweight nodes run them so they don&#39;t have to be c=
onnected to the network 24/7, it is very likely during that week you discon=
nect and reconnect to the network several times. And every time you do that=
 you increase your chances that you will connect to full nodes on the major=
ity branch of the chain, where you will be told about the double-spend.</di=
v><div><br></div><div>All of that is assuming that there is no OTHER mitiga=
tion done. DNS seeds should avoid reporting nodes that look like they are i=
n the middle of initial block download (that are at a block height signific=
antly behind the rest of the network), for example.</div></div><span class=
=3D"HOEnZb"><font color=3D"#888888"><div><br></div>-- <br><div><div dir=3D"=
ltr"><div><div dir=3D"ltr"><div>--<br>Gavin Andresen<br></div><div><br></di=
v></div></div></div></div>
</font></span></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
<br></blockquote></div><br></div>

--047d7b10cea577061d052b2f6c27--