MIME-Version: 1.0
In-Reply-To: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
References: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
Date: Wed, 1 May 2013 09:46:08 -0400
Message-ID: <CA+8xBpcN0Oz8yyAPRbs-Nfrgcnq8T-ANdF5aro54KkTTs9ZfNg@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Precedence: list

On Sun, Apr 28, 2013 at 11:51 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> Hello all,
>
> I think it is time to move forward with pruning nodes, i.e. nodes that fully
> validate and relay blocks and transactions, but which do not keep (all)
> historic blocks around, and thus cannot be queried for these.
>
> The biggest roadblock is making sure new and old nodes that start up are
> able to find nodes to synchronize from. To help them find peers, I would
> like to propose adding two extra service bits to the P2P protocol:
> * NODE_VALIDATE: relay and validate blocks and transactions, but is only
> guaranteed to answer getdata requests for (recently) relayed blocks and
> transactions, and mempool transactions.
> * NODE_BLOCKS_2016: can be queried for the last 2016 blocks, but without
> guarantee for relaying/validating new blocks and transactions.
> * NODE_NETWORK (which existed before) will imply NODE_VALIDATE and guarantee
> availability of all historic blocks.

In general, I support this, as anybody on IRC knows.

Though it does seem to open the question about snapshotting.

Personally, it seems important to enable running a fully validating
node, that may bootstrap from a UTXO snapshot + all blocks since that
snapshot.

NODE_BLOCKS_2016, in particular, is too short.  For users, I've seen
plenty of use cases in the field where you start a network sync after
a 2-week period.

Set a regular interval for creating a UTXO snapshot, say 3 months
(6*2016 blocks), and serve all blocks after that snapshot.  For older
nodes, they would contact an archive node or torrent for >3 month
blocks, and then download normally <= 3 month blocks (if the archive
node didn't serve up to present day).

Where are we on nailing down a stable, hash-able UTXO serialization?

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com