From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TCA3a-0006FK-6e for bitcoin-development@lists.sourceforge.net; Thu, 13 Sep 2012 14:06:14 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of eigbox.net designates 66.96.186.17 as permitted sender) client-ip=66.96.186.17; envelope-from=SRS0=nh6BJu=HM=godofgod.co.uk=matthewmitchell@eigbox.net; helo=bosmailout17.eigbox.net; Received: from bosmailout17.eigbox.net ([66.96.186.17]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TCA3U-0004I5-KM for bitcoin-development@lists.sourceforge.net; Thu, 13 Sep 2012 14:06:14 +0000 Received: from bosmailscan12.eigbox.net ([10.20.15.12]) by bosmailout17.eigbox.net with esmtp (Exim) id 1TCA3P-0000Hx-2P for bitcoin-development@lists.sourceforge.net; Thu, 13 Sep 2012 10:06:03 -0400 Received: from bosimpout01.eigbox.net ([10.20.55.1]) by bosmailscan12.eigbox.net with esmtp (Exim) id 1TCA3O-0001k9-Rd; Thu, 13 Sep 2012 10:06:02 -0400 Received: from bosauthsmtp17.eigbox.net ([10.20.18.17]) by bosimpout01.eigbox.net with NO UCE id ye621j01g0N5uqq01e62o8; Thu, 13 Sep 2012 10:06:02 -0400 X-Authority-Analysis: v=2.0 cv=aPZHX8Bm c=1 sm=1 a=Vnyysazsc9gF4v5jbSvB8A==:17 a=Goz4v7xpImgA:10 a=JhU9KSwl1l8A:10 a=RmqW3wxksLsA:10 a=kj9zAlcOel0A:10 a=eGitJVp2AAAA:8 a=-aUnnjAAwhoA:10 a=t1VQV7EkAAAA:8 a=j4oatsTgFnEDZAen5aAA:9 a=CjuIK1q_8ugA:10 a=6m3agaRMXGwA:10 a=f4kFLigMKr8AH7rIJ//qJA==:117 X-EN-OrigOutIP: 10.20.18.17 X-EN-IMPSID: ye621j01g0N5uqq01e62o8 Received: from [109.175.173.27] by bosauthsmtp17.eigbox.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim) id 1TCA3N-0002Cf-VL; Thu, 13 Sep 2012 10:06:02 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Matthew Mitchell In-Reply-To: Date: Thu, 13 Sep 2012 15:05:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk> <19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk> To: Mike Hearn , Gregory Maxwell , "bitcoin-development@lists.sourceforge.net" 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.27 X-EN-OrigHost: unknown X-Spam-Score: -0.4 (/) 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 -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.6 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TCA3U-0004I5-KM 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: Thu, 13 Sep 2012 14:06:14 -0000 On 13 Sep 2012, at 09:42, Mike Hearn wrote: > For what it's worth I disagree with Gregory on nearly all these > points, so don't take it as some kind of consensus from the Bitcoin > community ;) >=20 > Matts change is reasonable but I think we all agree it has minimal > impact at the moment relative to other things, so something even more > complex than that seems like a non-starter. Bloom filtering is a lot > more important. Sure other things may be done before this, I was seeing this as a change = somewhere down the line but not urgent. @Gregory > But you only need to request the transactions you don't have. Most of > time you should already have almost all of the transactions. Yes, my proposal allows you to do this. You skip out transactions your = already have. My proposal is simply better than others because it takes = full advantage of the merkle tree structure with minor additions that = are simple to implement. How hard is it to get the hashes at a = particular level of a merkle tree? Not hard at all. How hard is it to = place a selection of transactions from a block into a message Not hard = at all. Implementation of the protocol requirements would be a piece of = cake. The harder bit would be to create an algorithm to determine the = best level of segmentation but this is not required to comply with the = protocol. > Because there is no motivation not to set them to zero, if you don't > someone else will The motivation to incentivise miners and maintain stronger security? The = difficulty only has to be high enough to prevent a cartel of malicious = miners taking control of the network, something that is potentially a = problem today with the large mining pools. Remember that the more = transactions there are the more fees there can be for miners to collect. = The more people that are using bitcoin, the greater bitcoins will be = worth. A bigger network should be good for miners when relying on fees. > And yes, of course, you schedule the change > for the future, but as you note that it doesn't solve the problem of > people opposing it. If it's so controversial that it creates a split making two separated = currencies then I'd see it turning out like the format wars (VHS vs = Betamax and Blu-ray vs HD-DVD). Eventually people will move towards one = or the other since it's better for people to have universalised = agreement on a system.=