From: Matt Corallo <bitcoin-list@bluematt•me>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Policy for DNS seeds
Date: Tue, 22 Jul 2014 20:01:45 +0000 [thread overview]
Message-ID: <53CEC329.1020405@bluematt.me> (raw)
In-Reply-To: <CALxbBHW1kf6gDoO22GETwb6kRJ92qxS6MSNx64+kT2TiwH5iTQ@mail.gmail.com>
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
>
next prev parent reply other threads:[~2014-07-22 21:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-21 13:43 Wladimir
2014-07-21 13:53 ` Christian Decker
2014-07-22 20:01 ` Matt Corallo [this message]
2014-07-21 19:24 ` Peter Todd
2014-07-21 20:19 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53CEC329.1020405@bluematt.me \
--to=bitcoin-list@bluematt$(echo .)me \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox