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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TBYKD-0002gP-Fl for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 21:48:53 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of eigbox.net designates 66.96.188.16 as permitted sender) client-ip=66.96.188.16; envelope-from=SRS0=rXVvyT=HK=godofgod.co.uk=matthewmitchell@eigbox.net; helo=bosmailout16.eigbox.net; Received: from bosmailout16.eigbox.net ([66.96.188.16]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TBYKC-0006qY-Ns for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 21:48:53 +0000 Received: from bosmailscan01.eigbox.net ([10.20.15.1]) by bosmailout16.eigbox.net with esmtp (Exim) id 1TBYK7-00013x-Ee for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 17:48:47 -0400 Received: from bosimpout01.eigbox.net ([10.20.55.1]) by bosmailscan01.eigbox.net with esmtp (Exim) id 1TBYK7-0000Fx-4A; Tue, 11 Sep 2012 17:48:47 -0400 Received: from bosauthsmtp06.eigbox.net ([10.20.18.6]) by bosimpout01.eigbox.net with NO UCE id xxon1j00307rX7u01xonKK; Tue, 11 Sep 2012 17:48:47 -0400 X-Authority-Analysis: v=2.0 cv=aPZHX8Bm 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=pGLkceISAAAA:8 a=xWRbeWez38hbk6K_X2AA:9 a=pILNOxqGKmIA:10 a=MSl-tDqOz04A:10 a=7KhLVuCWMc1eCxG9:21 a=RC34QbZKBvMb1Vmp:21 a=fIc3/5IyPUehxkj7BpkQ7Q==:117 X-EN-OrigOutIP: 10.20.18.6 X-EN-IMPSID: xxon1j00307rX7u01xonKK Received: from [109.175.173.22] by bosauthsmtp06.eigbox.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim) id 1TBYK6-0000bF-PZ; Tue, 11 Sep 2012 17:48:46 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Matthew Mitchell In-Reply-To: Date: Tue, 11 Sep 2012 22:48:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk> References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk> To: 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.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.16 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: 1TBYKC-0006qY-Ns 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 21:48:53 -0000 On 11 Sep 2012, at 20:42, Gregory Maxwell wrote: > Someone can do that just by pipelining the one at a time requests. > How much bandwidth do you think you could save over that? You wouldn't need to pipeline the requests, just place more than one = inventory vector in get data, right? Well my messages would save the = space of those inventory vectors. Instead of needing 36 byte inventory = vectors for each transaction and a var int, you would need two var ints = only. And then the transaction responses only need one header, so you = save 24 bytes for each transaction after the first. You could say that = is a small benefit. =20 > I don't see what value this provides. For protecting against the > future you might as well suggest uploading x86 code which gets > executed to select transactions. "Protects against the future". Can > you clarify some more about exactly how you think it would help? Well it depends on wether you seriously think bitcoin blocks should be = limited at a million bytes or not. > it's not clear to me how your proposal is really all that useful for > very large blocks: I looks like it would lot of bytes sending > redundant tree data. Look at bittorrent. With bittorrent you don't download files from a = single peer all at once. > Bitcoin gets its value through scarcity. There are two kinds of > scarcity that are economically important, scarcity of the coins=97 = there > will never be more than 21 million=97 and scarcity of the block space > which, as the protocol is defined and enforced by every node can not > be more than 1MB. The latter scarcity is what makes the security model > economically sane. Why wouldn't requesting minimum fees in the software work as is done = currently? > Fortunately, its perfectly possible to make transactions denominated > in bitcoin outside of the blockchain, and in a secure and distributed > manner that respects the principles that make bitcoin attractive, but > with information hiding that improves privacy, transaction speed, and > scalability. See, e.g. the good work being done by Open transactions > to create distributed cryptographic banks. So blockchain scarcity > itself doesn't prevent Bitcoin from being a one world currency > (something which isn't at all sane no matter how big you make the > blocks if you don't allow for other modes of transaction processing=97 > who the heck wants to possibly wait an hour to get a 1 confirm > sodapop??). So what you essentially suggest is having bitcoin banks that maintain = trust through Open Transaction contracts which contains proof of = agreement, providing some legal protection? One wonders why have bitcoin = at all then? Why not have an elaborate e-money system between several = banks using Open Transactions? Bitcoin doesn't just contain proof of if = something was done right or not, it contains actual certainty that it = will be done right. And how does Open Transactions prevent fractional = reserve fraud? I suppose when people consider bitcoin banks, they will consider bitcoin = being useless. > but I know that changing it is precisely as > technically difficult as changing the 21 million limit Set the change to occur at some block in the future leaving time for = people to upgrade. Send out alert messages to notify users to upgrade. = Issue is, some people might not like the change for whatever reasons. As far as I see it, if bitcoin won't scale, then it's worth looking at = something different to bitcoin that will scale.=