Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SOw0L-0002tW-5s for bitcoin-development@lists.sourceforge.net; Mon, 30 Apr 2012 19:11:25 +0000 X-ACL-Warn: Received: from nm26-vm0.bullet.mail.ne1.yahoo.com ([98.138.91.68]) by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1SOw0K-0007S0-2W for bitcoin-development@lists.sourceforge.net; Mon, 30 Apr 2012 19:11:25 +0000 Received: from [98.138.90.51] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2012 19:11:18 -0000 Received: from [98.138.89.192] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2012 19:11:18 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 30 Apr 2012 19:11:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 326198.58403.bm@omp1050.mail.ne1.yahoo.com Received: (qmail 55191 invoked by uid 60001); 30 Apr 2012 19:11:18 -0000 X-YMail-OSG: UwMkTLAVM1mSwEaxi1AYQGNbvzZomQelrz2w_jSnuLZ8xV8 0RjQQEOU578IbLclLf_AuMvzFbWRc5GbdVk3cwXhhbU5dmaJYqafIrNikqlx mEOZ2_Jf0zZW_TY9H890aTjrPdHr5GjRc0aou2UxnmH4ZB3ShsyfE1Bx1KYF E67eSZGLrIG3YmRLLuzRSRjamUL4eFrmtxr5Gmws4ipWkpUm5nOWO2dJzgLj lZ46hjEInTu30pCK3rcqZynTV4a41zmZ5qsQ72bjO04f_z3pmIT9K4NZqJaX jdv6z.Saw2PRasMGS2yBrC0ysJMi0hn167rv6kRnNllXAY1TmopYC7YUxhyc d62nk9ePw6tpGWaEFNLwHQgW_ze3sxj1OiEAG6CipQoNLSH_WzEGaoEOt3p. La2XmGYHgfVUVd9RkaaohQDD61zHOdOnbeTmDR_.ZpcgtR4yC3s.pKDVb1IO zW2vEOmpCFW.7cOJzm1uNzBcU50yp.B_gTjrhF0JKZWE8tr2j3jsc6WKrAmd 0JidqZThEbTknJ_jSe965yu.NV9QrwB0KVB5VsxKjtMfNQmt3I_dUWEL_JSP EjRNLHMpgbzk8BRxB8hgT8wFV5A-- Received: from [92.20.187.109] by web121004.mail.ne1.yahoo.com via HTTP; Mon, 30 Apr 2012 12:11:18 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: Message-ID: <1335813078.98321.YahooMailNeo@web121004.mail.ne1.yahoo.com> Date: Mon, 30 Apr 2012 12:11:18 -0700 (PDT) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.91.68 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1SOw0K-0007S0-2W 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 Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:11:25 -0000 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 =0ATo: Rebroad (sourceforge= ) =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) 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