From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UWf4j-0007HB-Dt for bitcoin-development@lists.sourceforge.net; Mon, 29 Apr 2013 03:48:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com designates 74.125.83.50 as permitted sender) client-ip=74.125.83.50; envelope-from=john.dillon892@googlemail.com; helo=mail-ee0-f50.google.com; Received: from mail-ee0-f50.google.com ([74.125.83.50]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UWf4i-00068Y-FH for bitcoin-development@lists.sourceforge.net; Mon, 29 Apr 2013 03:48:25 +0000 Received: by mail-ee0-f50.google.com with SMTP id b15so1356117eek.37 for ; Sun, 28 Apr 2013 20:48:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.223.72 with SMTP id u48mr111559638eep.44.1367207298103; Sun, 28 Apr 2013 20:48:18 -0700 (PDT) Received: by 10.223.72.141 with HTTP; Sun, 28 Apr 2013 20:48:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Apr 2013 03:48:18 +0000 Message-ID: From: John Dillon To: Gregory Maxwell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -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 X-Headers-End: 1UWf4i-00068Y-FH Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Service bits for pruned nodes 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: Mon, 29 Apr 2013 03:48:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, Apr 29, 2013 at 3:36 AM, Gregory Maxwell wrote= : > On Sun, Apr 28, 2013 at 7:57 PM, John Dillon > wrote: >> Have we considered just leaving that problem to a different protocol suc= h as >> BitTorrent? Offering up a few GB of storage capacity is a nice idea but = it >> means we would soon have to add structure to the network to allow nodes = to find >> each other to actually get that data. BitTorrent already has that issue = thought >> through carefully with it's DHT support. > > I think this is not a great idea on a couple levels=97 > > Least importantly, our own experience with tracker-less torrents on > the bootstrap files that they don't work very well in practice=97 and > thats without someone trying to DOS attack it. Unfortunate. What makes them not work out? DHT torrents seem pretty popular= . > More importantly, I think it's very important that the process of > offering up more storage not take any more steps. The software could > have user overridable defaults based on free disk space to make > contributing painless. This isn't possible if it takes extra software, > requires opening additional ports.. etc. Also means that someone > would have to be constantly creating new torrents, there would be > issues with people only seeding the old ones, etc. Now don't get me wrong, I'm not proposing we do this if it requires additio= nal steps or other software. I only mean if it is possible in an easy way to integrate the BitTorrent technology into Bitcoin in an automatic fashion. Y= es part of that may have to be finding a way to re-use the existing port for instance. > We already have to worry about nodes finding each other just for basic > operation. The only addition this requires is being able to advertise > what parts of the chain they have. Sure I guess my concern is more how do you find the specific part of the ch= ian you need without some structure to the network? Although I guess it may be enough to just add that structure or depend on just walking the nodes advertising themselves until you find what you want. We can build this stuff incrementally I'll agree. It won't be the case that= one in a thousand nodes serve up the part of the chain you need overnight. So m= any I am over engineering the solution with BitTorrent. > Using Bitcoin to bootstrap the Bittorrent DHT would probably make it > more reliable, but then again it might cause commercial services that > are in the business of poisoning the bittorrent DHT to target the > Bitcoin network. Good point. Sadly one that may apply to the Tor network too in the future. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJRfe1LAAoJEEWCsU4mNhiPuDgIAM1zz+ohlHgz37RgToQhInRc 1tv4Fnb6uGWyb4+U6UpK24LlXMFvOJsLm2czgbBc1Iz4z4wvb1m5IGw0ubJuV4mT GPUJhM4sNqfeKZlSWRw4Gia6Vk1jTkue+uVYvZn2vBS4SS6vYhYCC3zXIITyb2mp 7CVjcM84bTHKxIaMW1rIgmVJmfslsFdeNOp/cDVvkNl9+WvzWPeJ32BkT522p+pT AcPVFMsEJirYrXYi8HwdtGSeiG+mv0IemTAObJNPRrpw3x04ja6qecqzM51AkQ4t hPems5ShXM9FyDKFQNmtoC6ULpbd3CBBjsiQj0pp55epy6UC0eiUIXP8L9v0giM=3D =3DAOj8 -----END PGP SIGNATURE-----