📅 Original date posted:2014-04-10
📝 Original message:On Thu, Apr 10, 2014 at 2:10 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> 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?
>
The use case is that you could burn the node implementation + block data +
a live operating system on a read-only medium. This could be set in stone
for a long time.
There would be no consensus code to keep up to date with protocol
developments, because it doesn't take active part in it.
I don't think it would be terribly useful right now, but it could be useful
when nodes that host all history become rare. It'd allow distributing
'pieces of history' in a self-contained form.
> 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.
>
Yes, it would be nice to at least be able to express it, if it doesn't make
the protocol too finicky.
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.
>
That makes sense.
In general, if you want a block 50 from the tip, it would be best to
request it from a node that only serves the last N (N>~50) blocks, and not
a history node that could use the same bandwidth to serve earlier, rarer
blocks to others.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/dc261288/attachment.html>;
Wladimir [ARCHIVE] /
npub1xq…ymc2p
2023-06-07 15:18:29
in reply to nevent1q…usv0
Author Public Key
npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2pSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:18:29Event JSON
{
"id": "f6fb29229c234939d16c8c2b3af45c000c891433d228166462aa09459af636e0",
"pubkey": "30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722",
"created_at": 1686151109,
"kind": 1,
"tags": [
[
"e",
"aae8a2dedee78eef571f285fef23331d89c84b104c87b098618414541001d13e",
"",
"root"
],
[
"e",
"8eb624b344039734de426d4eac017d028031e7da0c0210aae27fdd0af5742677",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-04-10\n📝 Original message:On Thu, Apr 10, 2014 at 2:10 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e But sure I could see a fixed range as also being a useful contribution\n\u003e though I'm struggling to figure out what set of constraints would\n\u003e leave a node without following the consensus? Obviously it has\n\u003e bandwidth if you're expecting to contribute much in serving those\n\u003e historic blocks... and verifying is reasonably cpu cheap with fast\n\u003e ecdsa code. Maybe it has a lot of read only storage?\n\u003e\n\nThe use case is that you could burn the node implementation + block data +\na live operating system on a read-only medium. This could be set in stone\nfor a long time.\n\nThere would be no consensus code to keep up to date with protocol\ndevelopments, because it doesn't take active part in it.\n\nI don't think it would be terribly useful right now, but it could be useful\nwhen nodes that host all history become rare. It'd allow distributing\n'pieces of history' in a self-contained form.\n\n\n\u003e I think it should be possible to express and use such a thing in the\n\u003e protocol even if I'm currently unsure as to why you wouldn't do 100000\n\u003e - 200000 _plus_ the most recent 144 that you were already keeping\n\u003e around for reorgs.\n\u003e\n\nYes, it would be nice to at least be able to express it, if it doesn't make\nthe protocol too finicky.\n\nIn terms of peer selection, if the blocks you need aren't covered by\n\u003e the nodes you're currently connected to I think you'd prefer to seek\n\u003e node nodes which have the least rare-ness in the ranges they offer.\n\u003e E.g. if you're looking for a block 50 from the tip, you're should\n\u003e probably not prefer to fetch it from someone with blocks 100000-150000\n\u003e if its one of only 100 nodes that has that range.\n\u003e\n\nThat makes sense.\n\nIn general, if you want a block 50 from the tip, it would be best to\nrequest it from a node that only serves the last N (N\u003e~50) blocks, and not\na history node that could use the same bandwidth to serve earlier, rarer\nblocks to others.\n\nWladimir\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/dc261288/attachment.html\u003e",
"sig": "ad816503743a6ce9368f9e8b059d85d309fd872049cecab10e15084ef894c7b3a221177508b5f8027b156d12a2f66c98a79365011df291f2193297c2711a72ea"
}