path: root/ed/1a346e670e5e758bdf3fdc300967e778f8980d

Return-Path: <david.vorick@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F2DDABAA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 20:28:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com
	[209.85.128.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1BF6B0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 20:28:37 +0000 (UTC)
Received: by mail-wr0-f170.google.com with SMTP id w43so31795735wrb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 13:28:37 -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=v6Uqb8Zr0yLTJ/nnD8F+FllL+XRhNUArPbJTVPd2jr0=;
	b=LwRp5lFYyWqEv48gZsHZfhPow8VdYBXoNUXp8hjUtbZRbVa21lSaxULL1gX4PlZha2
	uFLkWZTshzczQ7in2//ZUo4IRZoeVo4CLYnTnIn6C0PG36DZG8LLRO0RBTpdH9CYfC+w
	3BbKS/kRynnMLDDtGhWMTooCuGZtXZhMr/lEki652uv7IeEUXcezFZKrMt+g2HFYWK4Q
	myF0j1eQ74qSaI9BwQmtlB+ZOuHNoVhz0ZAyFSkRaz0mdisMTlL/UDipfKoQkBt34A94
	4KhDf/TKgrRzrhh/FEHohePSUbt8FHZKaQLDa3foJCrBaLMbgiPW1+fxL/jEjvegktbh
	MRYg==
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=v6Uqb8Zr0yLTJ/nnD8F+FllL+XRhNUArPbJTVPd2jr0=;
	b=EqO+RLSXovAxOWWcVhVdIy2Suysnxvzz8Y8OIcJMVBg8s5nwdlghyyIwkc55bYCsql
	n43E45Irybp2+CQdFh1sW6pojRX5ZRETJnSZhFUZ3vC//37OqPfQtZRZcccGF8vGmkyV
	/bJGql5LiFeqNkRRp4ID2r7D7FQOXKaDPGey8xXuQj6OcgRGhhPuF60b5kW0ypVDDFeN
	QVXWMUWQs1pLOBTJ5SFx8u9N7N/iewIqKzST/nLOWWqnCTLXxkSYE9J3ePxX1anwz73U
	o/7eZ9F//Q3cS27T9qmYzvU9l3opRx3xPnoBshjKD+rp2n4f9L51KVDmZC8l5nfXgLJc
	gsVQ==
X-Gm-Message-State: AFeK/H1oIPOJGQMCgCHmJslSsrVGpsbdVeNWigwPdwoJOoBh+opXjlCiyX5Ml/Wr2sOWyThGpZxkVVyex/gnOw==
X-Received: by 10.223.148.102 with SMTP id 93mr2017443wrq.144.1490819316053;
	Wed, 29 Mar 2017 13:28:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.55.9 with HTTP; Wed, 29 Mar 2017 13:28:35 -0700 (PDT)
In-Reply-To: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com>
References: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com>
From: David Vorick <david.vorick@gmail.com>
Date: Wed, 29 Mar 2017 16:28:35 -0400
Message-ID: <CAFVRnyq9Qgw88RZqenjQTDZHEWeuNCdh12Dq7wCGZdu9ZuEN9w@mail.gmail.com>
To: Daniele Pinna <daniele.pinna@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c0d2574c20008054be46beb
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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 20:28:39 -0000

--94eb2c0d2574c20008054be46beb
Content-Type: text/plain; charset=UTF-8

> > 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?

It's a political assessment. Full nodes are the ultimate arbiters of
consensus. When a contentious change is suggested, only the full nodes have
the power to either accept or reject this contentious change. If home users
are not running their own full nodes, then home users have to trust and
rely on other, more powerful nodes to represent them. Of course, the more
powerful nodes, simply by nature of having more power, are going to have
different opinions and objectives from the users. And it's impossible for
5000 nodes to properly represent the views of 5,000,000 users. Users
running full nodes is important to prevent political hijacking of the
Bitcoin protocol. Running a full node yourself is the only way to guarantee
(in the absence of trust - which Bitcoin is all about eliminating trust)
that changes you are opposed to are not introduced into the network.

> 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.

This statement is not true for home users, it is true for datacenter nodes.
For home users, 200 GB of bandwidth and 500 GB of bandwidth largely have
the exact same cost. I pay a fixed amount of money for my internet, and if
I use 500 GB the cost is identical to if I use 200 GB. So long as bandwidth
is kept under my home bandwidth cap, bandwidth for home nodes is _free_.

Similarly, disk space may only be $2/TB in bulk, but as a home user I have
a $1000 computer with 500 GB of total storage, 100 GB seems
(psychologically) to cost a lot closer to $200 than to $2. And if I go out
and buy an extra drive to support Bitcoin, it's going to cost about $50 no
matter what drive I pick, because that's just how much you have to spend to
get a drive. The fact that I get an extra 900 GB that I'm not using is
irrelevant - I spent $50 explicitly so I could run a bitcoin node.

The financials of home nodes follow a completely different math than the
costs you are citing by quoting datacenter prices.

> 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.

Many home machines only have 4GB of RAM. (I am acutely aware of this
because my own software consumes about 3.5GB of RAM, which means all of our
users stuck at 4 GB cannot use my software and Chrome at the same time).
0.14 uses more than 1 GB of RAM. This I think is not really a problem for
most people, but it becomes a problem if the amount of RAM required grows
enough that they can't have all of their programs open at the same time.
1GB I think is really the limit you'd want to have before you'd start
seeing users choose not to run nodes simply because they'd rather have 300
tabs open instead.

CPU usage I think is pretty minimal. Your node is pretty busy during IBD
which is annoying but tolerable. And during normal usage a user isn't even
going to notice. Same for electricity. They aren't going to notice at the
end of the month if their electricity bill is a dollar higher because of
Bitcoin.

> 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.

This is very much worth considering. If transaction fees are so high that
there is no use case at all for people unwilling to buy extra hardware for
Bitcoin (a dedicated node or whatever), then there is no longer a reason to
worry about these people as users. However, I think the fees would have to
get in the $50 range for that to start to be the case. When talking about
emergency funds - that is, $10k+ that you keep in case your government
defaults, hyperinflates, seizes citizen assets, etc. etc. (situations that
many Bitcoin users today have to legitimately worry about), then you are
going to be making a few transactions per year at most, and the cost of
fees on a home node may be $150 / yr, while the cost of dedicated hardware
might be $150/yr ($600 box amortized over 4 years). We are two orders of
magnitude away from this type of fee pressure, so I think it continues to
make sense to be considering the home nodes as the target that we want to
hit.

>  What about periodically committing the entire UTXO set to a special
checkpoint block which becomes the new de facto Genesis block?

This should be discussed in another thread but I don't think I'm alone in
saying that I think this could actually be done in a secure / safe /
valuable way if you did it correctly. It would reduce bandwidth pressure on
archive nodes, reduce disk pressure on full nodes, and imo make for a more
efficient network overall.

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

<div dir=3D"ltr">&gt; <span class=3D"gmail-im">&gt;=C2=A0<span style=3D"fon=
t-size:12.8px">When considering=20
what block size is acceptable, the impact of running bitcoin in the=20
background on affordable, non-dedicated home-hardware should be a top=20
consideration.</span><div style=3D"font-size:12.8px" dir=3D"auto" class=3D"=
gmail_extra"><br></div></span><div style=3D"font-size:12.8px" class=3D"gmai=
l_extra">&gt; Why
 is that a given?=C2=A0 Is there math that outlines what the risk levels ar=
e=20
for various configurations of node distributions, vulnerabilities, etc?=C2=
=A0
 How does one even evaluate the costs versus the benefits of node costs=20
versus transaction fees?</div><div style=3D"font-size:12.8px" dir=3D"auto" =
class=3D"gmail_extra"><br></div><div style=3D"font-size:12.8px" class=3D"gm=
ail_extra">It&#39;s a political assessment. Full nodes are the ultimate arb=
iters of consensus. When a contentious change is suggested, only the full n=
odes have the power to either accept or reject this contentious change. If =
home users are not running their own full nodes, then home users have to tr=
ust and rely on other, more powerful nodes to represent them. Of course, th=
e more powerful nodes, simply by nature of having more power, are going to =
have different opinions and objectives from the users. And it&#39;s impossi=
ble for 5000 nodes to properly represent the views of 5,000,000 users. User=
s running full nodes is important to prevent political hijacking of the Bit=
coin protocol. Running a full node yourself is the only way to guarantee (i=
n the absence of trust - which Bitcoin is all about eliminating trust) that=
 changes you are opposed to are not introduced into the network.<br><br>&gt=
; <span class=3D"gmail-im"></span>Disk space is not the largest cost, eithe=
r=20
today or in the future.=C2=A0 Without historical checkpointing in some=20
fashion, bandwidth costs are more than 2 orders of magnitude higher cost
 than every other cost for full listening nodes. <br><br></div><div style=
=3D"font-size:12.8px" class=3D"gmail_extra">This statement is not true for =
home users, it is true for datacenter nodes. For home users, 200 GB of band=
width and 500 GB of bandwidth largely have the exact same cost. I pay a fix=
ed amount of money for my internet, and if I use 500 GB the cost is identic=
al to if I use 200 GB. So long as bandwidth is kept under my home bandwidth=
 cap, bandwidth for home nodes is _free_.<br><br>Similarly, disk space may =
only be $2/TB in bulk, but as a home user I have a $1000 computer with 500 =
GB of total storage, 100 GB seems (psychologically) to cost a lot closer to=
 $200 than to $2. And if I go out and buy an extra drive to support Bitcoin=
, it&#39;s going to cost about $50 no matter what drive I pick, because tha=
t&#39;s just how much you have to spend to get a drive. The fact that I get=
 an extra 900 GB that I&#39;m not using is irrelevant - I spent $50 explici=
tly so I could run a bitcoin node.<br><br></div><div style=3D"font-size:12.=
8px" class=3D"gmail_extra">The financials of home nodes follow a completely=
 different math than the costs you are citing by quoting datacenter prices.=
<br><br>&gt; I don&#39;t know how to evaluate the impacts of RAM or CPU usa=
ge, or=20
consequently electricity usage for a node yet.=C2=A0 I&#39;m open to quanti=
fying=20
any of those if there&#39;s a method, but it seems absurd that ram could=20
even become a signficant factor given the abundance of cheap ram=20
nowadays with few programs needing it.<br><br></div><div style=3D"font-size=
:12.8px" class=3D"gmail_extra">Many home machines only have 4GB of RAM. (I =
am acutely aware of this because my own software consumes about 3.5GB of RA=
M, which means all of our users stuck at 4 GB cannot use my software and Ch=
rome at the same time). 0.14 uses more than 1 GB of RAM. This I think is no=
t really a problem for most people, but it becomes a problem if the amount =
of RAM required grows enough that they can&#39;t have all of their programs=
 open at the same time. 1GB I think is really the limit you&#39;d want to h=
