public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ricardo Filipe <ricardojdfilipe@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Date: Thu, 16 May 2013 12:26:49 +0100	[thread overview]
Message-ID: <CALC81CNMTWhAQ8VSxToGcSPeJmfFJrANrdXONseTq1=WKm4=7w@mail.gmail.com> (raw)

We would only end up with few copies of the historic data if users
could choose what parts of the blockchain to store. Simply store
chunks randomly, according to users available space, and give priority
to the "N most recent" chunks to have more replicas in the network.

You don't need bittorrent specifically for a DHT, if publicity is a
problem. There are many DHT proposals and implementations, and i bet
one of them should be more suitable to the bitcoin network than
bittorrent's.

>On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn <mike@...> wrote:
>> I'd imagined that nodes would be able to pick their own ranges to keep
>> rather than have fixed chosen intervals. "Everything or two weeks" is rather
>
>X most recent is special for two reasons:  It meshes well with actual demand,
>and the data is required for reorganization.
>
>So whatever we do for historic data, N most recent should be treated specially.
>
>But I also agree that its important that <everything> be splittable into ranges
>because otherwise when having to choose between serving historic data
>and— say— 40 GB storage, a great many are going to choose not to serve
>historic data... and so nodes may be willing to contribute 4-39 GB storage
>to the network there will be no good way for them to do so and we may end
>up with too few copies of the historic data available.
>
>As can be seen in the graph, once you get past the most recent 4000
>blocks the probability is fairly uniform... so "N most recent" is not a
>good way to divide load for the older blocks. But simple ranges— perhaps
>quantized to groups of 100 or 1000 blocks or something— would work fine.
>
>This doesn't have to come in the first cut, however— and it needs new
>addr messages in any case.



             reply	other threads:[~2013-05-16 11:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16 11:26 Ricardo Filipe [this message]
2013-05-16 15:47 ` [Bitcoin-development] Service bits for pruned nodes Jeff Garzik
2013-05-16 16:23   ` Ricardo Filipe
  -- strict thread matches above, loose matches on Subject: below --
2013-04-28 15:51 Pieter Wuille
2013-04-28 16:29 ` Mike Hearn
2013-04-28 16:44   ` Pieter Wuille
2013-04-28 16:57     ` Mike Hearn
2013-05-03 12:30       ` Pieter Wuille
2013-05-03 14:06         ` Mike Hearn
2013-05-03 14:18           ` Peter Todd
2013-05-03 15:02             ` Mike Hearn
2013-05-03 15:11               ` Peter Todd
2013-05-04 18:07                 ` John Dillon
2013-05-04 18:55                   ` Jeff Garzik
2013-05-05 13:12                     ` John Dillon
2013-05-06  8:19                       ` Mike Hearn
2013-05-06 13:13                         ` Pieter Wuille
2013-04-28 19:50   ` Gregory Maxwell
2013-04-29  2:57     ` John Dillon
2013-04-29  3:36       ` Gregory Maxwell
2013-04-29  3:42         ` Robert Backhaus
2013-04-29  3:48         ` John Dillon
2013-04-29  3:55           ` Peter Todd
2013-04-29  6:10             ` Jay F
     [not found]               ` <CAFBxzACw=G7UgG853zQrM-Z1-B4VqSQR5YUJQ5n1=wnv7EyWsw@mail.gmail.com>
2013-04-30 16:14                 ` [Bitcoin-development] Fwd: " Rebroad (sourceforge)
2013-04-30 18:04                   ` Jeff Garzik
2013-04-30 20:06                     ` [Bitcoin-development] " Brenton Camac
2013-05-01 13:46 ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALC81CNMTWhAQ8VSxToGcSPeJmfFJrANrdXONseTq1=WKm4=7w@mail.gmail.com' \
    --to=ricardojdfilipe@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox