References: <CAFBxzABqQBNdy9SbrKeePLsMdwwXDE7ghifh1GoOWscmpAZ+Tw@mail.gmail.com>
	<CA+s+GJCy4Utm14S_2KWofSORfsVuTJBYpwB0a7M26XHn1QQVYw@mail.gmail.com>
Message-ID: <1335813078.98321.YahooMailNeo@web121004.mail.ne1.yahoo.com>
Date: Mon, 30 Apr 2012 12:11:18 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CA+s+GJCy4Utm14S_2KWofSORfsVuTJBYpwB0a7M26XHn1QQVYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

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 block=
chain.=0A=0AAnd clients should never send blocks first. They always send an=
 inv packet, then you request the block. It is a disruptive change and brin=
gs little.=0A=0AWe don't need to optimise every aspect of Bitcoin :) Just f=
ocus on the big bits that matter, while keeping everything working with min=
imal changes.=0A=0AFor instance say we did this and to maintain backwards c=
ompatible, we introduced a new message called "hash+block". Now there are 2=
 code branches that must be maintained - urgh.=0A=0A=0A____________________=
____________=0AFrom: Wladimir <laanwj@gmail.com>=0ATo: Rebroad (sourceforge=
) <rebroad+sourceforge.net@gmail.com> =0ACc: bitcoin-development@lists.sour=
ceforge.net =0ASent: Monday, April 30, 2012 7:26 PM=0ASubject: Re: [Bitcoin=
-development] BIP to improve the availability of blocks=0A=0A=0AOn Mon, Apr=
 30, 2012 at 6:40 PM, Rebroad (sourceforge) <rebroad+sourceforge.net@gmail.=
com> wrote: =0A=0A=0A>My proposal is that in addition to the size (which is=
 advertised in=0A>the header), the hash is also advertised in the header (o=
f a block).=0A>This would help nodes to determine whether they wanted to re=
ject the=0A>download. (e.g. if it already had a block matching that hash). =
This of=0A>course wouldn't prevent a rogue node from sending an incorrect h=
ash,=0A>but this would aid in saving bandwidth amongst behaving nodes.=0A>=
=0A=0AI suppose it would make sense for clients to be able to reject blocks=
 that they already have, if that's not currently possible.=0A=0A=0AThe othe=
r part of the proposal is to allow nodes to request upload and=0A>download =
blocks that have already been partially downloaded.=0A>=0A>This could be do=
ne by modifying the existing methods of upload,=0A>download, or by adding a=
 new method, perhaps even using HTTP/HTTPS or=0A>something similar. This wo=
uld also help nodes to obtain the blockchain=0A>who have restrictive ISPs, =
especially if they are being served on port=0A>80 or 443. This could perhap=
s also allow web caches to keep caches of=0A>the blockchain, thereby making=
 it also more available also.=0A>=0A=0AYou don't need a BIP if you want to =
somehow fetch the (initial) block chain =0Aoutside the bitcoin protocol. Yo=
u could download it from some http =0Aserver or even pass it along on an US=
B stick. Then with a simple client change you can import it: https://github=
.com/bitcoin/bitcoin/pull/883 .=0A=0A=0ACurrently, without this=A0functiona=
lity, nodes with restrictive (or=0A>slow) internet have some options, such =
as going via a tor proxy, but=0A>due to the latency, the problem with multi=
ple receptions of the same=0A>block still occur.=0A>=0A=0AIf you're behind =
such a slow internet connection, and concerned about =0Aevery bit of bandwi=
dth, it is better to run a lightweight node. For example, Electrum.=0A=0AEv=
en if you could reduce the wasted bandwidth a bit by puzzling =0Aaround wit=
h partial blocks, the download will still be substantial (and that's going =
to get worse before it gets better). =0A=0AWladimir=0A=0A=0A---------------=
---------------------------------------------------------------=0ALive Secu=
rity Virtual Conference=0AExclusive live event will cover all the ways toda=
y's security and =0Athreat landscape has changed and how IT managers can re=
spond. Discussions =0Awill include endpoint security, mobile security and t=
he latest in malware =0Athreats. http://www.accelacomm.com/jaw/sfrnl0424201=
2/114/50122263/=0A_______________________________________________=0ABitcoin=
-development mailing list=0ABitcoin-development@lists.sourceforge.net=0Ahtt=
ps://lists.sourceforge.net/lists/listinfo/bitcoin-development