Zell Faze [ARCHIVE] on Nostr: 📅 Original date posted:2012-04-30 📝 Original message:Although quite true, I ...

📅 Original date posted:2012-04-30
📝 Original message:Although quite true, I actually agree though that there should be some sort of checksum for the blocks. Bandwidth may not be a bottleneck now (or ever), but it may be at some point. This change will help Bitcoin scale.

------------------------
"It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives."
— Jimmy Wales, Founder of Wikipedia
Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate



--- On Mon, 4/30/12, Amir Taaki <zgenjix at yahoo.com> wrote:

> From: Amir Taaki <zgenjix at yahoo.com>
> Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
> To: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
> Date: Monday, April 30, 2012, 3:11 PM
> 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
>
> ------------------------------------------------------------------------------
> 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
>