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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1X9hjm-0000eC-DY
for bitcoin-development@lists.sourceforge.net;
Tue, 22 Jul 2014 21:36:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
designates 192.241.179.72 as permitted sender)
client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
helo=mail.bluematt.me;
Received: from mail.bluematt.me ([192.241.179.72])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1X9hjk-0001Hy-U9
for bitcoin-development@lists.sourceforge.net;
Tue, 22 Jul 2014 21:36:42 +0000
Received: from [10.232.240.17] (unknown [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id AD93F4D26B
for <bitcoin-development@lists.sourceforge.net>;
Tue, 22 Jul 2014 20:02:07 +0000 (UTC)
Message-ID: <53CEC329.1020405@bluematt.me>
Date: Tue, 22 Jul 2014 20:01:45 +0000
From: Matt Corallo <bitcoin-list@bluematt.me>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CA+s+GJA1aLqOamoYTHRNsF3bGb=pKwNHXGYzQ6GSTgQnic+yCA@mail.gmail.com>
<CALxbBHW1kf6gDoO22GETwb6kRJ92qxS6MSNx64+kT2TiwH5iTQ@mail.gmail.com>
In-Reply-To: <CALxbBHW1kf6gDoO22GETwb6kRJ92qxS6MSNx64+kT2TiwH5iTQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.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
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information
X-Headers-End: 1X9hjk-0001Hy-U9
Subject: Re: [Bitcoin-development] Policy for DNS seeds
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, 22 Jul 2014 21:36:42 -0000
Absolutely not. Time and time again we've seen "anonymized" data sets
that dont work out so well. I'm sure its possible to do but there are
too many factors and we dont want to succumb to this.
Also, these generally look good (and essentially the same as what had
been a gentleman's agreement for those who read IRC actively, the
purpose of codifying this is essentially that we ended up adding a lot
of DNS Seeds run by people who dont follow development closely and/or
are not aware of the issues involved).
Thanks for writing this up,
Matt
On 07/21/14 13:53, Christian Decker wrote:
> How about research projects into node distribution? Specifically I
> wonder whether the collection and analysis of DNS query origin is
> allowed when queries are anonymized and aggregated. This would prevent
> the identification of a single user, which I assume is the rationale
> for point 4.
>
> Other than that I'm perfectly fine with accepting the rules for
> seed.bitcoinstats.com
>
> Regards,
> Christian
> --
> Christian Decker
>
>
> On Mon, Jul 21, 2014 at 2:43 PM, Wladimir <laanwj@gmail.com> wrote:
>> We've established a few basic rules for the DNS seeds as used in the
>> Bitcoin Core software. See below.
>>
>> If you run one of the DNS seeds please reply to this and let us know
>> whether you agree to these terms. if you think some requirements are
>> unreasonable let us know too. If we haven't heard from you by
>> 2014-08-04 we will remove your DNS seed from the list of defaults.
>>
>> Expectations for DNSSeed operators
>> ====================================
>>
>> Bitcoin Core attempts to minimize the level of trust in DNS seeds,
>> but DNS seeds still pose a small amount of risk for the network.
>> Other implementations of Bitcoin software may also use the same
>> seeds and may be more exposed. In light of this exposure this
>> document establishes some basic expectations for the expectations
>> for the operation of dnsseeds.
>>
>> 0. A DNSseed operating organization or person is expected
>> to follow good host security practices and maintain control of
>> their serving infrastructure and not sell or transfer control of their
>> infrastructure. Any hosting services contracted by the operator are
>> equally expected to uphold these expectations.
>>
>> 1. The DNSseed results must consist exclusively of fairly selected and
>> functioning Bitcoin nodes from the public network to the best of the
>> operators understanding and capability.
>>
>> 2. For the avoidance of doubt, the results may be randomized but must not
>> single-out any group of hosts to receive different results unless due to an
>> urgent technical necessity and disclosed.
>>
>> 3. The results may not be served with a DNS TTL of less than one minute.
>>
>> 4. Any logging of DNS queries should be only that which is necessary
>> for the operation of the service or urgent health of the Bitcoin
>> network and must not be retained longer than necessary or disclosed
>> to any third party.
>>
>> 5. Information gathered as a result of the operators node-spidering
>> (not from DNS queries) may be freely published or retained, but only
>> if this data was not made more complete by biasing node connectivity
>> (a violation of expectation (1)).
>>
>> 6. Operators are encouraged, but not required, to publicly document
>> the details of their operating practices.
>>
>> 7. A reachable email contact address must be published for inquiries
>> related to the DNSseed operation.
>>
>> If these expectations cannot be satisfied the operator should
>> discontinue providing services and contact the active Bitcoin
>> Core development team as well as posting on bitcoin-development.
>>
>> Behavior outside of these expectations may be reasonable in some
>> situations but should be discussed in public in advance.
>>
>> ========
>>
>> See
>> https://github.com/bitcoin/bitcoin/pull/4566
>>
>> Wladimir
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
