Amir Taaki [ARCHIVE] on Nostr: 📅 Original date posted:2012-04-30 📝 Original message:This is optimisation where ...
📅 Original date posted:2012-04-30
📝 Original message:This is optimisation where it isn't needed. Bandwidth is not the bottleneck of the Bitcoin system. It is the immense time needed to validate the blockchain.
And clients should never send blocks first. They always send an inv packet, then you request the block. It is a disruptive change and brings little.
We don't need to optimise every aspect of Bitcoin :) Just focus on the big bits that matter, while keeping everything working with minimal changes.
For instance say we did this and to maintain backwards compatible, we introduced a new message called "hash+block". Now there are 2 code branches that must be maintained - urgh.
________________________________
From: Wladimir <laanwj at gmail.com>
To: Rebroad (sourceforge) <rebroad+sourceforge.net at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Monday, April 30, 2012 7:26 PM
Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
📝 Original message:This is optimisation where it isn't needed. Bandwidth is not the bottleneck of the Bitcoin system. It is the immense time needed to validate the blockchain.
And clients should never send blocks first. They always send an inv packet, then you request the block. It is a disruptive change and brings little.
We don't need to optimise every aspect of Bitcoin :) Just focus on the big bits that matter, while keeping everything working with minimal changes.
For instance say we did this and to maintain backwards compatible, we introduced a new message called "hash+block". Now there are 2 code branches that must be maintained - urgh.
________________________________
From: Wladimir <laanwj at gmail.com>
To: Rebroad (sourceforge) <rebroad+sourceforge.net at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Monday, April 30, 2012 7:26 PM
Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development