<div dir="ltr">Yes, but that just increases the incentive for partially-full nodes. It would add to the assumed-small number of full nodes.<div><br></div><div>Or am I misunderstanding?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 12:05 PM, Jeff Garzik <span dir="ltr">&lt;<a href="mailto:jgarzik@bitpay.com" target="_blank">jgarzik@bitpay.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, May 12, 2015 at 8:26 AM, gabe appleton <span dir="ltr">&lt;<a href="mailto:gappleto97@gmail.com" target="_blank">gappleto97@gmail.com</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><p dir="ltr">Hi,</p>
<p dir="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="ltr">There could be a hybrid option in nodes. Selecting this would do the following:<br>
Flip the --no-wallet toggle<br>
Select a section of the blockchain to store fully (percentage based, possibly 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 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.</p>
<p dir="ltr">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&#39;m mistaken), and it would significantly reduce storage needs on a node.</p>
<p dir="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 over time, while keeping to the sections defined by the network. </p>
<p dir="ltr">What sort of side effects or network vulnerabilities would this 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></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="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target="_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>Jeff Garzik<br>Bitcoin core developer and open source evangelist<br>BitPay, Inc.      <a href="https://bitpay.com/" target="_blank">https://bitpay.com/</a></div>
</font></span></div>
</blockquote></div><br></div>