path: root/6d/c1a4537653219473ec4763e5ac0f46ee74c531

Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A519BDE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 19:46:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com
	[209.85.213.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7E1D416C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 19:46:52 +0000 (UTC)
Received: by mail-vk0-f54.google.com with SMTP id r69so30611497vke.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 12:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=ej+w9btLYGtiobURcGoBjWCAFyiwQmsKLysoXeXTgQM=;
	b=I0FQepj6eLCN6zYGAHNlWpWh6eohztAaHOdW6OqL6c65ceMsV8xc/4py0cCEWafjhZ
	pFAhisS0/NkEzdfbOsk86lMdRWmsGGfIc4c/Aiq6sm2Qmb7FfGf4u0j88XZobsk8bbI6
	YvlLxC9BdqhK6/KW67WIla7MV6I7bzYXdASgHgUn/D99jY9kxGmBLcDjvGkJiI3U8+3s
	lV63ivojDBH0hruFIfHBC7M2s410Pa7CVWbUpNQR73C9lGBLQbwLS3ztIa5bCIsxqFRy
	LlNfnTvLz2yZi+ZC+wq8OjjW/K2DYfPdVNU+B6fiqq9VhSf13Zq0no3UcGahJxVRWoX3
	xbyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=ej+w9btLYGtiobURcGoBjWCAFyiwQmsKLysoXeXTgQM=;
	b=GzpgN4VtpM2S4zslSXPEzGKsxrYuW3R2klJG3+UoVKqcDcmpvN9BUzZa33H0GQNF9D
	RzJTzlWTfgO4KXO6stwnpytXLoSgL5afKG9x38UpGflarKNBfZZNoHn0v7Yn5HA8+pb5
	j/za7JLly/jw/YQNqBIqz8WxUsI9eNv6aua/HgVvGDCPAsETZhbRjP8oBqhlpJ4zkOfL
	Ws//St/XR/ruRsmvOAOtZWtYGqGsJGeQxJnK28hPE8Y9a/tH6Y03Bb+faLfDTrb1+Lwe
	kJgqa7QpBJ2E+LVFbUzvsikOrGYlQ20EZiGw46uRWB9XLBIN3EQD9PU/7ApZLrCmTdZD
	BGLg==
X-Gm-Message-State: AFeK/H1Tp2lA6KPk3vcbcw/5dD4wArokH54avftBfUsmNC45dEam4/kRKr8Jfeu+1FndE1mLijsGQ+4RvUyt0g==
X-Received: by 10.31.84.66 with SMTP id i63mr1063083vkb.157.1490816811435;
	Wed, 29 Mar 2017 12:46:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Wed, 29 Mar 2017 12:46:50 -0700 (PDT)
In-Reply-To: <CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com>
	<CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Wed, 29 Mar 2017 12:46:50 -0700
Message-ID: <CAD1TkXtnSApYgp9FU55Esn2qgT=QyqS61kVzSO1Ae=g8J18Vcw@mail.gmail.com>
To: David Vorick <david.vorick@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114e523e788fd3054be3d6db
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 29 Mar 2017 19:58:59 +0000
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 29 Mar 2017 19:46:53 -0000

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

> When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.

Why is that a given?  Is there math that outlines what the risk levels are
for various configurations of node distributions, vulnerabilities, etc?
How does one even evaluate the costs versus the benefits of node costs
versus transaction fees?

> Disk space I believe is the most significant problem today, with RAM
being the second most significant problem, and finally bandwidth
consumption as the third most important consideration. I believe that v0.14
is already too expensive on all three fronts, and that block size increases
shouldn't be considered at all until the requirements are reduced (or until
consumer hardware is better, but I believe we are talking 3-7 years of
waiting if we pick that option).

Disk space is not the largest cost, either today or in the future.  Without
historical checkpointing in some fashion, bandwidth costs are more than 2
orders of magnitude higher cost than every other cost for full listening
nodes.  With historical syncing discounted(i.e. pruned or nonlistening
nodes) bandwidth costs are still higher than hard drive costs.


