public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed additional options for pruned nodes
Date: Wed, 13 May 2015 10:34:03 +0100	[thread overview]
Message-ID: <CAE-z3OWiurTt=QqjeL+KN-7AdKKgW2tJc_Yu-eMzoM-GUZ=fAg@mail.gmail.com> (raw)
In-Reply-To: <5552DEFA.4080508@domob.eu>

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

On Wed, May 13, 2015 at 6:19 AM, Daniel Kraft <d@domob.eu> wrote:

> 2) Divide the range of all blocks into intervals with exponentially
> growing size.  I. e., something like this:
>
> 1, 1, 2, 2, 4, 4, 8, 8, 16, 16, ...
>

Interesting.  This can be combined with the system I suggested.

A node broadcasts 3 pieces of information

Seed (16 bits): This is the seed
M_bits_lsb (1 bit):  Used to indicate M during a transition
N (7 bits):  This is the count of the last range held (or partially held)

M = 1 << M_bits

M should be set to the lowest power of 2 greater than double the block
chain height

That gives M = 1 million at the moment.  During changing M, some nodes will
be using the higher M and others will use the lower M.

The M_bits_lsb field allows those to be distinguished.

As the block height approaches 512k, nodes can begin to upgrade.  For a
period around block 512k, some nodes could use M = 1 million and others
could use M = 2 million.

Assuming M is around 3 times higher than the block height, then the odds of
a start being less than the block height is around 35%.  If they runs by
25% each step, then that is approx a double for each hit.

Size(n) = ((4 + (n & 0x3)) << (n >> 2)) * 2.5MB

This gives an exponential increase, but groups of 4 are linearly
interpolated.


*Size(0) = 10 MB*
Size(1) = 12.5MB
Size(2) = 15 MB
Size(3) = 17.5MB
Size(4) = 20MB

*Size(5) = 25MB*
Size(6) = 30MB
Size(7) = 35MB

*Size(8) = 40MB*

Start(n) = Hash(seed + n) mod M

A node should store as much of its last start as possible.  Assuming start
0, 5, and 8 were "hits" but the node had a max size of 60MB.  It can store
0 and 5 and have 25MB left.  That isn't enough to store all of run 8, but
it should store 25MB of the blocks in run 8 anyway.

Size(255) = pow(2, 31) * 17.5MB = 35,840 TB

Decreasing N only causes previously accepted runs to be invalidated.

When a node approaches a transition point for N, it would select a block
height within 25,000 of the transition point.  Once it reaches that block,
it will begin downloading the new runs that it needs.  When updating, it
can set N to zero.  This spreads out the upgrade (over around a year), with
only a small number of nodes upgrading at any time.

New nodes should use the higher M, if near a transition point (say within
100,000).

[-- Attachment #2: Type: text/html, Size: 3186 bytes --]

      reply	other threads:[~2015-05-13  9:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CANJO25J1WRHtfQLVXUB2s_sjj39pTPWmixAcXNJ3t-5os8RPmQ@mail.gmail.com>
2015-05-12 15:26 ` [Bitcoin-development] Proposed additional options for pruned nodes gabe appleton
2015-05-12 16:05   ` Jeff Garzik
2015-05-12 16:56     ` gabe appleton
2015-05-12 17:16     ` Peter Todd
2015-05-12 18:23       ` Tier Nolan
2015-05-12 19:03         ` Gregory Maxwell
2015-05-12 19:24           ` gabe appleton
2015-05-12 19:38             ` Jeff Garzik
2015-05-12 19:43               ` gabe appleton
2015-05-12 21:30                 ` [Bitcoin-development] [Bulk] " gb
2015-05-12 20:02               ` [Bitcoin-development] " Gregory Maxwell
2015-05-12 20:10                 ` Jeff Garzik
2015-05-12 20:41                   ` gabe appleton
2015-05-12 20:47                   ` Gregory Maxwell
     [not found]               ` <CAFVoEQTdmCSRAy3u26q5oHdfvFEytZDBfQb_fs_qttK15fiRmg@mail.gmail.com>
     [not found]                 ` <CAJHLa0OxxxiVd3JOp8SDvbF8dHj6KHdUNGb9L_GvTe93z3Z8mg@mail.gmail.com>
     [not found]                   ` <CAJHLa0MYSpVBD4VE65LVbADb2daOvE=N83G8F_zDSHy3AQ5DAQ@mail.gmail.com>
2015-05-12 21:17                     ` [Bitcoin-development] Fwd: " Adam Weiss
2015-05-12 22:00           ` [Bitcoin-development] " Tier Nolan
2015-05-12 22:09             ` gabe appleton
2015-05-13  5:19           ` Daniel Kraft
2015-05-13  9:34             ` Tier Nolan [this message]

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='CAE-z3OWiurTt=QqjeL+KN-7AdKKgW2tJc_Yu-eMzoM-GUZ=fAg@mail.gmail.com' \
    --to=tier.nolan@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