Jeff Garzik [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-01 📝 Original message:On Sun, Apr 28, 2013 at ...

📅 Original date posted:2013-05-01
📝 Original message:On Sun, Apr 28, 2013 at 11:51 AM, Pieter Wuille <pieter.wuille at 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 at exmulti.com