📅 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
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 14:56:17
in reply to nevent1q…747y
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 14:56:17Event JSON
{
"id": "2f04f73dd02f3e6b60c4f217f3411927458d2c621eebb66495b5e7c86fd9de99",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686149777,
"kind": 1,
"tags": [
[
"e",
"29ec2e2b5b2f4dc51eb87cabd53d5f02656fee9d1f600fd1d211680c53c784ad",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2013-05-01\n📝 Original message:On Sun, Apr 28, 2013 at 11:51 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e Hello all,\n\u003e\n\u003e I think it is time to move forward with pruning nodes, i.e. nodes that fully\n\u003e validate and relay blocks and transactions, but which do not keep (all)\n\u003e historic blocks around, and thus cannot be queried for these.\n\u003e\n\u003e The biggest roadblock is making sure new and old nodes that start up are\n\u003e able to find nodes to synchronize from. To help them find peers, I would\n\u003e like to propose adding two extra service bits to the P2P protocol:\n\u003e * NODE_VALIDATE: relay and validate blocks and transactions, but is only\n\u003e guaranteed to answer getdata requests for (recently) relayed blocks and\n\u003e transactions, and mempool transactions.\n\u003e * NODE_BLOCKS_2016: can be queried for the last 2016 blocks, but without\n\u003e guarantee for relaying/validating new blocks and transactions.\n\u003e * NODE_NETWORK (which existed before) will imply NODE_VALIDATE and guarantee\n\u003e availability of all historic blocks.\n\nIn general, I support this, as anybody on IRC knows.\n\nThough it does seem to open the question about snapshotting.\n\nPersonally, it seems important to enable running a fully validating\nnode, that may bootstrap from a UTXO snapshot + all blocks since that\nsnapshot.\n\nNODE_BLOCKS_2016, in particular, is too short. For users, I've seen\nplenty of use cases in the field where you start a network sync after\na 2-week period.\n\nSet a regular interval for creating a UTXO snapshot, say 3 months\n(6*2016 blocks), and serve all blocks after that snapshot. For older\nnodes, they would contact an archive node or torrent for \u003e3 month\nblocks, and then download normally \u003c= 3 month blocks (if the archive\nnode didn't serve up to present day).\n\nWhere are we on nailing down a stable, hash-able UTXO serialization?\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "c92e54e3c643c0ddb9d605e96dfad1b17610872a68f277b1d036a9e1ae34f52dfcda4f463e01f8146da2a672dfbede4df8a0011dedf7075d20cc2b7492e93ea0"
}