diff options
| author | gabe appleton <gappleto97@gmail.com> | 2015-05-12 12:56:37 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-12 16:56:44 +0000 |
| commit | f04d0315908af08dee3b90291abdc5bd9d6c45fb (patch) | |
| tree | 5a3be1aeea1e8c1b40ee61a32f4ea63b259dffb9 | |
| parent | e4d5ce0ea1f202dbb2d3328a54622e4b599a0e96 (diff) | |
| download | pi-bitcoindev-f04d0315908af08dee3b90291abdc5bd9d6c45fb.tar.gz pi-bitcoindev-f04d0315908af08dee3b90291abdc5bd9d6c45fb.zip | |
Re: [Bitcoin-development] Proposed additional options for pruned nodes
| -rw-r--r-- | 6a/9c7b772f312a81010e906c146137878864b045 | 206 |
1 files changed, 206 insertions, 0 deletions
diff --git a/6a/9c7b772f312a81010e906c146137878864b045 b/6a/9c7b772f312a81010e906c146137878864b045 new file mode 100644 index 000000000..92b4e54f5 --- /dev/null +++ b/6a/9c7b772f312a81010e906c146137878864b045 @@ -0,0 +1,206 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gappleto97@gmail.com>) id 1YsDU4-0002ip-Di + for bitcoin-development@lists.sourceforge.net; + Tue, 12 May 2015 16:56:44 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.220.52 as permitted sender) + client-ip=209.85.220.52; envelope-from=gappleto97@gmail.com; + helo=mail-pa0-f52.google.com; +Received: from mail-pa0-f52.google.com ([209.85.220.52]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YsDU3-0000Co-7K + for bitcoin-development@lists.sourceforge.net; + Tue, 12 May 2015 16:56:44 +0000 +Received: by pabtp1 with SMTP id tp1so19061359pab.2 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 12 May 2015 09:56:37 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.66.249.198 with SMTP id yw6mr29354867pac.149.1431449797567; + Tue, 12 May 2015 09:56:37 -0700 (PDT) +Received: by 10.66.85.165 with HTTP; Tue, 12 May 2015 09:56:37 -0700 (PDT) +In-Reply-To: <CAJHLa0O5OxaX5g3u=dnCY6Lz_gK3QZgQEPNcWNVRD4JziwAmvg@mail.gmail.com> +References: <CANJO25J1WRHtfQLVXUB2s_sjj39pTPWmixAcXNJ3t-5os8RPmQ@mail.gmail.com> + <CANJO25JTtfmfsOQYOzJeksJn3CoKE3W8iLGsRko-_xd4XhB3ZA@mail.gmail.com> + <CAJHLa0O5OxaX5g3u=dnCY6Lz_gK3QZgQEPNcWNVRD4JziwAmvg@mail.gmail.com> +Date: Tue, 12 May 2015 12:56:37 -0400 +Message-ID: <CANJO25KWmUhpFbSycYBZmowrBtLZPwXDs-eoXRgcAoaMuE0Rzg@mail.gmail.com> +From: gabe appleton <gappleto97@gmail.com> +To: Jeff Garzik <jgarzik@bitpay.com> +Content-Type: multipart/alternative; boundary=089e0160c916b2ac560515e5604d +X-Spam-Score: -0.3 (/) +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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (gappleto97[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in + digit (gappleto97[at]gmail.com) + 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: 1YsDU3-0000Co-7K +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:56:44 -0000 + +--089e0160c916b2ac560515e5604d +Content-Type: text/plain; charset=UTF-8 + +Yes, but that just increases the incentive for partially-full nodes. It +would add to the assumed-small number of full nodes. + +Or am I misunderstanding? + +On Tue, May 12, 2015 at 12:05 PM, Jeff Garzik <jgarzik@bitpay.com> wrote: + +> 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/ +> + +--089e0160c916b2ac560515e5604d +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Yes, but that just increases the incentive for partially-f= +ull nodes. It would add to the assumed-small number of full nodes.<div><br>= +</div><div>Or am I misunderstanding?</div></div><div class=3D"gmail_extra">= +<br><div class=3D"gmail_quote">On Tue, May 12, 2015 at 12:05 PM, Jeff Garzi= +k <span dir=3D"ltr"><<a href=3D"mailto:jgarzik@bitpay.com" target=3D"_bl= +ank">jgarzik@bitpay.com</a>></span> wrote:<br><blockquote class=3D"gmail= +_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= +1ex"><div dir=3D"ltr">A general assumption is that you will have a few arch= +ive nodes with the full blockchain, and a majority of nodes are pruned, abl= +e to serve only the tail of the chains.<div><br></div></div><div class=3D"g= +mail_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Tue, M= +ay 12, 2015 at 8:26 AM, gabe appleton <span dir=3D"ltr"><<a href=3D"mail= +to:gappleto97@gmail.com" target=3D"_blank">gappleto97@gmail.com</a>></sp= +an> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin= +:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D= +"h5"><p dir=3D"ltr">Hi,</p> +<p dir=3D"ltr">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.</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'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't be Sybil resistant, but how= + would this be less so than a fully pruned node? </p> +<br></div></div>-----------------------------------------------------------= +-------------------<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" target=3D"_bla= +nk">Bitcoin-development@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><span class=3D"HOEnZb"><font color=3D"#888888"><br><= +br clear=3D"all"><div><br></div>-- <br><div>Jeff Garzik<br>Bitcoin core dev= +eloper and open source evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a hr= +ef=3D"https://bitpay.com/" target=3D"_blank">https://bitpay.com/</a></div> +</font></span></div> +</blockquote></div><br></div> + +--089e0160c916b2ac560515e5604d-- + + |