path: root/11/dcfc4afca77e23913836c7ded5f41198084944

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <peter@coinlab.com>) id 1SOy6G-0002T7-14
	for bitcoin-development@lists.sourceforge.net;
	Mon, 30 Apr 2012 21:25:40 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
	designates 209.85.214.175 as permitted sender)
	client-ip=209.85.214.175; envelope-from=peter@coinlab.com;
	helo=mail-ob0-f175.google.com; 
Received: from mail-ob0-f175.google.com ([209.85.214.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1SOy6D-00063x-ON
	for bitcoin-development@lists.sourceforge.net;
	Mon, 30 Apr 2012 21:25:39 +0000
Received: by obhx4 with SMTP id x4so4507623obh.34
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 30 Apr 2012 14:25:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=VhVv9idaiP/vuil5SLk1u8khxbLEXkj2kjj1ctSaemQ=;
	b=HvW6qwVxCh1mtLJMxmGTSITMlV+HvxJraPR62FJtIufOnT/tseo3jy+/9Hnj5mJ2Jh
	UPhHFr/EjvEHSgMqvyFuPxNH3eyBeRU5UeMq5Wtdwdjt9hosybzMnKTcPL9uRDE9kIUI
	I2SvcoYFfgpMpwM2WFr0czR2yTmFlFSXXRZCmmy6D22AxAZPTgIKi5Fmo4OnQoEGJIIL
	6uIUBa9fGptWSUmlF2T1xKKRfURw1HbAFJVOHJmYlXNVcNbuLWLz8vbJL9m5BzPj/2nY
	iVhHp9Dm3IALBgrEAKZFRQJegpBgm4EzjpdeQ6Uup2IjiL7eulU2Qa1og1K8zDLG7Gkm
	ayLw==
Received: by 10.182.122.4 with SMTP id lo4mr30132496obb.24.1335819297768; Mon,
	30 Apr 2012 13:54:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.56.226 with HTTP; Mon, 30 Apr 2012 13:54:37 -0700 (PDT)
In-Reply-To: <1335816167.89493.YahooMailClassic@web120904.mail.ne1.yahoo.com>
References: <1335813078.98321.YahooMailNeo@web121004.mail.ne1.yahoo.com>
	<1335816167.89493.YahooMailClassic@web120904.mail.ne1.yahoo.com>
From: Peter Vessenes <peter@coinlab.com>
Date: Mon, 30 Apr 2012 13:54:37 -0700
Message-ID: <CAMGNxUvBRjDM5MykRv6P_k=yxgsTxbL+shu9_3henAn4TG_LjA@mail.gmail.com>
To: Zell Faze <zellfaze@yahoo.com>
Content-Type: multipart/alternative; boundary=f46d044785fdba45df04beebaa8e
X-Gm-Message-State: ALoCoQmuCQTEHxdnReTruxVj4msrydXiEtzcoYvSXUNnEK6AxeICUdqOjA5qLdPC2XjLIHvpVr2f
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1SOy6D-00063x-ON
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 21:25:40 -0000

--f46d044785fdba45df04beebaa8e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Blocks already checksum; they hash to a low number.

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.

Peter


On Mon, Apr 30, 2012 at 1:02 PM, Zell Faze <zellfaze@yahoo.com> wrote:

> 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."
> =97 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@yahoo.com> wrote:
>
> > From: Amir Taaki <zgenjix@yahoo.com>
> > Subject: Re: [Bitcoin-development] BIP to improve the availability of
> blocks
> > To: "bitcoin-development@lists.sourceforge.net" <
> bitcoin-development@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@gmail.com>
> > To: Rebroad (sourceforge) <rebroad+sourceforge.net@gmail.com>
> >
> > Cc: bitcoin-development@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@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@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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



--=20
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>

--f46d044785fdba45df04beebaa8e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 8=
0 bytes of the block. You can always cut the connection at that moment if y=
ou&#39;ve already seen the block headers.</div>

<div><br></div><div>Peter</div><div><br></div><div><div><br><div class=3D"g=
mail_quote">On Mon, Apr 30, 2012 at 1:02 PM, Zell Faze <span dir=3D"ltr">&l=
t;<a href=3D"mailto:zellfaze@yahoo.com" target=3D"_blank">zellfaze@yahoo.co=
m</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Although quite true, I actually agree though=
 that there should be some sort of checksum for the blocks. =A0Bandwidth ma=
y not be a bottleneck now (or ever), but it may be at some point. =A0This c=
hange will help Bitcoin scale.<br>


<br>
------------------------<br>
&quot;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.&quot=
;<br>
=97 Jimmy Wales, Founder of Wikipedia<br>
Help protect it now. Please make a donation today: <a href=3D"http://www.wi=
kimediafoundation.org/wiki/Donate" target=3D"_blank">http://www.wikimediafo=
undation.org/wiki/Donate</a><br>
<br>
<br>
<br>
--- On Mon, 4/30/12, Amir Taaki &lt;<a href=3D"mailto:zgenjix@yahoo.com">zg=
enjix@yahoo.com</a>&gt; wrote:<br>
<br>
&gt; From: Amir Taaki &lt;<a href=3D"mailto:zgenjix@yahoo.com">zgenjix@yaho=
o.com</a>&gt;<br>
<div class=3D"im">&gt; Subject: Re: [Bitcoin-development] BIP to improve th=
e availability of blocks<br>
</div>&gt; To: &quot;<a href=3D"mailto:bitcoin-development@lists.sourceforg=
e.net">bitcoin-development@lists.sourceforge.net</a>&quot; &lt;<a href=3D"m=
ailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.=
sourceforge.net</a>&gt;<br>


&gt; Date: Monday, April 30, 2012, 3:11 PM<br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt; This is optimisation where it =
isn&#39;t<br>
&gt; needed. Bandwidth is not the bottleneck of the Bitcoin<br>
&gt; system. It is the immense time needed to validate the<br>
&gt; blockchain.<br>
&gt;<br>
&gt; And clients should never send blocks first. They always send<br>
&gt; an inv packet, then you request the block. It is a<br>
&gt; disruptive change and brings little.<br>
&gt;<br>
&gt; We don&#39;t need to optimise every aspect of Bitcoin :) Just<br>
&gt; focus on the big bits that matter, while keeping everything<br>
&gt; working with minimal changes.<br>
&gt;<br>
&gt; For instance say we did this and to maintain backwards<br>
&gt; compatible, we introduced a new message called &quot;hash+block&quot;.=
<br>
&gt; Now there are 2 code branches that must be maintained -<br>
&gt; urgh.<br>
&gt;<br>
&gt;<br>
&gt; ________________________________<br>
&gt; From: Wladimir &lt;<a href=3D"mailto:laanwj@gmail.com">laanwj@gmail.co=
m</a>&gt;<br>
&gt; To: Rebroad (sourceforge) &lt;<a href=3D"mailto:rebroad%2Bsourceforge.=
net@gmail.com">rebroad+sourceforge.net@gmail.com</a>&gt;<br>
&gt;<br>
&gt; Cc: <a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitco=
in-development@lists.sourceforge.net</a><br>
&gt;<br>
&gt; Sent: Monday, April 30, 2012 7:26 PM<br>
&gt; Subject: Re: [Bitcoin-development] BIP to improve the<br>
&gt; availability of blocks<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge)<br>
&gt; &lt;<a href=3D"mailto:rebroad%2Bsourceforge.net@gmail.com">rebroad+sou=
rceforge.net@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; &gt;My proposal is that in addition to the size (which is<br>
&gt; advertised in<br>
&gt; &gt;the header), the hash is also advertised in the header<br>
&gt; (of a block).<br>
&gt; &gt;This would help nodes to determine whether they wanted<br>
&gt; to reject the<br>
&gt; &gt;download. (e.g. if it already had a block matching that<br>
&gt; hash). This of<br>
&gt; &gt;course wouldn&#39;t prevent a rogue node from sending an<br>
&gt; incorrect hash,<br>
&gt; &gt;but this would aid in saving bandwidth amongst behaving<br>
&gt; nodes.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I suppose it would make sense for clients to be able to<br>
&gt; reject blocks that they already have, if that&#39;s not<br>
&gt; currently possible.<br>
&gt;<br>
&gt;<br>
&gt; The other part of the proposal is to allow nodes to request<br>
&gt; upload and<br>
&gt; &gt;download blocks that have already been partially<br>
&gt; downloaded.<br>
&gt; &gt;<br>
&gt; &gt;This could be done by modifying the existing methods of<br>
&gt; upload,<br>
&gt; &gt;download, or by adding a new method, perhaps even using<br>
&gt; HTTP/HTTPS or<br>
&gt; &gt;something similar. This would also help nodes to obtain<br>
&gt; the blockchain<br>
&gt; &gt;who have restrictive ISPs, especially if they are being<br>
&gt; served on port<br>
&gt; &gt;80 or 443. This could perhaps also allow web caches to<br>
&gt; keep caches of<br>
&gt; &gt;the blockchain, thereby making it also more available<br>
&gt; also.<br>
&gt; &gt;<br>
&gt;<br>
&gt; You don&#39;t need a BIP if you want to somehow fetch the<br>
&gt; (initial) block chain<br>
&gt; outside the bitcoin protocol. You could download it from<br>
&gt; some http<br>
&gt; server or even pass it along on an USB stick. Then with a<br>
&gt; simple client change you can import it: <a href=3D"https://github.com/=
bitcoin/bitcoin/pull/883" target=3D"_blank">https://github.com/bitcoin/bitc=
oin/pull/883</a> .<br>
&gt;<br>
&gt;<br>
&gt; Currently, without this=A0functionality, nodes with<br>
&gt; restrictive (or<br>
&gt; &gt;slow) internet have some options, such as going via a<br>
&gt; tor proxy, but<br>
&gt; &gt;due to the latency, the problem with multiple receptions<br>
&gt; of the same<br>
&gt; &gt;block still occur.<br>
&gt; &gt;<br>
&gt;<br>
&gt; If you&#39;re behind such a slow internet connection, and<br>
&gt; concerned about<br>
&gt; every bit of bandwidth, it is better to run a lightweight<br>
&gt; node. For example, Electrum.<br>
&gt;<br>
&gt; Even if you could reduce the wasted bandwidth a bit by<br>
&gt; puzzling<br>
&gt; around with partial blocks, the download will still be<br>
&gt; substantial (and that&#39;s going to get worse before it gets<br>
&gt; better).<br>
&gt;<br>
&gt; Wladimir<br>
&gt;<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; Live Security Virtual Conference<br>
&gt; Exclusive live event will cover all the ways today&#39;s<br>
&gt; security and<br>
&gt; threat landscape has changed and how IT managers can<br>
&gt; respond. Discussions<br>
&gt; will include endpoint security, mobile security and the<br>
&gt; latest in malware<br>
&gt; threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/50=
122263/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/=
50122263/</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; Live Security Virtual Conference<br>
&gt; Exclusive live event will cover all the ways today&#39;s<br>
&gt; security and<br>
&gt; threat landscape has changed and how IT managers can<br>
&gt; respond. Discussions<br>
&gt; will include endpoint security, mobile security and the<br>
&gt; latest in malware<br>
&gt; threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/50=
122263/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/=
50122263/</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
<br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today&#39;s security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<table style=3D"font-family:Times"><tbody><tr><td><img src=3D"http://coinla=
b.com/images/coinlab-logo.png"></td><td valign=3D"bottom"><div style=3D"fon=
t-family:RobotoLight,&#39;Lucida Grande&#39;,Helmet,Freesans,sans-serif;fon=
t-size:16px;line-height:20px">

Peter J. Vessenes<br>CEO, CoinLab<br>M: 206.595.9839<br>Skype: vessenes<br>=
<a href=3D"https://plus.google.com/112885659993091300749" target=3D"_blank"=
>Google+</a></div></td></tr></tbody></table><br>
</div></div>

--f46d044785fdba45df04beebaa8e--