gabe appleton [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-12 📝 Original message:Yes, but that just ...
📅 Original date posted:2015-05-12
📝 Original message: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 at 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 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/af7820e4/attachment.html>;
📝 Original message: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 at 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 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/af7820e4/attachment.html>;