summaryrefslogtreecommitdiff
path: root/2a/bab520349612b18181bee8209b8dd680cd244e
blob: 6f71bdf943958e3a405e8d0303bc272bbbf77ca2 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
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 <john.dillon892@googlemail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAAS2fgRR3K_dVMhOSHpga91tFaK7G99ouKLFpXHbgxEsvY+_Wg@mail.gmail.com>
References: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
	<CANEZrP3FA-5z3gAC1aYbG2EOKM2eDyv7zX3S9+ia2ZJ0LPkKiA@mail.gmail.com>
	<CAAS2fgSo6Ua8giSKhYTjGm=2U1nBjprHOBqCL7dSNr9MQX_6tw@mail.gmail.com>
	<CAPaL=UUhrb+4CANVB6refCOeQwcf_A80Way_C_oJbDKM9kmWXg@mail.gmail.com>
	<CAAS2fgRR3K_dVMhOSHpga91tFaK7G99ouKLFpXHbgxEsvY+_Wg@mail.gmail.com>
Date: Mon, 29 Apr 2013 03:48:18 +0000
Message-ID: <CAPaL=UU8=EzhAni+rRtro4QZdgreUSJxeMpqJai19kGZ9JHTyg@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <gmaxwell@gmail.com> wrote=
:
> On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
> <john.dillon892@googlemail.com> 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-----