Today: Full listening node, 133 peers, measured 1.5 TB/mo of bandwidth
consumption over two multi-day intervals.  1,500 GB/month @ ec2 low-tier
prices =3D $135/month, 110 GB storage =3D $4.95.  Similar arguments extend =
to
consumer hardware - Comcast broadband is ~$80/mo depending on region and
comes with 1.0 TB cap in most regions, so $120/mo or even $80/mo would be
in the same ballpark.  A consumer-grade 2GB hard drive is $70 and will last
for at least 2 years, so $2.93/month if the hard drive was totally
dedicated to Bitcoin and $0.16/month if we only count the percentage that
Bitcoin uses.

For a non-full listening node, ~25 peers I measured around 70 GB/month of
usage over several days, which is $6.3 per month EC2 or $5.6 proportional
Comcast cost.  If someone isn't supporting syncing, there's not much point
in them not turning on pruning.  Even if they didn't, a desktop in the $500
range typically comes with 1 or 2 TB of storage by default, and without
segwit or a blocksize cap increase, 3 years from now the full history will
only take up the 33% of the smaller, three year old, budget-range PC hard
drive.  Even then if we assume the hard drive price declines of the last 4
years hold steady(14%, very low compared to historical gains), 330gb of
data only works out to a proportional monthly cost of $6.20 - still
slightly smaller than his bandwidth costs, and almost entirely removable by
turning on pruning since he isn't paying to help others sync.

I don't know how to evaluate the impacts of RAM or CPU usage, or
consequently electricity usage for a node yet.  I'm open to quantifying any
of those if there's a method, but it seems absurd that ram could even
become a signficant factor given the abundance of cheap ram nowadays with
few programs needing it.  CPU usage and thus electricity costs might become
a factor, I just don't know how to quantify it at various block scales.
Currently cpu usage isn't taxing any hardware that I run a node on in any
way I have been able to notice, not including the syncing process.

> I am also solidly unconvinced that increasing the blocksize today is a
good move, even as little as SegWit does.

The consequence of your logic that holds node operational costs down is
that transaction fees for users go up, adoption slows as various use cases
become impractical, price growth suffers, and alt coins that choose lower
fees over node cost concerns will exhibit competitive growth against
Bitcoin's crypto-currency market share.  Even if you are right, that's
hardly a tradeoff not worth thoroughly investigating from every angle, the
consequences could be just as dire for Bitcoin in 10 years as it would be
if we made ourselves vulnerable.

And even if an altcoin can't take Bitcoin's dominance by lower fees, we
will not end up with millions of home users running nodes, ever.  If they
did so, that would be orders of magnitude fee market competition, and
continuing increases in price, while hardware costs decline.  If
transaction fees go up from space limitations, and they go up even further
in real-world terms from price increases, while node costs decline,
eventually it will cost more to send a transaction than it does to run a
node for a full month.  No home users would send transactions because the
fee costs would be higher than anything they might use Bitcoin for, and so
they would not run a node for something they don't use - Why would they?
The cost of letting the ratio between node costs and transaction costs go
in the extreme favor of node costs would be worse - Lower Bitcoin
usability, adoption, and price, without any meaningful increase in security=
.

How do we evaluate the math on node distributions versus various attack
vectors?



