On Sun, Apr 28, 2013 at 11:51 AM, Pieter Wuille <pieter.wui...@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. jgar...@exmulti.com ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
