đź“… Original date posted:2013-05-16
đź“ť Original message:We would only end up with few copies of the historic data if users
could choose what parts of the blockchain to store. Simply store
chunks randomly, according to users available space, and give priority
to the "N most recent" chunks to have more replicas in the network.
You don't need bittorrent specifically for a DHT, if publicity is a
problem. There are many DHT proposals and implementations, and i bet
one of them should be more suitable to the bitcoin network than
bittorrent's.
>On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn <mike at ...> wrote:
>> I'd imagined that nodes would be able to pick their own ranges to keep
>> rather than have fixed chosen intervals. "Everything or two weeks" is rather
>
>X most recent is special for two reasons: It meshes well with actual demand,
>and the data is required for reorganization.
>
>So whatever we do for historic data, N most recent should be treated specially.
>
>But I also agree that its important that <everything> be splittable into ranges
>because otherwise when having to choose between serving historic data
>and— say— 40 GB storage, a great many are going to choose not to serve
>historic data... and so nodes may be willing to contribute 4-39 GB storage
>to the network there will be no good way for them to do so and we may end
>up with too few copies of the historic data available.
>
>As can be seen in the graph, once you get past the most recent 4000
>blocks the probability is fairly uniform... so "N most recent" is not a
>good way to divide load for the older blocks. But simple ranges— perhaps
>quantized to groups of 100 or 1000 blocks or something— would work fine.
>
>This doesn't have to come in the first cut, however— and it needs new
>addr messages in any case.
Ricardo Filipe [ARCHIVE] /
npub14f…hksaj
2023-06-07 15:01:11
in reply to nevent1q…ak0f
Author Public Key
npub14fwd2yh320mh4ge46ute8ukdyx2kjxy2ak4a05prjwrtzlmh9rvq8hksajPublished at
2023-06-07 15:01:11Event JSON
{
"id": "e42cbedcf8845f6ad771a77692eacd8476bae62440ab2f13e204556eb511320c",
"pubkey": "aa5cd512f153f77aa335d71793f2cd219569188aedabd7d0239386b17f7728d8",
"created_at": 1686150071,
"kind": 1,
"tags": [
[
"e",
"1092d5ea64142286a0cd5c2b3aebd8da882fcd6a0c7a755bcf6c68f75e2e26e6",
"",
"root"
],
[
"e",
"79123ca80f2764e4bd80f78ba6e8c10fc40e52b70c5ef890e14615fa96acd9ce",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2013-05-16\n📝 Original message:We would only end up with few copies of the historic data if users\ncould choose what parts of the blockchain to store. Simply store\nchunks randomly, according to users available space, and give priority\nto the \"N most recent\" chunks to have more replicas in the network.\n\nYou don't need bittorrent specifically for a DHT, if publicity is a\nproblem. There are many DHT proposals and implementations, and i bet\none of them should be more suitable to the bitcoin network than\nbittorrent's.\n\n\u003eOn Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn \u003cmike at ...\u003e wrote:\n\u003e\u003e I'd imagined that nodes would be able to pick their own ranges to keep\n\u003e\u003e rather than have fixed chosen intervals. \"Everything or two weeks\" is rather\n\u003e\n\u003eX most recent is special for two reasons: It meshes well with actual demand,\n\u003eand the data is required for reorganization.\n\u003e\n\u003eSo whatever we do for historic data, N most recent should be treated specially.\n\u003e\n\u003eBut I also agree that its important that \u003ceverything\u003e be splittable into ranges\n\u003ebecause otherwise when having to choose between serving historic data\n\u003eand— say— 40 GB storage, a great many are going to choose not to serve\n\u003ehistoric data... and so nodes may be willing to contribute 4-39 GB storage\n\u003eto the network there will be no good way for them to do so and we may end\n\u003eup with too few copies of the historic data available.\n\u003e\n\u003eAs can be seen in the graph, once you get past the most recent 4000\n\u003eblocks the probability is fairly uniform... so \"N most recent\" is not a\n\u003egood way to divide load for the older blocks. But simple ranges— perhaps\n\u003equantized to groups of 100 or 1000 blocks or something— would work fine.\n\u003e\n\u003eThis doesn't have to come in the first cut, however— and it needs new\n\u003eaddr messages in any case.",
"sig": "af978158898f72355800ba23813ce3b3c21112a5ff161b455679d41268a90adfb456bc4c10d8d5e0a12f70c1b995a9fca6a6c20053381f8e45644169a3dd601f"
}