Jeff Garzik [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-12 📝 Original message:A general assumption is ...
📅 Original date posted:2015-05-12
📝 Original message: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 at 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 at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150512/0ee91628/attachment.html>;
📝 Original message: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 at 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 at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150512/0ee91628/attachment.html>;