ave before you&#39;d start seeing users choose not to run nodes simply beca=
use they&#39;d rather have 300 tabs open instead.<br><br></div><div style=
=3D"font-size:12.8px" class=3D"gmail_extra">CPU usage I think is pretty min=
imal. Your node is pretty busy during IBD which is annoying but tolerable. =
And during normal usage a user isn&#39;t even going to notice. Same for ele=
ctricity. They aren&#39;t going to notice at the end of the month if their =
electricity bill is a dollar higher because of Bitcoin.<br><br>&gt; <span s=
tyle=3D"font-size:12.8px">The consequence of your logic that holds=20
node operational costs down is that transaction fees for users go up,=20
adoption slows as various use cases become impractical, price growth=20
suffers, and alt coins that choose lower fees over node cost concerns=20
will exhibit competitive growth against Bitcoin&#39;s crypto-currency marke=
t
 share.=C2=A0 Even if you are right, that&#39;s hardly a tradeoff not worth=
=20
thoroughly investigating from every angle, the consequences could be=20
just as dire for Bitcoin <span tabindex=3D"0" class=3D"gmail-aBn"><span cla=
ss=3D"gmail-aQJ">in 10 years</span></span> as it would be if we made oursel=
ves vulnerable.<br><br></span></div><div style=3D"font-size:12.8px" class=
=3D"gmail_extra"><span style=3D"font-size:12.8px">This is very much worth c=
onsidering. If transaction fees are so high that there is no use case at al=
l for people unwilling to buy extra hardware for Bitcoin (a dedicated node =
or whatever), then there is no longer a reason to worry about these people =
as users. However, I think the fees would have to get in the $50 range for =
that to start to be the case. When talking about emergency funds - that is,=
 $10k+ that you keep in case your government defaults, hyperinflates, seize=
s citizen assets, etc. etc. (situations that many Bitcoin users today have =
to legitimately worry about), then you are going to be making a few transac=
tions per year at most, and the cost of fees on a home node may be $150 / y=
r, while the cost of dedicated hardware might be $150/yr ($600 box amortize=
d over 4 years). We are two orders of magnitude away from this type of fee =
pressure, so I think it continues to make sense to be considering the home =
nodes as the target that we want to hit.<br><br>&gt;=C2=A0 </span>What abou=
t periodically committing the entire UTXO set=20
to a special checkpoint block which becomes the new de facto Genesis=20
block? <br><div dir=3D"auto"><br></div></div><div style=3D"font-size:12.8px=
" class=3D"gmail_extra">This should be discussed in another thread but I do=
n&#39;t think I&#39;m alone in saying that I think this could actually be d=
one in a secure / safe / valuable way if you did it correctly. It would red=
uce bandwidth pressure on archive nodes, reduce disk pressure on full nodes=
, and imo make for a more efficient network overall.<br></div><div style=3D=
"font-size:12.8px" class=3D"gmail_extra"><br></div></div>

--94eb2c0d2574c20008054be46beb--