📅 Original date posted:2014-04-10
📝 Original message:On Thu, Apr 10, 2014 at 4:57 AM, Wladimir <laanwj at gmail.com> wrote:
> Just wondering: Would there be a use for a [static] node that, say, always
> serves only the first 100000 blocks? Or, even, a static range like block
> 100000 - 200000?
The last time we discussed this sipa collected data based on how often
blocks were feteched as a function of their depth and there was a huge
increase for recent blocks that didn't really level out until 2000
blocks or so— presumably its not uncommon for nodes to be offline for
a week or two at a time.
But sure I could see a fixed range as also being a useful contribution
though I'm struggling to figure out what set of constraints would
leave a node without following the consensus? Obviously it has
bandwidth if you're expecting to contribute much in serving those
historic blocks... and verifying is reasonably cpu cheap with fast
ecdsa code. Maybe it has a lot of read only storage?
I think it should be possible to express and use such a thing in the
protocol even if I'm currently unsure as to why you wouldn't do 100000
- 200000 _plus_ the most recent 144 that you were already keeping
around for reorgs.
In terms of peer selection, if the blocks you need aren't covered by
the nodes you're currently connected to I think you'd prefer to seek
node nodes which have the least rare-ness in the ranges they offer.
E.g. if you're looking for a block 50 from the tip, you're should
probably not prefer to fetch it from someone with blocks 100000-150000
if its one of only 100 nodes that has that range.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:18:29
in reply to nevent1q…ukhq
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:18:29Event JSON
{
"id": "8eb624b344039734de426d4eac017d028031e7da0c0210aae27fdd0af5742677",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151109,
"kind": 1,
"tags": [
[
"e",
"aae8a2dedee78eef571f285fef23331d89c84b104c87b098618414541001d13e",
"",
"root"
],
[
"e",
"649c04559980f0ef3f196dc260685da956f48ce9e7a03a9919000fb49ed211d1",
"",
"reply"
],
[
"p",
"30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722"
]
],
"content": "📅 Original date posted:2014-04-10\n📝 Original message:On Thu, Apr 10, 2014 at 4:57 AM, Wladimir \u003claanwj at gmail.com\u003e wrote:\n\u003e Just wondering: Would there be a use for a [static] node that, say, always\n\u003e serves only the first 100000 blocks? Or, even, a static range like block\n\u003e 100000 - 200000?\n\nThe last time we discussed this sipa collected data based on how often\nblocks were feteched as a function of their depth and there was a huge\nincrease for recent blocks that didn't really level out until 2000\nblocks or so— presumably its not uncommon for nodes to be offline for\na week or two at a time.\n\nBut sure I could see a fixed range as also being a useful contribution\nthough I'm struggling to figure out what set of constraints would\nleave a node without following the consensus? Obviously it has\nbandwidth if you're expecting to contribute much in serving those\nhistoric blocks... and verifying is reasonably cpu cheap with fast\necdsa code. Maybe it has a lot of read only storage?\n\nI think it should be possible to express and use such a thing in the\nprotocol even if I'm currently unsure as to why you wouldn't do 100000\n- 200000 _plus_ the most recent 144 that you were already keeping\naround for reorgs.\n\nIn terms of peer selection, if the blocks you need aren't covered by\nthe nodes you're currently connected to I think you'd prefer to seek\nnode nodes which have the least rare-ness in the ranges they offer.\nE.g. if you're looking for a block 50 from the tip, you're should\nprobably not prefer to fetch it from someone with blocks 100000-150000\nif its one of only 100 nodes that has that range.",
"sig": "4d586b71896ddee959f2317e3dbb6c1a27b8902b3d91a8db27914d107bb0cabdc6d6682e43a1db99e00f7706e59d3b4d8adc85711639f156b2f7621617f359db"
}