Message-ID: <1335816167.89493.YahooMailClassic@web120904.mail.ne1.yahoo.com>
Date: Mon, 30 Apr 2012 13:02:47 -0700 (PDT)
From: Zell Faze <zellfaze@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <1335813078.98321.YahooMailNeo@web121004.mail.ne1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
Precedence: list

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 eve=
r), but it may be at some point.  This change will help Bitcoin scale.=0A=
=0A------------------------=0A"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."=0A=E2=80=94 Jimmy Wales, Founder of Wikipedia =0AHelp=
 protect it now. Please make a donation today: http://www.wikimediafoundati=
on.org/wiki/Donate=0A=0A=0A=0A--- On Mon, 4/30/12, Amir Taaki <zgenjix@yaho=
o.com> wrote:=0A=0A> From: Amir Taaki <zgenjix@yahoo.com>=0A> Subject: Re: =
[Bitcoin-development] BIP to improve the availability of blocks=0A> To: "bi=
tcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourcef=
orge.net>=0A> Date: Monday, April 30, 2012, 3:11 PM=0A> This is optimisatio=
n where it isn't=0A> needed. Bandwidth is not the bottleneck of the Bitcoin=
=0A> system. It is the immense time needed to validate the=0A> blockchain.=
=0A> =0A> And clients should never send blocks first. They always send=0A> =
an inv packet, then you request the block. It is a=0A> disruptive change an=
d brings little.=0A> =0A> We don't need to optimise every aspect of Bitcoin=
 :) Just=0A> focus on the big bits that matter, while keeping everything=0A=
> working with minimal changes.=0A> =0A> For instance say we did this and t=
o maintain backwards=0A> compatible, we introduced a new message called "ha=
sh+block".=0A> Now there are 2 code branches that must be maintained -=0A> =
urgh.=0A> =0A> =0A> ________________________________=0A> From: Wladimir <la=
anwj@gmail.com>=0A> To: Rebroad (sourceforge) <rebroad+sourceforge.net@gmai=
l.com>=0A> =0A> Cc: bitcoin-development@lists.sourceforge.net=0A> =0A> Sent=
: Monday, April 30, 2012 7:26 PM=0A> Subject: Re: [Bitcoin-development] BIP=
 to improve the=0A> availability of blocks=0A> =0A> =0A> On Mon, Apr 30, 20=
12 at 6:40 PM, Rebroad (sourceforge)=0A> <rebroad+sourceforge.net@gmail.com=
>=0A> wrote: =0A> =0A> =0A> >My proposal is that in addition to the size (w=
hich is=0A> advertised in=0A> >the header), the hash is also advertised in =
the header=0A> (of a block).=0A> >This would help nodes to determine whethe=
r they wanted=0A> to reject the=0A> >download. (e.g. if it already had a bl=
ock matching that=0A> hash). This of=0A> >course wouldn't prevent a rogue n=
ode from sending an=0A> incorrect hash,=0A> >but this would aid in saving b=
andwidth amongst behaving=0A> nodes.=0A> >=0A> =0A> I suppose it would make=
 sense for clients to be able to=0A> reject blocks that they already have, =
if that's not=0A> currently possible.=0A> =0A> =0A> The other part of the p=
roposal is to allow nodes to request=0A> upload and=0A> >download blocks th=
at have already been partially=0A> downloaded.=0A> >=0A> >This could be don=
e by modifying the existing methods of=0A> upload,=0A> >download, or by add=
ing a new method, perhaps even using=0A> HTTP/HTTPS or=0A> >something simil=
ar. This would also help nodes to obtain=0A> the blockchain=0A> >who have r=
estrictive ISPs, especially if they are being=0A> served on port=0A> >80 or=
 443. This could perhaps also allow web caches to=0A> keep caches of=0A> >t=
he blockchain, thereby making it also more available=0A> also.=0A> >=0A> =
=0A> You don't need a BIP if you want to somehow fetch the=0A> (initial) bl=
ock chain =0A> outside the bitcoin protocol. You could download it from=0A>=
 some http =0A> server or even pass it along on an USB stick. Then with a=
=0A> simple client change you can import it: https://github.com/bitcoin/bit=
coin/pull/883 .=0A> =0A> =0A> Currently, without this=C2=A0functionality, n=
odes with=0A> restrictive (or=0A> >slow) internet have some options, such a=
s going via a=0A> tor proxy, but=0A> >due to the latency, the problem with =
multiple receptions=0A> of the same=0A> >block still occur.=0A> >=0A> =0A> =
If you're behind such a slow internet connection, and=0A> concerned about =
=0A> every bit of bandwidth, it is better to run a lightweight=0A> node. Fo=
r example, Electrum.=0A> =0A> Even if you could reduce the wasted bandwidth=
 a bit by=0A> puzzling =0A> around with partial blocks, the download will s=
till be=0A> substantial (and that's going to get worse before it gets=0A> b=
etter). =0A> =0A> Wladimir=0A> =0A> =0A> ----------------------------------=
--------------------------------------------=0A> Live Security Virtual Conf=
erence=0A> Exclusive live event will cover all the ways today's=0A> securit=
y and =0A> threat landscape has changed and how IT managers can=0A> respond=
. Discussions =0A> will include endpoint security, mobile security and the=
=0A> latest in malware =0A> threats. http://www.accelacomm.com/jaw/sfrnl042=
42012/114/50122263/=0A> _______________________________________________=0A>=
 Bitcoin-development mailing list=0A> Bitcoin-development@lists.sourceforge=
.net=0A> https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
=0A> =0A> -----------------------------------------------------------------=
-------------=0A> Live Security Virtual Conference=0A> Exclusive live event=
 will cover all the ways today's=0A> security and =0A> threat landscape has=
 changed and how IT managers can=0A> respond. Discussions =0A> will include=
 endpoint security, mobile security and the=0A> latest in malware =0A> thre=
ats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/=0A> ________=
_______________________________________=0A> Bitcoin-development mailing lis=
t=0A> Bitcoin-development@lists.sourceforge.net=0A> https://lists.sourcefor=
ge.net/lists/listinfo/bitcoin-development=0A>