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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <robbak@robbak.com>) id 1UWf4K-0001rY-3l
for bitcoin-development@lists.sourceforge.net;
Mon, 29 Apr 2013 03:48:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of robbak.com
designates 74.125.82.177 as permitted sender)
client-ip=74.125.82.177; envelope-from=robbak@robbak.com;
helo=mail-we0-f177.google.com;
Received: from mail-we0-f177.google.com ([74.125.82.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UWf4I-0004ad-SC
for bitcoin-development@lists.sourceforge.net;
Mon, 29 Apr 2013 03:48:00 +0000
Received: by mail-we0-f177.google.com with SMTP id s47so4177740wey.8
for <bitcoin-development@lists.sourceforge.net>;
Sun, 28 Apr 2013 20:47:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-received:in-reply-to:references:date:message-id
:subject:from:to:content-type:x-gm-message-state;
bh=GL1j5lyKrhMsUORh2x/svfM0vi4BrjFxWLQ0GeIhgSI=;
b=fW4FUnKZjX6D2YyrCTPo1w02TnqASeNGaRGqfVD7HrjkrobyxN8jHDELX1HNovpYa/
zyrMT/+sy/3xOYKOW0k9PwYiwndkTwuBLHolt2bVYS/gZB4UKq9UGSPTKCM2Z57p2Qx7
uPfAgtyv3d8gvtnzFSwIH/yIvbe+moSF9spZ4Nxl5l65joA9qGe+QPCGj19jBacRBOki
cZCDi/ZbBNyDu3HzoUTZcwffAwDZd3NF5TjVz+mkOokMvwDMutM4CnADGzfZ+djHNBYk
GaMyRNXdGamw5h2AkJdVY7FQBcpaQLWMWT+nENZBOCkwZiWv5VDbOmy5gxacUhErtApT
82ew==
MIME-Version: 1.0
X-Received: by 10.180.183.50 with SMTP id ej18mr14738126wic.4.1367206966602;
Sun, 28 Apr 2013 20:42:46 -0700 (PDT)
Received: by 10.194.80.169 with HTTP; Sun, 28 Apr 2013 20:42:46 -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 13:42:46 +1000
Message-ID: <CA+i0-i-WxkKU3U9LKpVR57JsCZ4_-hX1XpAgNt_w_2Pb1kVDEg@mail.gmail.com>
From: Robert Backhaus <robbak@robbak.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c353a2943d2604db77ad22
X-Gm-Message-State: ALoCoQlMgmzK2ZyddZfF1udHEP5FQZecChIFi6GnHBLRT8Xi/ALsl/vNHft7LDU1cdS9/kXs7Jzx
X-Spam-Score: -0.5 (/)
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
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1UWf4I-0004ad-SC
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:00 -0000
--001a11c353a2943d2604db77ad22
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
While I like the idea of a client using a DHT blockchain or UTXO list, I
don't think that the reference client is the place for it. But it would
make for a very interesting experimental project!
On 29 April 2013 13:36, 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
> such 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.
>
> 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.
>
> It's also the case that bittorrent is blocked on many networks and is
> confused with illicit copying. We would have the same problems with
> that that we had with IRC being confused with botnets.
>
> 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.
>
> > What are the logistics of either integrating a DHT capable BitTorrent
> client,
> > or just calling out to some library? We could still use the Bitcoin
> network to
> > bootstrap the BitTorrent DHT.
>
> 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.
>
> Integration also brings up the question of network exposed attack surface=
.
>
> Seems like it would be more work than just adding the ability to add
> ranges to address messages. I think we already want to revise the
> address message format in order to have signed flags and to support
> I2P peers.
>
>
> -------------------------------------------------------------------------=
-----
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring servi=
ce
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_ap=
r
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c353a2943d2604db77ad22
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">While I like the idea of a client using a DHT blockchain o=
r UTXO list, I don't think that the reference client is the place for i=
t. But it would make for a very interesting experimental project!</div><div=
class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On 29 April 2013 13:36, Gregory Maxwell =
<span dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blan=
k">gmaxwell@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div class=3D"im">On Sun, Apr 28, 2013 at 7:57 PM, John Dillon<br>
<<a href=3D"mailto:john.dillon892@googlemail.com">john.dillon892@googlem=
ail.com</a>> wrote:<br>
> Have we considered just leaving that problem to a different protocol s=
uch as<br>
> BitTorrent? Offering up a few GB of storage capacity is a nice idea bu=
t it<br>
> means we would soon have to add structure to the network to allow node=
s to find<br>
> each other to actually get that data. BitTorrent already has that issu=
e thought<br>
> through carefully with it's DHT support.<br>
<br>
</div>I think this is not a great idea on a couple levels=97<br>
<br>
Least importantly, our own experience with tracker-less torrents on<br>
the bootstrap files that they don't work very well in practice=97 and<b=
r>
thats without someone trying to DOS attack it.<br>
<br>
More importantly, I think it's very important that the process of<br>
offering up more storage not take any more steps. The software could<br>
have user overridable defaults based on free disk space to make<br>
contributing painless. This isn't possible if it takes extra software,<=
br>
requires opening additional ports.. etc. =A0Also means that someone<br>
would have to be constantly creating new torrents, there would be<br>
issues with people only seeding the old ones, etc.<br>
<br>
It's also the case that bittorrent is blocked on many networks and is<b=
r>
confused with illicit copying. We would have the same problems with<br>
that that we had with IRC being confused with botnets.<br>
<br>
We already have to worry about nodes finding each other just for basic<br>
operation. The only addition this requires is being able to advertise<br>
what parts of the chain they have.<br>
<div class=3D"im"><br>
> What are the logistics of either integrating a DHT capable BitTorrent =
client,<br>
> or just calling out to some library? We could still use the Bitcoin ne=
twork to<br>
> bootstrap the BitTorrent DHT.<br>
<br>
</div>Using Bitcoin to bootstrap the Bittorrent DHT would probably make it<=
br>
more reliable, but then again it might cause commercial services that<br>
are in the business of poisoning the bittorrent DHT to target the<br>
Bitcoin network.<br>
<br>
Integration also brings up the question of network exposed attack surface.<=
br>
<br>
Seems like it would be more work than just adding the ability to add<br>
ranges to address messages. I think we already want to revise the<br>
address message format in order to have signed flags and to support<br>
I2P peers.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Try New Relic Now & We'll Send You this Cool Shirt<br>
New Relic is the only SaaS-based application performance monitoring service=
<br>
that delivers powerful full stack analytics. Optimize and monitor your<br>
browser, app, & servers with just a few lines of code. Try New Relic<br=
>
and get this awesome Nerd Life shirt! <a href=3D"http://p.sf.net/sfu/newrel=
ic_d2d_apr" target=3D"_blank">http://p.sf.net/sfu/newrelic_d2d_apr</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--001a11c353a2943d2604db77ad22--
|
