MIME-Version: 1.0
In-Reply-To: <CA+voGJT7tfHS-6bEqjhnOTz=jVidg7AAEXSis_GvqVvBZdRy0w@mail.gmail.com>
References: <CAFVRnypbQQ-vsSLqv48cYaqTCty4R1DmFRqfAvxe4mAqyQNXxQ@mail.gmail.com>
	<CAJN5wHW=p+q+DT9R=uheLxOjKBX=xcB+fOZR2KACgJO9SdXypw@mail.gmail.com>
	<CA+voGJT7tfHS-6bEqjhnOTz=jVidg7AAEXSis_GvqVvBZdRy0w@mail.gmail.com>
From: Leandro Coutinho <lescoutinhovr@gmail.com>
Date: Fri, 21 Apr 2017 12:58:43 -0300
Message-ID: <CAN6UTaw0N8g+Kk0AYENa9WnXP7tH6H7rikkZ+9N4zesdodrJXw@mail.gmail.com>
To: David Kaufman <david@gigawatt.com>
Content-Type: multipart/alternative; boundary=94eb2c06e8ae02deef054daf5575
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes
Precedence: list

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

Maybe it already exists ...

#9484 <https://github.com/bitcoin/bitcoin/pull/9484> 812714f
<https://github.com/bitcoin/bitcoin/commit/812714f> Introduce assumevalid
setting to skip validation presumed valid scripts (gmaxwell)
https://github.com/bitcoin/bitcoin/pull/9484

..., but ...
It would be very interesting if a new node could decide to be a pruned node:
  - it would need to trust one or more peers for the initial blockchain
download, because the blocks downloaded would not be validated
  - it would decide a time from when to get the blocks, like a week before
  - once a day a routine would run that would prune blocks older than the
chosen time

"

*The unspent transaction outputs (which is the only essential piece ofdata
necessary for validation) are already kept in a separate database,so
technically removing old blocks is perfectly possible.*" Pieter Wuille
https://bitcoin.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-at-the-moment


On Fri, Apr 21, 2017 at 10:35 AM, David Kaufman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Danny,
>
> On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe wrote:
> >
> > 1TB HDD is now available for under $40 USD.  How is the 100GB storage
> > requirement preventing anyone from setting up full nodes?
>
> Yeah, but that's because most people (well, using myself as the
> "target market" anyway) are upgrading to SSD's for the faster boot and
> response times.  Modern consumer OS's run incredibly slow on
> non-ssd drives!  And since the vast majority of consumer laptops sold
> today fall into the $400 to $700 range, a 200 - 500gb SSD is about the
> most storage upgrade people can afford.
>
> And so I think David's premise, that having to devote only 30GB to
> running a full node instead of 100, would remove a major obstacle that
> prevents many more people running full bitcoin nodes.
>
> My only suggestion is, does it scale?  I mean, if the bitcoin network
> volume grows exponentially and in 2 years the blockchain is 500GB, can
> the "small node" be adjusted down from one fifth of the blockchain to
> just one-tenth, or one twentieth?  Can different smalInesses
> interoperate? Can I choose to store a small node with 20 - 30% of the
> blockchain, while others chose to share just 5% or 10% of it? Can I run
> "less small" node today that's 50GB?
>
> Can the default install be a "small node" that requires about 30GB of
> storage (if that is indeed the sweet spot for enticing many more users to
> bringing nodes online), but allow the user at install time, to choose *how*
> small? To, say, drag a slider anywhere up and down the range from
> 10GB to 100GB?
>
> If not, then it will have to be revisited constantly as the blockchain
> grows, and disk storage prices drop.  I suspect the blockchain will
> grow in size, at some point in the not too distant future, much faster
> than storage prices drop, so making small, smaller and smallest nodes
> that can be configured to store more or less of it will be necessary
> to motivate most users to run nodes at all.  But when that happens,
> there is likely to be exponentially *more* people using bitcoin, too!
> So an exponentially growing number of users running (smaller and
> smaller) nodes would take up the slack.
>
> Then, the blockchain would begin to look a lot more like a bittorrent,
> right? ;-) but -- happily -- one that you never need to download fully.
>
> -dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Maybe it already exists ...<br><br><a href=3D"https:/=
/github.com/bitcoin/bitcoin/pull/9484">#9484</a> <a href=3D"https://github.=
com/bitcoin/bitcoin/commit/812714f"><code class=3D"gmail-highlighter-rouge"=
>812714f</code></a> Introduce assumevalid setting to skip validation presum=
ed valid scripts (gmaxwell)<br><a href=3D"https://github.com/bitcoin/bitcoi=
n/pull/9484">https://github.com/bitcoin/bitcoin/pull/9484</a><br><br>..., b=
ut ...<br>It would be very interesting if a new node could decide to be a p=
runed node:<br>=C2=A0 - it would need to trust one or more peers for the in=
itial blockchain download, because the blocks downloaded would not be valid=
ated</div><div>=C2=A0 - it would decide a time from when to get the blocks,=
 like a week before</div><div>=C2=A0 - once a day a routine would run that =
