gabe appleton [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-12 📝 Original message:I suppose this begs two ...
📅 Original date posted:2015-05-12
📝 Original message:I suppose this begs two questions:
1) why not have a partial archive store the most recent X% of the
blockchain by default?
2) why not include some sort of torrent in QT, to mitigate this risk? I
don't think this is necessarily a good idea, but I'd like to hear the
reasoning.
On May 12, 2015 4:11 PM, "Jeff Garzik" <jgarzik at bitpay.com> wrote:
> True. Part of the issue rests on the block sync horizon/cliff. There is
> a value X which is the average number of blocks the 90th percentile of
> nodes need in order to sync. It is sufficient for the [semi-]pruned nodes
> to keep X blocks, after which nodes must fall back to archive nodes for
> older data.
>
> There is simply far, far more demand for recent blocks, and the demand for
> old blocks very rapidly falls off.
>
> There was even a more radical suggestion years ago - refuse to sync if too
> old (>2 weeks?), and force the user to download ancient data via torrent.
>
>
>
> On Tue, May 12, 2015 at 1:02 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> On Tue, May 12, 2015 at 7:38 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>> > One general problem is that security is weakened when an attacker can
>> DoS a
>> > small part of the chain by DoS'ing a small number of nodes - yet the
>> impact
>> > is a network-wide DoS because nobody can complete a sync.
>>
>> It might be more interesting to think of that attack as a bandwidth
>> exhaustion DOS attack on the archive nodes... if you can't get a copy
>> without them, thats where you'll go.
>>
>> So the question arises: does the option make some nodes that would
>> have been archive not be? Probably some-- but would it do so much that
>> it would offset the gain of additional copies of the data when those
>> attacks are not going no. I suspect not.
>>
>> It's also useful to give people incremental ways to participate even
>> when they can't swollow the whole pill; or choose to provide the
>> resource thats cheap for them to provide. In particular, if there is
>> only two kinds of full nodes-- archive and pruned; then the archive
>> nodes take both a huge disk and bandwidth cost; where as if there are
>> fractional then archives take low(er) bandwidth unless the fractionals
>> get DOS attacked.
>>
>
>
>
> --
> 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/01931028/attachment.html>;
📝 Original message:I suppose this begs two questions:
1) why not have a partial archive store the most recent X% of the
blockchain by default?
2) why not include some sort of torrent in QT, to mitigate this risk? I
don't think this is necessarily a good idea, but I'd like to hear the
reasoning.
On May 12, 2015 4:11 PM, "Jeff Garzik" <jgarzik at bitpay.com> wrote:
> True. Part of the issue rests on the block sync horizon/cliff. There is
> a value X which is the average number of blocks the 90th percentile of
> nodes need in order to sync. It is sufficient for the [semi-]pruned nodes
> to keep X blocks, after which nodes must fall back to archive nodes for
> older data.
>
> There is simply far, far more demand for recent blocks, and the demand for
> old blocks very rapidly falls off.
>
> There was even a more radical suggestion years ago - refuse to sync if too
> old (>2 weeks?), and force the user to download ancient data via torrent.
>
>
>
> On Tue, May 12, 2015 at 1:02 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> On Tue, May 12, 2015 at 7:38 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>> > One general problem is that security is weakened when an attacker can
>> DoS a
>> > small part of the chain by DoS'ing a small number of nodes - yet the
>> impact
>> > is a network-wide DoS because nobody can complete a sync.
>>
>> It might be more interesting to think of that attack as a bandwidth
>> exhaustion DOS attack on the archive nodes... if you can't get a copy
>> without them, thats where you'll go.
>>
>> So the question arises: does the option make some nodes that would
>> have been archive not be? Probably some-- but would it do so much that
>> it would offset the gain of additional copies of the data when those
>> attacks are not going no. I suspect not.
>>
>> It's also useful to give people incremental ways to participate even
>> when they can't swollow the whole pill; or choose to provide the
>> resource thats cheap for them to provide. In particular, if there is
>> only two kinds of full nodes-- archive and pruned; then the archive
>> nodes take both a huge disk and bandwidth cost; where as if there are
>> fractional then archives take low(er) bandwidth unless the fractionals
>> get DOS attacked.
>>
>
>
>
> --
> 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/01931028/attachment.html>;