path: root/27/d6704af2b9a4bd63bf90e0c0d903fa31665ba6

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jgarzik@bitpay.com>) id 1YsChA-0007gw-J0
	for bitcoin-development@lists.sourceforge.net;
	Tue, 12 May 2015 16:06:12 +0000
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; 
Received: from mail-oi0-f54.google.com ([209.85.218.54])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YsCh8-00020m-RJ
	for bitcoin-development@lists.sourceforge.net;
	Tue, 12 May 2015 16:06:12 +0000
Received: by oign205 with SMTP id n205so9768208oig.2
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 12 May 2015 09:06:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=K7S40lXH4aT/MM8NHaxzGD2AYFY++5fuH1Ma1jG1/TM=;
	b=gAwz9MjkqvuW1WDF7gpL/V4LjfKdbxF11Y8lgKmicakm14u4JPeBBG/w+88szwoB3x
	ahYVImiSPOfHCr5f/SB0Be0I4270f8bLlj+baoe2XbUbNQFV6qYSxZ0o0QwfzIzNMjIl
	C299Q7lTi+W9o2nzITY+uNPAUdQXnnSR0HlVqOK0eTArKJ+pCxOQHLy3I6qmRUZ78IK6
	8IEXFpzCvk7ByQCasz3p9VY8gEgG9QS5SR7uN+asaKDEMlwM3Rf+M+wpr9Nk8XsxoCzg
	0ANmPBXMm3U4W7XLi5DYTNwiHSi2PMKkrhAqXG81UIuvxdLOzDDxSqrDeujSuZEWqMk1
	docQ==
X-Gm-Message-State: ALoCoQn9hJDbAH8gINDPK1fJEzxiotigWgGtBJIVdrp2u3nB1GCHa0JgB+UbiDIlRnl5sIQMltqg
X-Received: by 10.60.42.161 with SMTP id p1mr12731182oel.7.1431446764941; Tue,
	12 May 2015 09:06:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.108.149 with HTTP; Tue, 12 May 2015 09:05:44 -0700 (PDT)
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
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YsCh8-00020m-RJ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed additional options for pruned
	nodes
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 16:06:12 -0000

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