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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1UWete-0001Tx-Dn
for bitcoin-development@lists.sourceforge.net;
Mon, 29 Apr 2013 03:36:58 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.49 as permitted sender)
client-ip=209.85.215.49; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f49.google.com;
Received: from mail-la0-f49.google.com ([209.85.215.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UWetd-0005X8-Dl
for bitcoin-development@lists.sourceforge.net;
Mon, 29 Apr 2013 03:36:58 +0000
Received: by mail-la0-f49.google.com with SMTP id fp13so2745771lab.8
for <bitcoin-development@lists.sourceforge.net>;
Sun, 28 Apr 2013 20:36:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.163.105 with SMTP id yh9mr872466lbb.63.1367206609941;
Sun, 28 Apr 2013 20:36:49 -0700 (PDT)
Received: by 10.112.6.193 with HTTP; Sun, 28 Apr 2013 20:36:49 -0700 (PDT)
In-Reply-To: <CAPaL=UUhrb+4CANVB6refCOeQwcf_A80Way_C_oJbDKM9kmWXg@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>
Date: Sun, 28 Apr 2013 20:36:49 -0700
Message-ID: <CAAS2fgRR3K_dVMhOSHpga91tFaK7G99ouKLFpXHbgxEsvY+_Wg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: John Dillon <john.dillon892@googlemail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1UWetd-0005X8-Dl
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:36:58 -0000
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 i=
t
> means we would soon have to add structure to the network to allow nodes t=
o find
> each other to actually get that data. BitTorrent already has that issue t=
hought
> through carefully with it's DHT support.
I think this is not a great idea on a couple levels=E2=80=94
Least importantly, our own experience with tracker-less torrents on
the bootstrap files that they don't work very well in practice=E2=80=94 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 cli=
ent,
> or just calling out to some library? We could still use the Bitcoin netwo=
rk 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.
|
