Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.218.54 as permitted sender)
	client-ip=209.85.218.54; envelope-from=jgarzik@bitpay.com;
	helo=mail-oi0-f54.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANJO25JTtfmfsOQYOzJeksJn3CoKE3W8iLGsRko-_xd4XhB3ZA@mail.gmail.com>
References: <CANJO25J1WRHtfQLVXUB2s_sjj39pTPWmixAcXNJ3t-5os8RPmQ@mail.gmail.com>
	<CANJO25JTtfmfsOQYOzJeksJn3CoKE3W8iLGsRko-_xd4XhB3ZA@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Tue, 12 May 2015 09:05:44 -0700
Message-ID: <CAJHLa0O5OxaX5g3u=dnCY6Lz_gK3QZgQEPNcWNVRD4JziwAmvg@mail.gmail.com>
To: gabe appleton <gappleto97@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c24d80f0897f0515e4ab0c
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed additional options for pruned
	nodes
Precedence: list

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

A general assumption is that you will have a few archive nodes with the
full blockchain, and a majority of nodes are pruned, able to serve only the
tail of the chains.


On Tue, May 12, 2015 at 8:26 AM, gabe appleton <gappleto97@gmail.com> wrote:

> Hi,
>
> There's been a lot of talk in the rest of the community about how the 20MB
> step would increase storage needs, and that switching to pruned nodes
> (partially) would reduce network security. I think I may have a solution.
>
> There could be a hybrid option in nodes. Selecting this would do the
> following:
> Flip the --no-wallet toggle
> Select a section of the blockchain to store fully (percentage based,
> possibly on hash % sections?)
> Begin pruning all sections not included in 2
> The idea is that you can implement it similar to how a Koorde is done, in
> that the network will decide which sections it retrieves. So if the user
> prompts it to store 50% of the blockchain, it would look at its peers, and
> at their peers (if secure), and choose the least-occurring options from
> them.
>
> This would allow them to continue validating all transactions, and still
> store a full copy, just distributed among many nodes. It should overall
> have little impact on security (unless I'm mistaken), and it would
> significantly reduce storage needs on a node.
>
> It would also allow for a retroactive --max-size flag, where it will prune
> until it is at the specified size, and continue to prune over time, while
> keeping to the sections defined by the network.
>
> What sort of side effects or network vulnerabilities would this introduce?
> I know some said it wouldn't be Sybil resistant, but how would this be less
> so than a fully pruned node?
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

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

<div dir=3D"ltr">A general assumption is that you will have a few archive n=
odes with the full blockchain, and a majority of nodes are pruned, able to =
serve only the tail of the chains.<div><br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Tue, May 12, 2015 at 8:26 AM, gabe=
 appleton <span dir=3D"ltr">&lt;<a href=3D"mailto:gappleto97@gmail.com" tar=
get=3D"_blank">gappleto97@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><p dir=3D"ltr">Hi,</p>
<p dir=3D"ltr">There&#39;s been a lot of talk in the rest of the community =
about how the 20MB step would increase storage needs, and that switching to=
 pruned nodes (partially) would reduce network security. I think I may have=
 a solution.</p>
<p dir=3D"ltr">There could be a hybrid option in nodes. Selecting this woul=
d do the following:<br>
Flip the --no-wallet toggle<br>
Select a section of the blockchain to store fully (percentage based, possib=
ly on hash % sections?)<br>
Begin pruning all sections not included in 2<br>
The idea is that you can implement it similar to how a Koorde is done, in t=
hat the network will decide which sections it retrieves. So if the user pro=
mpts it to store 50% of the blockchain, it would look at its peers, and at =
their peers (if secure), and choose the least-occurring options from them.<=
/p>
<p dir=3D"ltr">This would allow them to continue validating all transaction=
s, and still store a full copy, just distributed among many nodes. It shoul=
d overall have little impact on security (unless I&#39;m mistaken), and it =
would significantly reduce storage needs on a node.</p>
<p dir=3D"ltr">It would also allow for a retroactive --max-size flag, where=
 it will prune until it is at the specified size, and continue to prune ove=
r time, while keeping to the sections defined by the network. </p>
<p dir=3D"ltr">What sort of side effects or network vulnerabilities would t=
his introduce? I know some said it wouldn&#39;t be Sybil resistant, but how=
 would this be less so than a fully pruned node? </p>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature">Jeff Garzik<br>Bitcoin core developer and open sourc=
e evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.=
com/" target=3D"_blank">https://bitpay.com/</a></div>
</div>

--001a11c24d80f0897f0515e4ab0c--