Go to file
Gregory Maxwell 50bd12ce0c Break addnode out from the outbound connection limits.
Previously addnodes were in competition with outbound connections
 for access to the eight outbound slots.

One result of this is that frequently a node with several addnode
 configured peers would end up connected to none of them, because
 while the addnode loop was in its two minute sleep the automatic
 connection logic would fill any free slots with random peers.
 This is particularly unwelcome to users trying to maintain links
 to specific nodes for fast block relay or purposes.

Another result is that a group of nine or more nodes which are
 have addnode configured towards each other can become partitioned
 from the public network.

This commit introduces a new limit of eight connections just for
 addnode peers which is not subject to any of the other connection
 limitations (including maxconnections).

The choice of eight is sufficient so that under no condition would
 a user find themselves connected to fewer addnoded peers than
 previously.  It is also low enough that users who are confused
 about the significance of more connections and have gotten too
 copy-and-paste happy will not consume more than twice the slot
 usage of a typical user.

Any additional load on the network resulting from this will likely
 be offset by a reduction in users applying even more wasteful
 workaround for the prior behavior.

The retry delays are reduced to avoid nodes sitting around without
 their added peers up, but are still sufficient to prevent overly
 aggressive repeated connections.  The reduced delays also make
 the system much more responsive to the addnode RPC.

Ban-disconnects are also exempted for peers added via addnode since
 the outbound addnode logic ignores bans.  Previously it would ban
 an addnode then immediately reconnect to it.

A minor change was also made to CSemaphoreGrant so that it is
 possible to re-acquire via an object whos grant was moved.
2017-01-05 19:02:09 +00:00
.github Mention reporting security issues responsibly 2016-11-10 14:41:40 +01:00
.tx qt: Set transifex slug to 0.14 2017-01-02 09:36:03 +01:00
build-aux/m4 [build-aux] Boost_Base serial 27 2016-10-17 11:43:24 +08:00
contrib Make linearize scripts Python 3-compatible. 2017-01-05 00:46:30 -08:00
depends [depends] Set OSX_MIN_VERSION to 10.8 2016-11-09 18:55:04 +08:00
doc [Doc] Install Protobuf v3 on OS X 2017-01-04 17:08:04 +08:00
qa add test for -walletrejectlongchains 2017-01-04 13:26:44 -05:00
share Increment MIT Licence copyright header year on files modified in 2016 2016-12-31 11:01:21 -07:00
src Break addnode out from the outbound connection limits. 2017-01-05 19:02:09 +00:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore gitignore: Wipe line after java comp tool removal 2016-12-20 22:59:08 +01:00
.travis.yml travis: make distdir 2016-12-20 22:54:13 +01:00
autogen.sh Add MIT license to autogen.sh and share/genbuild.sh 2016-09-21 23:01:36 +00:00
configure.ac Merge #9475: Let autoconf detect presence of EVP_MD_CTX_new 2017-01-05 10:28:47 +01:00
CONTRIBUTING.md Add copyright/patent issues to possible NACK reasons 2016-10-13 19:47:43 +02:00
COPYING Update license year range to 2016 2016-01-17 23:38:11 +05:30
INSTALL.md Update INSTALL landing redirection notice for build instructions. 2016-10-06 12:27:23 +13:00
libbitcoinconsensus.pc.in Unify package name to as few places as possible without major changes 2015-12-14 02:11:10 +00:00
Makefile.am build: Fix 'make deploy' for OSX 2016-12-23 09:48:52 +01:00
README.md Merge doc/unit-tests.md into src/test/README.md 2016-11-02 18:19:43 +01:00

Bitcoin Core integration/staging tree

Build Status

https://bitcoincore.org

What is Bitcoin?

Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

For more information, as well as an immediately useable, binary version of the Bitcoin Core software, see https://bitcoin.org/en/download, or read the original whitepaper.

License

Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is regularly built and tested, but is not guaranteed to be completely stable. Tags are created regularly to indicate new official, stable release versions of Bitcoin Core.

The contribution workflow is described in CONTRIBUTING.md.

The developer mailing list should be used to discuss complicated or controversial changes before working on a patch set.

Developer IRC can be found on Freenode at #bitcoin-core-dev.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests of the RPC interface, written in Python, that are run automatically on the build server. These tests can be run (if the test dependencies are installed) with: qa/pull-tester/rpc-tests.py

The Travis CI system makes sure that every pull request is built for Windows, Linux, and OS X, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.

Translators should also subscribe to the mailing list.