Published on: 2012-04-30T20:54:37+00:00
The discussion in this context revolves around a proposal to improve the availability of blocks in Bitcoin. One member proposes adding a checksum for the blocks to save bandwidth among behaving nodes, but another argues that bandwidth is not the bottleneck of the Bitcoin system and it is the immense time needed to validate the blockchain. Clients should never send blocks first, but always an inv packet, then request the block.Amir Taaki, a bitcoin developer, stated that the proposed Bitcoin Improvement Proposal (BIP) to improve the availability of blocks is an optimization that is not needed because bandwidth is not the bottleneck of the Bitcoin system. He also stated that clients should never send blocks first and this change will cause disruption and bring little benefit. On the other hand, Rebroad suggested adding a hash to the block header to enable nodes to reject an already downloaded block, which would aid in saving bandwidth among well-behaving nodes.Wladimir noted that it would make sense for clients to be able to reject blocks they already have, but there would be no need for a BIP if you want to somehow fetch the block chain outside the bitcoin protocol. It could be downloaded from some http server or passed along on a USB stick. Currently, nodes with restrictive or slow internet have options such as going via a tor proxy; however, the problem with multiple receptions of the same block still occurs due to latency. If one is behind such a slow internet connection and concerned about every bit of bandwidth, it is better to run a lightweight node like Electrum.The email thread discusses a proposal to improve the availability of blocks in the Bitcoin system. The proposal suggests advertising hash in addition to the size in the header block, which would help nodes reject downloads if they already have a matching block to save bandwidth. Wladimir agrees that it would make sense for clients to be able to reject blocks they already have. However, he points out that introducing a new feature like this can cause maintenance and compatibility issues.Another part of the proposal is to allow nodes to request upload and download blocks that have already been partially downloaded. However, Wladimir thinks that introducing a BIP for this is unnecessary as users can simply download the blockchain from an HTTP server or pass it along on a USB stick. He suggests that running a lightweight node like Electrum could be a better option for those with restrictive or slow internet connections.In a forum discussion on SourceForge, Rebroad proposed adding hash advertisements in the header of a block, which would help nodes determine if they want to reject a download. This proposal could aid in saving bandwidth among behaving nodes. Rebroad also suggested modifying existing methods or adding a new method to allow nodes to request upload and download partially downloaded blocks. This would help nodes obtain the blockchain who have restrictive ISPs, especially if they are being served on port 80 or 443. Another option for those with slow or restrictive internet is to run a lightweight node like Electrum. However, Wladimir pointed out that even with partial blocks, the download will still be substantial.The proposal put forth by Ed to Bitcoin developers is to extend the protocol to allow partial block download and upload for people with intermittent or restricted internet connectivity. The proposal suggests adding the hash along with the size in the header of a block, which would help nodes determine whether they want to reject the download if they already have the same block. This addition could save bandwidth amongst behaving nodes. The other part of the proposal is to allow nodes to request the upload and download of blocks that have already been partially downloaded, which can be done by modifying existing methods of upload and download or by adding a new method, possibly using HTTP/HTTPS or similar methods. This could help nodes obtain the blockchain if they have restrictive ISPs, especially if it's served on ports 80 or 443. Moreover, web caches could keep caches of the blockchain, making it more widely available. Currently, nodes with restrictive or slow internet have some options, such as going via a tor proxy, but there are problems with multiple receptions of the same block due to latency. In conclusion, Ed's proposal aims to make the blockchain more accessible to nodes with limited internet connectivity while also saving bandwidth among nodes.
Updated on: 2023-08-01T03:27:44.714263+00:00