path: root/97/0d5ea3df48f8c8ffd43eec76d3e9ae286ef957

Return-Path: <steven.pine@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0AD58EA8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  7 Feb 2016 21:33:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com
	[209.85.214.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22434100
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  7 Feb 2016 21:33:14 +0000 (UTC)
Received: by mail-ob0-f175.google.com with SMTP id is5so130744291obc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 07 Feb 2016 13:33:14 -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
	:content-type; bh=OBHVB3lZQcRv39q6GAAiLdbtEHGjUnbQ94lRwGZx6ik=;
	b=yCwPI2cRIVcEUWylNEajdFhyVUnzKCvQ9enYZ8+PpfkPjKSO61wuSk+t0RUs/GeCDl
	yvJ+bqh2B0tfo1PujE5TEcc+OuRBvMKVBFK5PuKRXLeFudhGOPrsFzcSqVKn6UoWlRQ1
	DbkF28M9n8HKPVAC+Jd3VGjXjCYCabPySGz2pE8qVKonu15z/CtoNzHdA8MDg6SceAfw
	/Wobu4l0FfVZXE3G/OvXROt6giXCqWOIxvikGzJng8eHIQm2B9YST1RWUETZPxinmIy8
	CFSFYy1i5+PfO0zEtODToLkcITrN6Wh+sx7gShDZQ15WkOJIugiLmWg6ThbDRmPjo+6a
	/BQQ==
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:content-type;
	bh=OBHVB3lZQcRv39q6GAAiLdbtEHGjUnbQ94lRwGZx6ik=;
	b=Df+dVdCXeAz003J+Df670GRAqNU/sKG50tO+imhS4ja9fAP6vYtNeWNVKxy8t9+HS4
	BIQdVPnuOU5AOIHA3tbmHhduYRpAq3HJ8TbWO38wpjdvM0RlBrDa/3z9ByE5RQn7GnbL
	VwOwLn1SaCZBNJI9cGzmNOVq55bHqn2YiADVlM85o+7fwkWzA+8M7ohubpXa++zl+P+j
	YV2iWhoAAB1fmRSa2asyLnu2gff9MN/wiO7g5HCMwNVFfHD0ACgf2z8F1huuPg1mYjZV
	n/+vKBVraw28/MgmvgkyL0MUDTVka1DiOZYAr5nzbWRM/ItvBRFqp/Br2T25ujnCOoqt
	7xHg==
X-Gm-Message-State: AG10YOTz8WJuMh45RZ2NpwNHt7xmvKrpJkNwGgWrbripi2wVDF1/LO8zY2MNE0bgArDhv2t1g6oAEAHweIZBDQ==
MIME-Version: 1.0
X-Received: by 10.60.233.131 with SMTP id tw3mr22306590oec.35.1454880793355;
	Sun, 07 Feb 2016 13:33:13 -0800 (PST)
Received: by 10.182.246.33 with HTTP; Sun, 7 Feb 2016 13:33:13 -0800 (PST)
In-Reply-To: <201602072101.15142.luke@dashjr.org>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<201602062046.40193.luke@dashjr.org>
	<CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
	<201602072101.15142.luke@dashjr.org>
Date: Sun, 7 Feb 2016 16:33:13 -0500
Message-ID: <CAAjy6kDd_1wY=Zrwnp4FZ_b0C0C06ThTLSPZq06Yjh178DuOkA@mail.gmail.com>
From: Steven Pine <steven.pine@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c1a31ce0ec77052b34d485
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
X-Mailman-Approved-At: Sun, 07 Feb 2016 21:35:24 +0000
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 21:33:15 -0000

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

Is it me or did Gavin ignore Yifu's direct questions? In case you missed it
Gavin --

~
"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."

On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage (in 28 days ) on the network for a hard fork is good
enough?

There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.
~~

When Gavin writes "Responding to "28 days is not long enough" :

I keep seeing this claim made with no evidence to back it up.  As I said, I
surveyed several of the biggest infrastructure providers and the btcd lead
developer and they all agree "28 days is plenty of time."

For individuals... why would it take somebody longer than 28 days to either
download and restart their bitcoind, or to patch and then re-run (the patch
can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?"

~~

Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
propositional a priori logic, but empirical evidence that. As for why
people take longer, who knows, we simply know from passed experience that
it in fact does take longer.

It's extremely frustrating to read Gavin's comments, it's hard to believe
he is engaging in earnest discussion.

On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen 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:
> > > > If you have a node that is "old" your node will stop getting new
> > > > blocks. 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
> (they
> > upgrade VERY quickly from 75% to over 95%).
>
> I'm assuming there are literally ZERO miners left on the weaker branch.
> The attacker in this scenario simply rents hashing for a few days in
> advance
> to build his fake chain, then broadcasts the blocks to the unsuspecting
> merchant at ~10 block intervals so it looks like everything is working
> normal
> again. There are lots of mining rental services out there, and miners quite
> often do not care to avoid selling hashrate to the highest bidder
> regardless
> of what they're mining. 10 blocks worth costs a little more than 250 BTC -
> soon, that will be 125 BTC.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Steven Pine
(510) 517-7075

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

<div dir=3D"ltr"><div>Is it me or did Gavin ignore Yifu&#39;s direct questi=
ons? In case you missed it Gavin --</div><div><br></div><div>~</div><span s=
tyle=3D"font-size:12.8px">&quot;We can look at the adoption of the last maj=
or Bitcoin core release to guess how long it might take people to upgrade. =
0.11.0 was released on 12 July, 2015. Twenty=C2=A0</span><span class=3D"" t=
abindex=3D"0" style=3D"font-size:12.8px"><span class=3D"">eight days later<=
/span></span><span style=3D"font-size:12.8px">, about 38% of full nodes wer=
e running that release.=C2=A0</span><span class=3D"" tabindex=3D"0" style=
=3D"font-size:12.8px"><span class=3D"">Three months later</span></span><spa=
n style=3D"font-size:12.8px">, about 50% of the network was running that re=
lease, and=C2=A0</span><span class=3D"" tabindex=3D"0" style=3D"font-size:1=
2.8px"><span class=3D"">six months later</span></span><span style=3D"font-s=
ize:12.8px">=C2=A0about 66% of the network was running some flavor of 0.11.=
&quot;</span><div style=3D"font-size:12.8px"><br></div><div style=3D"font-s=
ize:12.8px">On what grounds do you think it is reasonable to assume that th=
is update will roll out 6x faster than previous data suggested, as oppose t=
o your own observation of 66% adoption=C2=A0<span class=3D"" tabindex=3D"0"=
><span class=3D"">in 6 month</span></span>. or do you believe 38% node upgr=
ade-coverage (<span class=3D"" tabindex=3D"0"><span class=3D"">in 28 days</=
span></span>=C2=A0) on the network for a hard fork is good enough?</div><di=
v style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">Ther=
e are no harm in choosing a longer grace period but picking one short as 28=
 days you risk on alienating the nodes who do not upgrade with the aggressi=
ve upgrade timeline you proposed.</div><div>~~</div><div><br></div><div>Whe=
n Gavin writes &quot;<span style=3D"font-size:12.8px">Responding to &quot;2=
8 days is not long enough&quot; :</span></div><div style=3D"font-size:12.8p=
x"><br></div><div style=3D"font-size:12.8px">I keep seeing this claim made =
with no evidence to back it up.=C2=A0 As I said, I surveyed several of the =
biggest infrastructure providers and the btcd lead developer and they all a=
gree &quot;28 days is plenty of time.&quot;</div><div style=3D"font-size:12=
.8px"><br></div><div style=3D"font-size:12.8px">For individuals... why woul=
d it take somebody longer than 28 days to either download and restart their=
 bitcoind, or to patch and then re-run (the patch can be a one-line change =
MAX_BLOCK_SIZE from 1000000 to 2000000)?&quot;</div><div style=3D"font-size=
:12.8px"><br></div><div style=3D"font-size:12.8px">~~</div><div style=3D"fo=
nt-size:12.8px"><br></div><div style=3D"font-size:12.8px">Isn&#39;t Yifu&#3=
9;s comment, evidence, the very best sort of evidence, it isn&#39;t proposi=
tional a priori logic, but empirical evidence that. As for why people take =
longer, who knows, we simply know from passed experience that it in fact do=
es take longer.</div><div style=3D"font-size:12.8px"><br></div><div style=
=3D"font-size:12.8px">It&#39;s extremely frustrating to read Gavin&#39;s co=
mments, it&#39;s hard to believe he is engaging in earnest discussion.</div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Fe=
b 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <span dir=3D"ltr">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><span class=3D"">On Sunday, February 07, 2016 2:16:02 PM Ga=
vin Andresen wrote:<br>
&gt; On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt; On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-=
dev<br>
wrote:<br>
</span><span class=3D"">&gt; &gt; &gt; If you have a node that is &quot;old=
&quot; your node will stop getting new<br>
&gt; &gt; &gt; blocks. The node will essentially just say &quot;x-hours beh=
ind&quot; with &quot;x&quot;<br>
&gt; &gt; &gt; getting larger every hour. Funds don&#39;t get confirmed. et=
c.<br>
&gt; &gt;<br>
&gt; &gt; Until someone decides to attack you. Then you&#39;ll get 6, 10, m=
aybe more<br>
&gt; &gt; blocks confirming a large 10000 BTC payment. If you&#39;re just a=
 normal end<br>
&gt; &gt; user (or perhaps an automated system), you&#39;ll figure that pay=
ment is good<br>
&gt; &gt; and irreversibly hand over the title to the house.<br>
&gt;<br>
&gt; There will be approximately zero percentage of hash power left on the<=
br>
&gt; weaker branch of the fork, based on past soft-fork adoption by miners =
(they<br>
&gt; upgrade VERY quickly from 75% to over 95%).<br>
<br>
</span>I&#39;m assuming there are literally ZERO miners left on the weaker =
branch.<br>
The attacker in this scenario simply rents hashing for a few days in advanc=
e<br>
to build his fake chain, then broadcasts the blocks to the unsuspecting<br>
merchant at ~10 block intervals so it looks like everything is working norm=
al<br>
again. There are lots of mining rental services out there, and miners quite=
<br>
often do not care to avoid selling hashrate to the highest bidder regardles=
s<br>
of what they&#39;re mining. 10 blocks worth costs a little more than 250 BT=
C -<br>
soon, that will be 125 BTC.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Luke<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>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr"><div>Steven Pine<div>(510) =
517-7075</div></div></div></div>
</div>

--001a11c1a31ce0ec77052b34d485--