From: Gregory Maxwell <gmaxwell@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: kevin <bit.kevin@gmail•com>,
Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Policy for DNS seeds
Date: Mon, 21 Jul 2014 13:19:19 -0700 [thread overview]
Message-ID: <CAAS2fgQsq9AdAsZ09nbU9j2r=atL4KUuNNUYuc+ZTPKJLXScWQ@mail.gmail.com> (raw)
In-Reply-To: <20140721192401.GA16764@petertodd.org>
On Mon, Jul 21, 2014 at 12:24 PM, Peter Todd <pete@petertodd•org> wrote:
> Might be worthwhile to also write an "Expectations for DNSSeed users"
> outlining what security properties the seeds actually have, and what
> kind of attacks are possible.
Agreed. I've seen some amount of use of dnsseeds which I would
consider inadvisable considering their weakness.
> Many users would be better served with
> seeds that offer authenticated and encrypted connections to the seeds
> for instance. (esp. if they're using authed/encrypted connections to
> nodes, e.g. Tor hidden services)
Also agreed, we ought to have a separate onionseed process for hosts
which can reach hidden services which would be inherently
authenticated and somewhat more anonymous. The existing introduction
method already doesn't work well for onlynet=onion hosts, so that
would be a good place to start.
>> 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.
>
> Along the lines of my above point, for Bitcoin Core users of the
> DNSSeeds what constitutes a "functioning" Bitcoin node is much more
> broad than what other users might need.
I was deliberately vague here in that I'm trying to avoid foreclosing
reasonable activities like omitting nodes which are uselessly slow,
diverged from the network, or running very old software. The test I'm
suggesting is that if "why am I doing this" is "to connect users to
functioning nodes" then it's probably okay, but if its to achieve some
other end— probably not.
> Note that singling out a group of hosts to receive different results
> with DNS is especially difficult as you'll be usually singling out
> different ISP's rather than hosts themselves. That said if we ever start
> operating HTTPS or similar seeds this expectation will become even more
> relevant for them.
Yes, this is one of the reasons we use DNS (and also one of the
reasons the document suggests a non-zero minimum ttl)... but belt and
suspenders, even though technical measures are protective here it's
good to make it clear that this isn't acceptable.
> While there have been
> suggestions to use the testnet seeds for testing vulnerabilities, the
> public discussion clause should suffice to allow those exceptions.
Yep. That was the intent. (well not testnet, but the notion that if
there really were a good reason to do something else a discussion
should cover it)
prev parent reply other threads:[~2014-07-21 20:19 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
2014-07-21 19:24 ` Peter Todd
2014-07-21 20:19 ` Gregory Maxwell [this message]
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='CAAS2fgQsq9AdAsZ09nbU9j2r=atL4KUuNNUYuc+ZTPKJLXScWQ@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bit.kevin@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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