From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TBVoS-0002CS-ND for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 19:07:56 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of eigbox.net designates 66.96.188.4 as permitted sender) client-ip=66.96.188.4; envelope-from=SRS0=rXVvyT=HK=godofgod.co.uk=matthewmitchell@eigbox.net; helo=bosmailout04.eigbox.net; Received: from bosmailout04.eigbox.net ([66.96.188.4]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TBVoO-00045s-Vr for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 19:07:56 +0000 Received: from bosmailscan08.eigbox.net ([10.20.15.8]) by bosmailout04.eigbox.net with esmtp (Exim) id 1TBVoJ-0004vn-Ic for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 15:07:47 -0400 Received: from bosimpout02.eigbox.net ([10.20.55.2]) by bosmailscan08.eigbox.net with esmtp (Exim) id 1TBVoJ-00073E-El for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 15:07:47 -0400 Received: from bosauthsmtp13.eigbox.net ([10.20.18.13]) by bosimpout02.eigbox.net with NO UCE id xv7n1j00F0GvDVm01v7nKq; Tue, 11 Sep 2012 15:07:47 -0400 X-Authority-Analysis: v=2.0 cv=KtT6LxqN c=1 sm=1 a=cRTwvq1SzvVpLn7uyA08BA==:17 a=Goz4v7xpImgA:10 a=JhU9KSwl1l8A:10 a=RmqW3wxksLsA:10 a=N659UExz7-8A:10 a=eGitJVp2AAAA:8 a=-aUnnjAAwhoA:10 a=pC1eQIXatfgpUIqEt3QA:9 a=pILNOxqGKmIA:10 a=UH8/iCWBfdUmbm4Ft4Vi3Q==:117 X-EN-OrigOutIP: 10.20.18.13 X-EN-IMPSID: xv7n1j00F0GvDVm01v7nKq Received: from [109.175.173.22] by bosauthsmtp13.eigbox.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim) id 1TBVoJ-0002In-6b for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 15:07:47 -0400 From: Matthew Mitchell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk> Date: Tue, 11 Sep 2012 20:07:39 +0100 To: "bitcoin-development@lists.sourceforge.net" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) X-EN-UserInfo: c68a83c59c94ef03b40bb4bc312c51e4:dffc0a9b4c8a0435ad832ff5852cab82 X-EN-AuthUser: godofgod@godofgod.co.uk Sender: Matthew Mitchell X-EN-OrigIP: 109.175.173.22 X-EN-OrigHost: unknown X-Spam-Score: 1.1 (+) 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 1.5 RCVD_IN_PSBL RBL: Received via a relay in PSBL [66.96.188.4 listed in psbl.surriel.com] -0.0 SPF_PASS SPF: sender matches SPF record -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.5 SF_NO_SPF_SPAM SF_NO_SPF_SPAM X-Headers-End: 1TBVoO-00045s-Vr Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft. X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:07:56 -0000 For some reason sourceforge is not sending me updates anymore but I can = see the replies online=85 There could be a slightly more simple protocol which gives all the = transactions hashes and nodes can then download the transactions = separately. However there are two problems: 1. Downloading all the transactions individually might be inefficient. = My proposal will allow nodes to request multiple transactions at once. 2. Why not add a few additional components to the protocol to allow = requests for any level of the merkle tree? It's not very complicated at = all and protects against the future. Sure, analysis needs to be done to see at what point the proposal would = give benefit and I will hopefully get around to doing some measurements = of peer behaviour to aid with this. I think it's a good idea to think ahead rather than only do what is = beneficial for the network currently. The block sizes at the moment are = about 0.1MB but what if the bitcoin demand starts pushing that into = megabytes? And yes the ~0.95MB limit needs to be changed in order for = bitcoin to grow that far. Why would the limit not be lifted? How will = bitcoin demand be satisfied other than having large fees to deter = transactions, hoping the fees are large enough to balance the demand = with the block size limits to prevent many transactions being = unconfirmed and annoying users? That limit has got to go eventually. And = then it could be that block sizes do become large enough to worry about = the performance in relaying. Best not to leave this to the last minute, so at the very least I think = it's good to talk about this.=