📅 Original date posted:2012-04-30
📝 Original message:On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge) <
rebroad+sourceforge.net at gmail.com> wrote:
>
> My proposal is that in addition to the size (which is advertised in
> the header), the hash is also advertised in the header (of a block).
> This would help nodes to determine whether they wanted to reject the
> download. (e.g. if it already had a block matching that hash). This of
> course wouldn't prevent a rogue node from sending an incorrect hash,
> but this would aid in saving bandwidth amongst behaving nodes.
>
I suppose it would make sense for clients to be able to reject blocks that
they already have, if that's not currently possible.
The other part of the proposal is to allow nodes to request upload and
> download blocks that have already been partially downloaded.
>
> This could be done by modifying the existing methods of upload,
> download, or by adding a new method, perhaps even using HTTP/HTTPS or
> something similar. This would also help nodes to obtain the blockchain
> who have restrictive ISPs, especially if they are being served on port
> 80 or 443. This could perhaps also allow web caches to keep caches of
> the blockchain, thereby making it also more available also.
>
You don't need a BIP if you want to somehow fetch the (initial) block chain
outside the bitcoin protocol. You could download it from some http server
or even pass it along on an USB stick. Then with a simple client change you
can import it: https://github.com/bitcoin/bitcoin/pull/883 .
Currently, without this functionality, nodes with restrictive (or
> slow) internet have some options, such as going via a tor proxy, but
> due to the latency, the problem with multiple receptions of the same
> block still occur.
>
If you're behind such a slow internet connection, and concerned about every
bit of bandwidth, it is better to run a lightweight node. For example,
Electrum.
Even if you could reduce the wasted bandwidth a bit by puzzling around with
partial blocks, the download will still be substantial (and that's going to
get worse before it gets better).
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120430/874d7838/attachment.html>;
Wladimir [ARCHIVE] /
npub1xq…ymc2p
2023-06-07 10:05:28
in reply to nevent1q…8vre
Author Public Key
npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2pSeen on
wss://nostr21.comPublished at
2023-06-07 10:05:28Event JSON
{
"id": "5d268c817571d74eb2690cd6df58707f740d3702084e66adfce016d15997930c",
"pubkey": "30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722",
"created_at": 1686132328,
"kind": 1,
"tags": [
[
"e",
"b1869bd66cd5575b05a9f209428289dafc8f4de2160bcae68ae6070ca8b47fc6",
"",
"root"
],
[
"e",
"07c5209be36e61c23f65cf66382b04b683caa5beeb9ed2b5b4fb0c737fcb30dc",
"",
"reply"
],
[
"p",
"624c501b2cfe965bd947828b1e2703bc4899d913d5aa28f30ee6d91f69f47155"
]
],
"content": "📅 Original date posted:2012-04-30\n📝 Original message:On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge) \u003c\nrebroad+sourceforge.net at gmail.com\u003e wrote:\n\n\u003e\n\u003e My proposal is that in addition to the size (which is advertised in\n\u003e the header), the hash is also advertised in the header (of a block).\n\u003e This would help nodes to determine whether they wanted to reject the\n\u003e download. (e.g. if it already had a block matching that hash). This of\n\u003e course wouldn't prevent a rogue node from sending an incorrect hash,\n\u003e but this would aid in saving bandwidth amongst behaving nodes.\n\u003e\n\nI suppose it would make sense for clients to be able to reject blocks that\nthey already have, if that's not currently possible.\n\nThe other part of the proposal is to allow nodes to request upload and\n\u003e download blocks that have already been partially downloaded.\n\u003e\n\u003e This could be done by modifying the existing methods of upload,\n\u003e download, or by adding a new method, perhaps even using HTTP/HTTPS or\n\u003e something similar. This would also help nodes to obtain the blockchain\n\u003e who have restrictive ISPs, especially if they are being served on port\n\u003e 80 or 443. This could perhaps also allow web caches to keep caches of\n\u003e the blockchain, thereby making it also more available also.\n\u003e\n\nYou don't need a BIP if you want to somehow fetch the (initial) block chain\noutside the bitcoin protocol. You could download it from some http server\nor even pass it along on an USB stick. Then with a simple client change you\ncan import it: https://github.com/bitcoin/bitcoin/pull/883 .\n\nCurrently, without this functionality, nodes with restrictive (or\n\u003e slow) internet have some options, such as going via a tor proxy, but\n\u003e due to the latency, the problem with multiple receptions of the same\n\u003e block still occur.\n\u003e\n\nIf you're behind such a slow internet connection, and concerned about every\nbit of bandwidth, it is better to run a lightweight node. For example,\nElectrum.\n\nEven if you could reduce the wasted bandwidth a bit by puzzling around with\npartial blocks, the download will still be substantial (and that's going to\nget worse before it gets better).\n\nWladimir\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120430/874d7838/attachment.html\u003e",
"sig": "2d4fdcdb86e840d2d3f87bf69cf6b8326d7a08abba51e899c67e11fe5b11fe162b79b0e00a7a564bb8babf1b9e89c4f68e96d7570142d2cb1da76ae09bb2c805"
}