path: root/a7/4c76a08940dc2847416b5845540d5f102a0956

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 35832B55
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 20:53:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com
	[209.85.213.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69A05124
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 20:53:42 +0000 (UTC)
Received: by mail-vk0-f48.google.com with SMTP id r69so32649051vke.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 13:53:42 -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=lFRzrbxntm3n7znRUlM07yn/IMsB2k0BWF9SRn3EqXs=;
	b=IPohUr/1GmTAojOB1DET8+P94XOlGaj651Qw96qVPdeOHkjx9SvQ1nVrvj0owcez7E
	n4glGeHeU3r2Zk5Na5qdG+GAPTJNqKz1NGroXzTK4C0NqzhN3JQg9e18etFgOe3GIiYW
	hiTm8tx+nFcn+diW5HEHkIFfGC9lKJXAhE8NXsomDpbFrIsjM0fzwifRnG5AbeGBC4Pd
	EShAeiDtnLW1NmiixfocxfaQeckmtCXYIt7PjCwkWA6g66qqD0EHl02ZE72I02ERLLv9
	fhet3rGlKDEY+QAEsC9b9CxA7RJjpyyzcu3mNdmi83Bd1IE5rSiZ365xA0yjgX1hAgU3
	6qJQ==
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=lFRzrbxntm3n7znRUlM07yn/IMsB2k0BWF9SRn3EqXs=;
	b=V151HpMrtKcI0mAd9wkh7ppBQ/yAzOxjGCWmItUYz+GJePzpJcuA2nCJKAmGckJ+dT
	VX2tjoNSMg99jZqDeloMU84cs3//CdTfBEF53xjD8Q9G3mJCj0J+HmPUPFjZlBkE8vpN
	xwN+hKfcgBcv3xTSmhQLumUv3vSNa/p2sKH7bu+fuT/zwr6t2qr3/VbBDHr3uzOmeZA6
	8p1I3mtrhRlut14pxysCWACRM63PDIPG+g0KAUdGq+c+jakS6Ut0LE+/RMxjHuReuhbn
	Rve/G3mAXTqc3F9/mdxzeWclgX/M3ohkferTb3sQNMd7tYJWguwxorBPEOvoW8aD6he9
	OSpQ==
X-Gm-Message-State: AFeK/H0PvhnueVzWrlbp5UE4bRFOjWus2S49qHMn31jnewrY+sdXaRjsXwCQBTTGY+5NFjaaht03H2xQ0Oo1TQ==
X-Received: by 10.31.114.79 with SMTP id n76mr1191352vkc.30.1490820821504;
	Wed, 29 Mar 2017 13:53:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Wed, 29 Mar 2017 13:53:40 -0700 (PDT)
In-Reply-To: <CAFVRnyrpfRUVNWjR19+ou7PxQuLbaoY8yta+BAAK3zbMrdsOhw@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>
	<f61153c3-9afb-5cee-2c6b-70d67208f015@gmail.com>
	<CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
	<CAFVRnyqxQhu0c-ACfzR5=Z=C1SbR70jrfCaCeEdfSJASSnzpqw@mail.gmail.com>
	<CAAy62_J+huc_d5r-gyYCMGh6AjfJH4YiEVov9eBmwbKbWTe0Sw@mail.gmail.com>
	<CAFVRnyrpfRUVNWjR19+ou7PxQuLbaoY8yta+BAAK3zbMrdsOhw@mail.gmail.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Wed, 29 Mar 2017 13:53:40 -0700
Message-ID: <CAD1TkXuqFVjC0gp5EKmv=guWboYfNw8AU_4DW9=w4GHU=zn5Mw@mail.gmail.com>
To: David Vorick <david.vorick@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c1497187d55d7054be4c507
X-Spam-Status: No, score=-1.2 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,
	RCVD_IN_SORBS_SPAM 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 21:52:22 +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 20:53:43 -0000

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

> Pruned nodes are not the default configuration, if it was the default
configuration then I think you would see far more users running a pruned
node.

Default configurations aren't a big enough deal to factor into the critical
discussion of node costs versus transaction fee cost.  Default
configurations can be changed, and if nodes are negatively affected by a
default configuration, there will be an abundance of information about how
to correct that effect by turning on pruning.  Bitcoin can't design with
the assumption that people can't google - If we wanted to cater to that
population group right now, we'd need 100x the blocksize at least.

> But that would also substantially increase the burden on archive nodes.

This is already a big problem from the measurements I've been looking at.
There are alternatives that need to be considered there as well.  If we
limit ourselves to not changing the syncing process for most users, the
blocksize limit debate changes drastically.  Hard drive costs, CPU costs,
propagation times... none of those things matter because the cost of sync
bandwidth is so incredibly high even now ($130ish per month, see other
email).  Even if we didn't increase the blocksize any more than segwit,
we're already seeing sync costs being shifted onto fewer nodes - I.e., Luke
Jr's scan finding ~50k nodes online but only 7k of those show up on sites
like bitnodes.21.co.  Segwit will shift it further until the few nodes
providing sync limit speeds and/or max out on connections, providing no
fully-sync'd nodes for a new node to connect to. Then wallet providers /
node software will offer a solution - A bundled utxo checkpoint that
removes the need to sync.  This slightly increases centralization, and
increases centralization more if core were to adopt the same approach.

The advantage would be tremendous for such a simple solution - Node costs
would drop by a full order of magnitude for full nodes even today, more
when archival nodes are more restricted, history is bigger, and segwit
blocksizes are in effect, and then blocksizes could be safely increased by
nearly the same order of magnitude, increasing the utility of bitcoin and
the number of people that can effectively use it.

Another, much more complicated option is for the node sync process to
function like a tor network.  A very small number of seed nodes could send
data on to only other nodes with the highest bandwidth available(and good
retention policy, i.e. not tightly pruning as they sync), who then spread
it out further and so on.  That's complicated though, because as far as I
know the syncing process today has no ability to exchange a selfish syncing
node for a high performing syncing node.  I'm not even sure - will a
syncing node opt to sync from a different node that, itself, isn't fully
sync'd but is farther ahead?

At any rate, syncing bandwidth usage is a critical problem for future
growth and is solvable.  The upsides of fixing it are huge, though.

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

>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83@gmail.com>
> wrote:
>
> What's stopping these users from running a pruned node?  Not every node
> needs to store a complete copy of the blockchain.
>
>
> Pruned nodes are not the default configuration, if it was the default
> configuration then I think you would see far more users running a pruned
> node.
>
> But that would also substantially increase the burden on archive nodes.
>
>
> Further discussion about disk space requirements should be taken to
> another thread.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-family:sans-serif;font-size:=
12.8px">Pruned nodes are not the default configuration, if it was the defau=
lt configuration then I think you would see far more users running a pruned=
 node.</span><div><div dir=3D"auto" style=3D"font-size:12.8px;font-family:s=
ans-serif"><br></div><div style=3D"font-size:12.8px;font-family:sans-serif"=
>Default configurations aren&#39;t a big enough deal to factor into the cri=
tical discussion of node costs versus transaction fee cost.=C2=A0 Default c=
onfigurations can be changed, and if nodes are negatively affected by a def=
ault configuration, there will be an abundance of information about how to =
correct that effect by turning on pruning.=C2=A0 Bitcoin can&#39;t design w=
ith the assumption that people can&#39;t google - If we wanted to cater to =
that population group right now, we&#39;d need 100x the blocksize at least.=
</div><div dir=3D"auto" style=3D"font-size:12.8px;font-family:sans-serif"><=
br></div><div dir=3D"auto" style=3D"font-size:12.8px;font-family:sans-serif=
">&gt; But that would also substantially increase the burden on archive nod=
es.</div></div><div><br>This is already a big problem from the measurements=
 I&#39;ve been looking at.=C2=A0 There are alternatives that need to be con=
sidered there as well.=C2=A0 If we limit ourselves to not changing the sync=
ing process for most users, the blocksize limit debate changes drastically.=
=C2=A0 Hard drive costs, CPU costs, propagation times... none of those thin=
gs matter because the cost of sync bandwidth is so incredibly high even now=
 ($130ish per month, see other email).=C2=A0 Even if we didn&#39;t increase=
 the blocksize any more than segwit, we&#39;re already seeing sync costs be=
ing shifted onto fewer nodes - I.e., Luke Jr&#39;s scan finding ~50k nodes =
online but only 7k of those show up on sites like <a href=3D"http://bitnode=
s.21.co">bitnodes.21.co</a>.=C2=A0 Segwit will shift it further until the f=
ew nodes providing sync limit speeds and/or max out on connections, providi=
ng no fully-sync&#39;d nodes for a new node to connect to. Then wallet prov=
iders / node software will offer a solution - A bundled utxo checkpoint tha=
t removes the need to sync.=C2=A0 This slightly increases centralization, a=
nd increases centralization more if core were to adopt the same approach.</=
div><div><br></div><div>The advantage would be tremendous for such a simple=
 solution - Node costs would drop by a full order of magnitude for full nod=
es even today, more when archival nodes are more restricted, history is big=
ger, and segwit blocksizes are in effect, and then blocksizes could be safe=
ly increased by nearly the same order of magnitude, increasing the utility =
of bitcoin and the number of people that can effectively use it.<br><br></d=
iv><div>Another, much more complicated option is for the node sync process =
to function like a tor network.=C2=A0 A very small number of seed nodes cou=
ld send data on to only other nodes with the highest bandwidth available(an=
d good retention policy, i.e. not tightly pruning as they sync), who then s=
pread it out further and so on.=C2=A0 That&#39;s complicated though, becaus=
e as far as I know the syncing process today has no ability to exchange a s=
elfish syncing node for a high performing syncing node.=C2=A0 I&#39;m not e=
ven sure - will a syncing node opt to sync from a different node that, itse=
lf, isn&#39;t fully sync&#39;d but is farther ahead?</div><div><br></div><d=
iv>At any rate, syncing bandwidth usage is a critical problem for future gr=
owth and is solvable.=C2=A0 The upsides of fixing it are huge, though.</div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Ma=
r 29, 2017 at 9:25 AM, David Vorick via bitcoin-dev <span dir=3D"ltr">&lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"auto"><span class=3D""><div><div dir=3D"auto"=
><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mar 29,=
 2017 12:20 PM, &quot;Andrew Johnson&quot; &lt;<a href=3D"mailto:andrew.joh=
nson83@gmail.com" target=3D"_blank">andrew.johnson83@gmail.com</a>&gt; wrot=
e:<br type=3D"attribution"><blockquote class=3D"m_3762129008447833992quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv>What&#39;s stopping these users from running a pruned node?=C2=A0 Not ev=
ery node needs to store a complete copy of the blockchain.=C2=A0</div></blo=
ckquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"m_3=
762129008447833992quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div></div></blockquote></div></div></div></span><div=
 dir=3D"auto"><span style=3D"font-family:sans-serif">Pruned nodes are not t=
he default configuration, if it was the default configuration then I think =
you would see far more users running a pruned node.</span><div dir=3D"auto"=
 style=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=3D"font=
-family:sans-serif">But that would also substantially increase the burden o=
n archive nodes.</div><br></div><div dir=3D"auto"><br><span style=3D"font-f=
amily:sans-serif">Further discussion about disk space requirements should b=
e taken to another thread.</span><br></div><div dir=3D"auto"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"m_376212900844=
7833992quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div><br></div></blockquote></div></div></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>

--94eb2c1497187d55d7054be4c507--