Blocks already checksum; they hash to a low number.<div><br></div><div>Also inre: block headers, you are furnished with a previous hash in the first 80 bytes of the block. You can always cut the connection at that moment if you've already seen the block headers.</div>
<div><br></div><div>Peter</div><div><br></div><div><div><br><div class="gmail_quote">On Mon, Apr 30, 2012 at 1:02 PM, Zell Faze <span dir="ltr"><<a href="mailto:zellfaze@yahoo.com" target="_blank">zellfaze@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
------------------------<br>
"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."<br>
— Jimmy Wales, Founder of Wikipedia<br>
Help protect it now. Please make a donation today: <a href="http://www.wikimediafoundation.org/wiki/Donate" target="_blank">http://www.wikimediafoundation.org/wiki/Donate</a><br>
<br>
<br>
<br>
--- On Mon, 4/30/12, Amir Taaki <<a href="mailto:zgenjix@yahoo.com">zgenjix@yahoo.com</a>> wrote:<br>
<br>
> From: Amir Taaki <<a href="mailto:zgenjix@yahoo.com">zgenjix@yahoo.com</a>><br>
<div class="im">> Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks<br>
</div>> To: "<a href="mailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>" <<a href="mailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>><br>
> Date: Monday, April 30, 2012, 3:11 PM<br>
<div class="HOEnZb"><div class="h5">> This is optimisation where it isn't<br>
> needed. Bandwidth is not the bottleneck of the Bitcoin<br>
> system. It is the immense time needed to validate the<br>
> blockchain.<br>
><br>
> And clients should never send blocks first. They always send<br>
> an inv packet, then you request the block. It is a<br>
> disruptive change and brings little.<br>
><br>
> We don't need to optimise every aspect of Bitcoin :) Just<br>
> focus on the big bits that matter, while keeping everything<br>
> working with minimal changes.<br>
><br>
> For instance say we did this and to maintain backwards<br>
> compatible, we introduced a new message called "hash+block".<br>
> Now there are 2 code branches that must be maintained -<br>
> urgh.<br>
><br>
><br>
> ________________________________<br>
> From: Wladimir <<a href="mailto:laanwj@gmail.com">laanwj@gmail.com</a>><br>
> To: Rebroad (sourceforge) <<a href="mailto:rebroad%2Bsourceforge.net@gmail.com">rebroad+sourceforge.net@gmail.com</a>><br>
><br>
> Cc: <a href="mailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a><br>
><br>
> Sent: Monday, April 30, 2012 7:26 PM<br>
> Subject: Re: [Bitcoin-development] BIP to improve the<br>
> availability of blocks<br>
><br>
><br>
> On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge)<br>
> <<a href="mailto:rebroad%2Bsourceforge.net@gmail.com">rebroad+sourceforge.net@gmail.com</a>><br>
> wrote:<br>
><br>
><br>
> >My proposal is that in addition to the size (which is<br>
> advertised in<br>
> >the header), the hash is also advertised in the header<br>
> (of a block).<br>
> >This would help nodes to determine whether they wanted<br>
> to reject the<br>
> >download. (e.g. if it already had a block matching that<br>
> hash). This of<br>
> >course wouldn't prevent a rogue node from sending an<br>
> incorrect hash,<br>
> >but this would aid in saving bandwidth amongst behaving<br>
> nodes.<br>
> ><br>
><br>
> I suppose it would make sense for clients to be able to<br>
> reject blocks that they already have, if that's not<br>
> currently possible.<br>
><br>
><br>
> The other part of the proposal is to allow nodes to request<br>
> upload and<br>
> >download blocks that have already been partially<br>
> downloaded.<br>
> ><br>
> >This could be done by modifying the existing methods of<br>
> upload,<br>
> >download, or by adding a new method, perhaps even using<br>
> HTTP/HTTPS or<br>
> >something similar. This would also help nodes to obtain<br>
> the blockchain<br>
> >who have restrictive ISPs, especially if they are being<br>
> served on port<br>
> >80 or 443. This could perhaps also allow web caches to<br>
> keep caches of<br>
> >the blockchain, thereby making it also more available<br>
> also.<br>
> ><br>
><br>
> You don't need a BIP if you want to somehow fetch the<br>
> (initial) block chain<br>
> outside the bitcoin protocol. You could download it from<br>
> some http<br>
> server or even pass it along on an USB stick. Then with a<br>
> simple client change you can import it: <a href="https://github.com/bitcoin/bitcoin/pull/883" target="_blank">https://github.com/bitcoin/bitcoin/pull/883</a> .<br>
><br>
><br>
> Currently, without this functionality, nodes with<br>
> restrictive (or<br>
> >slow) internet have some options, such as going via a<br>
> tor proxy, but<br>
> >due to the latency, the problem with multiple receptions<br>
> of the same<br>
> >block still occur.<br>
> ><br>
><br>
> If you're behind such a slow internet connection, and<br>
> concerned about<br>
> every bit of bandwidth, it is better to run a lightweight<br>
> node. For example, Electrum.<br>
><br>
> Even if you could reduce the wasted bandwidth a bit by<br>
> puzzling<br>
> around with partial blocks, the download will still be<br>
> substantial (and that's going to get worse before it gets<br>
> better).<br>
><br>
> Wladimir<br>
><br>
><br>
> ------------------------------------------------------------------------------<br>
> Live Security Virtual Conference<br>
> Exclusive live event will cover all the ways today's<br>
> security and<br>
> threat landscape has changed and how IT managers can<br>
> respond. Discussions<br>
> will include endpoint security, mobile security and the<br>
> latest in malware<br>
> threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
><br>
> ------------------------------------------------------------------------------<br>
> Live Security Virtual Conference<br>
> Exclusive live event will cover all the ways today's<br>
> security and<br>
> threat landscape has changed and how IT managers can<br>
> respond. Discussions<br>
> will include endpoint security, mobile security and the<br>
> latest in malware<br>
> threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
><br>
<br>
------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><table style="font-family:Times"><tbody><tr><td><img src="http://coinlab.com/images/coinlab-logo.png"></td><td valign="bottom"><div style="font-family:RobotoLight,'Lucida Grande',Helmet,Freesans,sans-serif;font-size:16px;line-height:20px">
Peter J. Vessenes<br>CEO, CoinLab<br>M: 206.595.9839<br>Skype: vessenes<br><a href="https://plus.google.com/112885659993091300749" target="_blank">Google+</a></div></td></tr></tbody></table><br>
</div></div>