would prune blocks older than the chosen time<br><br>&quot;<i>The unspent t=
ransaction outputs=20
(which is the only essential piece of<br>data necessary for validation) are
 already kept in a separate database,<br>so technically removing old blocks
 is perfectly possible.</i>&quot; Pieter Wuille<br><a href=3D"https://bitco=
in.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-=
at-the-moment">https://bitcoin.stackexchange.com/questions/11170/why-is-pru=
ning-not-considered-already-at-the-moment</a><br><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Apr 21, 2017 at 10:=
35 AM, David Kaufman via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">Hi Danny,<br>
<br>
On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe wrote:<br>
&gt;<br>
&gt; 1TB HDD is now available for under $40 USD.=C2=A0 How is the 100GB sto=
rage<br>
&gt; requirement preventing anyone from setting up full nodes?<br>
<br>
Yeah, but that&#39;s because most people (well, using myself as the<br>
&quot;target market&quot; anyway) are upgrading to SSD&#39;s for the faster=
 boot and<br>
response times.=C2=A0 Modern consumer OS&#39;s run incredibly slow on<br>
non-ssd drives!=C2=A0 And since the vast majority of consumer laptops sold<=
br>
today fall into the $400 to $700 range, a 200 - 500gb SSD is about the<br>
most storage upgrade people can afford.<br>
<br>
And so I think David&#39;s premise, that having to devote only 30GB to<br>
running a full node instead of 100, would remove a major obstacle that<br>
prevents many more people running full bitcoin nodes.<br>
<br>
My only suggestion is, does it scale?=C2=A0 I mean, if the bitcoin network<=
br>
volume grows exponentially and in 2 years the blockchain is 500GB, can<br>
the &quot;small node&quot; be adjusted down from one fifth of the blockchai=
n to<br>
just one-tenth, or one twentieth?=C2=A0 Can different smalInesses<br>
interoperate? Can I choose to store a small node with 20 - 30% of the<br>
blockchain, while others chose to share just 5% or 10% of it? Can I run<br>
&quot;less small&quot; node today that&#39;s 50GB?<br>
<br>
Can the default install be a &quot;small node&quot; that requires about 30G=
B of<br>
storage (if that is indeed the sweet spot for enticing many more users to<b=
r>
bringing nodes online), but allow the user at install time, to choose *how*=
<br>
small? To, say, drag a slider anywhere up and down the range from<br>
10GB to 100GB?<br>
<br>
If not, then it will have to be revisited constantly as the blockchain<br>
grows, and disk storage prices drop.=C2=A0 I suspect the blockchain will<br=
>
grow in size, at some point in the not too distant future, much faster<br>
than storage prices drop, so making small, smaller and smallest nodes<br>
that can be configured to store more or less of it will be necessary<br>
to motivate most users to run nodes at all.=C2=A0 But when that happens,<br=
>
there is likely to be exponentially *more* people using bitcoin, too!<br>
So an exponentially growing number of users running (smaller and<br>
smaller) nodes would take up the slack.<br>
<br>
Then, the blockchain would begin to look a lot more like a bittorrent,<br>
right? ;-) but -- happily -- one that you never need to download fully.<br>
<br>
-dave<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>
</blockquote></div><br></div>

--94eb2c06e8ae02deef054daf5575--