[Bitcoin-development] Policy for DNS seeds

2014-07-21 Thread Wladimir
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


Re: [Bitcoin-development] Policy for DNS seeds

2014-07-21 Thread Christian Decker
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 laa...@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


[Bitcoin-development] Question on creating test cases for block.CheckBlock()

2014-07-21 Thread Sergio Lerner
I'm working on a BIP which needs to modify the block acceptance rules. I
have two ways of testing:

- Mining blocks on the testnet
- Creating test cases for Bitcoin Core.

I want to create those test cases for block.CheckBlock(), which involves
verifying 100 dynamically generated blocks.
What is the state of the blockchain when a test case is executed ? Is is
configured for the regtest, testnet3 or mainnet? What blocks are in the
blockchain? Only the genesis block?

checkblock_tests.cpp seems to be the only test case for CheckBlock() and
it assumes the mainnet is configured.
I need to use the regtest so I can create blocks of difficulty 1.

Best regards and thank you in advance,


--
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


Re: [Bitcoin-development] Policy for DNS seeds

2014-07-21 Thread Gregory Maxwell
On Mon, Jul 21, 2014 at 12:24 PM, Peter Todd p...@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)

--
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