On Wed, Mar 29, 2017 at 8:57 AM, David Vorick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Mar 29, 2017 9:50 AM, "Martin L=C3=ADzner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Im tending to believe, that HF is necessary evil now.
>
>
> I will firmly disagree. We know how to do a soft-fork blocksize increase.
> If it is decided that a block size increase is justified, we can do it wi=
th
> extension blocks in a way that achieves full backwards compatibility for
> all nodes.
>
> Barring a significant security motivation, there is no need to hardfork.
>
> I am also solidly unconvinced that increasing the blocksize today is a
> good move, even as little as SegWit does. It's too expensive for a home
> user to run a full node, and user-run full nodes are what provide the
> strongest defence against political manuveuring.
>
> When considering what block size is acceptable, the impact of running
> bitcoin in the background on affordable, non-dedicated home-hardware shou=
ld
> be a top consideration.
>
> Disk space I believe is the most significant problem today, with RAM bein=
g
> the second most significant problem, and finally bandwidth consumption as
> the third most important consideration. I believe that v0.14 is already t=
oo
> expensive on all three fronts, and that block size increases shouldn't be
> considered at all until the requirements are reduced (or until consumer
> hardware is better, but I believe we are talking 3-7 years of waiting if =
we
> pick that option).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">When considerin=
g what block size is acceptable, the impact of running bitcoin in the backg=
round on affordable, non-dedicated home-hardware should be a top considerat=
ion.</span><div class=3D"gmail_extra" dir=3D"auto" style=3D"font-size:12.8p=
x"><br></div><div class=3D"gmail_extra" style=3D"font-size:12.8px">Why is t=
hat a given?=C2=A0 Is there math that outlines what the risk levels are for=
 various configurations of node distributions, vulnerabilities, etc?=C2=A0 =
How does one even evaluate the costs versus the benefits of node costs vers=
us transaction fees?</div><div class=3D"gmail_extra" dir=3D"auto" style=3D"=
font-size:12.8px"><br></div><div class=3D"gmail_extra" dir=3D"auto" style=
=3D"font-size:12.8px">&gt; Disk space I believe is the most significant pro=
blem today, with RAM being the second most significant problem, and finally=
 bandwidth consumption as the third most important consideration. I believe=
 that v0.14 is already too expensive on all three fronts, and that block si=
ze increases shouldn&#39;t be considered at all until the requirements are =
reduced (or until consumer hardware is better, but I believe we are talking=
 3-7 years of waiting if we pick that option).<br><br>Disk space is not the=
 largest cost, either today or in the future.=C2=A0 Without historical chec=
kpointing in some fashion, bandwidth costs are more than 2 orders of magnit=
ude higher cost than every other cost for full listening nodes.=C2=A0 With =
historical syncing discounted(i.e. pruned or nonlistening nodes) bandwidth =
costs are still higher than hard drive costs.<br><br><br>Today: Full listen=
ing node, 133 peers, measured 1.5 TB/mo of bandwidth consumption over two m=
ulti-day intervals. =C2=A01,500 GB/month @ ec2 low-tier prices =3D $135/mon=
th, 110 GB storage =3D $4.95.=C2=A0 Similar arguments extend to consumer ha=
rdware - Comcast broadband is ~$80/mo depending on region and comes with 1.=
0 TB cap in most regions, so $120/mo or even $80/mo would be in the same ba=
llpark.=C2=A0 A consumer-grade 2GB hard drive is $70 and will last for at l=
east 2 years, so $2.93/month if the hard drive was totally dedicated to Bit=
coin and $0.16/month if we only count the percentage that Bitcoin uses.<br>=
<br>For a non-full listening node, ~25 peers I measured around 70 GB/month =
of usage over several days, which is $6.3 per month EC2 or $5.6 proportiona=
l Comcast cost.=C2=A0 If someone isn&#39;t supporting syncing, there&#39;s =
not much point in them not turning on pruning.=C2=A0 Even if they didn&#39;=
t, a desktop in the $500 range typically comes with 1 or 2 TB of storage by=
 default, and without segwit or a blocksize cap increase, 3 years from now =
the full history will only take up the 33% of the smaller, three year old, =
budget-range PC hard drive.=C2=A0 Even then if we assume the hard drive pri=
ce declines of the last 4 years hold steady(14%, very low compared to histo=
rical gains), 330gb of data only works out to a proportional monthly cost o=
f $6.20 - still slightly smaller than his bandwidth costs, and almost entir=
ely removable by turning on pruning since he isn&#39;t paying to help other=
s sync.<br><br>I don&#39;t know how to evaluate the impacts of RAM or CPU u=
sage, or consequently electricity usage for a node yet.=C2=A0 I&#39;m open =
to quantifying any of those if there&#39;s a method, but it seems absurd th=
at ram could even become a signficant factor given the abundance of cheap r=
am nowadays with few programs needing it.=C2=A0 CPU usage and thus electric=
ity costs might become a factor, I just don&#39;t know how to quantify it a=
t various block scales.=C2=A0 Currently cpu usage isn&#39;t taxing any hard=
ware that I run a node on in any way I have been able to notice, not includ=
ing the syncing process.<br><br>&gt;=C2=A0<span style=3D"font-size:12.8px">=
I am also solidly unconvinced that increasing the blocksize today is a good=
 move, even as little as SegWit does.</span><span style=3D"font-size:12.8px=
