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
|
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 <grarpamp@gmail.com>) id 1Rs8wF-0001dX-Dq
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 08:19:39 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=grarpamp@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rs8wA-0005X2-1b
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 08:19:39 +0000
Received: by werc1 with SMTP id c1so157978wer.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 31 Jan 2012 00:19:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.138.149 with SMTP id a21mr583197wej.0.1327997967963; Tue,
31 Jan 2012 00:19:27 -0800 (PST)
Received: by 10.180.103.227 with HTTP; Tue, 31 Jan 2012 00:19:27 -0800 (PST)
In-Reply-To: <CAAS2fgRPj29FSBcC_RQbufSC5tPhnZjguUQVAaWOn2VN6DZR1A@mail.gmail.com>
References: <CAPg+sBjNTS3n8Q3XzZi5GpBL6k_-4AxRKr0BkWa=-AAVgqS=2Q@mail.gmail.com>
<CAFHuXub52Lu4T0mCWoPoCrHGhCXyLpmEpSWn32_PZPjaRGL2LQ@mail.gmail.com>
<CABsx9T0avsrL3134WaA3boG-cdx2NcgEH1mQG7Cef78ZV5UNkw@mail.gmail.com>
<CAAS2fgRPj29FSBcC_RQbufSC5tPhnZjguUQVAaWOn2VN6DZR1A@mail.gmail.com>
Date: Tue, 31 Jan 2012 03:19:27 -0500
Message-ID: <CAD2Ti2_U2X47mwouZw085mncb8vBJ7x9Tr3-f8soot2foUp5cA@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.9 (/)
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
(grarpamp[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
0.7 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rs8wA-0005X2-1b
Subject: Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager
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: Tue, 31 Jan 2012 08:19:39 -0000
> I think it's important that we have more mechanisms then just DNS and
> hardcoded seednodes.
> This is important because the mechanisms we have are all pretty
> subject to blocking. Now=E2=80=94 before you say it=E2=80=94 Bitcoin isn'=
t intended to
> be blocking resistant (combine it with Tor and Tor anti-censorship
> tools)
> Is the fact that users can addnodes / addr.txt enough of an
> alternative to address this?
Perhaps not worry about removing it too much. As above, if blocking
or other issues arise, people will be hosting manual lists and nodes
on hidden sites... Tor/I2P/etc. The nodes are already there.
For that matter, since the nodes are talking once seeded, why not
deploy a DHT and be done. All you'd need is one friendly node and
the list comes in and maintains itself through node expiry rules.
Your node publishes its hello for others to discover, etc.
IRC, DNS, etc would go away in favor of autonomy. It wouldn't
be any more resistant. But if people wanted that, some form of
signatures from the hidden nodes would do... if you trusted them.
Booting and running is easy, trust isn't (ask the Tor/I2P people).
|