"><br><br>The consequence of your logic that holds node operational costs d=
own is that transaction fees for users go up, adoption slows as various use=
 cases become impractical, price growth suffers, and alt coins that choose =
lower fees over node cost concerns will exhibit competitive growth against =
Bitcoin&#39;s crypto-currency market share.=C2=A0 Even if you are right, th=
at&#39;s hardly a tradeoff not worth thoroughly investigating from every an=
gle, the consequences could be just as dire for Bitcoin in 10 years as it w=
ould be if we made ourselves vulnerable.<br><br>And even if an altcoin can&=
#39;t take Bitcoin&#39;s dominance by lower fees, we will not end up with m=
illions of home users running nodes, ever.=C2=A0 If they did so, that would=
 be orders of magnitude fee market competition, and continuing increases in=
 price, while hardware costs decline.=C2=A0 If transaction fees go up from =
space limitations, and they go up even further in real-world terms from pri=
ce increases, while node costs decline, eventually it will cost more to sen=
d a transaction than it does to run a node for a full month.=C2=A0 No home =
users would send transactions because the fee costs would be higher than an=
ything they might use Bitcoin for, and so they would not run a node for som=
ething they don&#39;t use - Why would they?=C2=A0 The cost of letting the r=
atio between node costs and transaction costs go in the extreme favor of no=
de costs would be worse - Lower Bitcoin usability, adoption, and price, wit=
hout any meaningful increase in security.<br><br>How do we evaluate the mat=
h on node distributions versus various attack vectors?<br><br><br></span></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
 Mar 29, 2017 at 8:57 AM, David Vorick via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto"><span class=3D""><div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Mar 29, 2017 9:50 AM, &quot;=
Martin L=C3=ADzner via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfo=
undation.org</a>&gt; wrote:<blockquote class=3D"m_-5625292351202753279quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>Im tending to believe, that HF is necessary evil now.=
=C2=A0</div></div></blockquote></div><br></div></div></span><div class=3D"g=
mail_extra" dir=3D"auto">I will firmly disagree. We know how to do a soft-f=
ork blocksize increase. If it is decided that a block size increase is just=
ified, we can do it with extension blocks in a way that achieves full backw=
ards compatibility for all nodes.</div><div class=3D"gmail_extra" dir=3D"au=
to"><br></div><div class=3D"gmail_extra" dir=3D"auto">Barring a significant=
 security motivation, there is no need to hardfork.</div><div class=3D"gmai=
l_extra" dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto">I a=
m also solidly unconvinced that increasing the blocksize today is a good mo=
ve, even as little as SegWit does. It&#39;s too expensive for a home user t=
o run a full node, and user-run full nodes are what provide the strongest d=
efence against political manuveuring.</div><div class=3D"gmail_extra" dir=
=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto">When considerin=
g what block size is acceptable, the impact of running bitcoin in the backg=
round on affordable, non-dedicated home-hardware should be a top considerat=
ion.</div><div class=3D"gmail_extra" dir=3D"auto"><br></div><div class=3D"g=
mail_extra" dir=3D"auto">Disk space I believe is the most significant probl=
em today, with RAM being the second most significant problem, and finally b=
andwidth consumption as the third most important consideration. I believe t=
hat v0.14 is already too expensive on all three fronts, and that block size=
 increases shouldn&#39;t be considered at all until the requirements are re=
duced (or until consumer hardware is better, but I believe we are talking 3=
-7 years of waiting if we pick that option).</div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a114e523e788fd3054be3d6db--