cd9c6994c2
* Initial devnet * Move genesis block adding into its own method * Introduce -allowprivatenet to lift limitation on RFC1918 addresses Normally, RFC1918 (192.168.x.x/10.x.x.x/...) addresses are not allowed to be relayed. Also, masternodes won't start when the address is considered invalid. This is needed to test local devnet or regtest based networks. * Lift the requirement of minimum MN age for regtest/devnet * Implement named devnets This allows the creation of multiple independent devnets. Each one is identified by a name which is hardened into a "devnet genesis" block, which is automatically positioned at height 1. Validation rules will ensure that a node from devnet=test1 never be able to accept blocks from devnet=test2. This is done by checking the expected devnet genesis block. The genesis block of the devnet is the same as the one from regtest. This starts the devnet with a very low difficulty, allowing us to fill up needed balances for masternodes very fast. Also, the devnet name is put into the sub-version of the VERSION message. If a node connects to the wrong network, it will immediately be disconnected. * Allow to select multiple addresses from the same group in devnet/regtest The selection code normally only allows to select addresses from the same group (e.g. 192.168.x.x) once. This results in connecting to only a single node in devnet/regtest. * Show the devnet name in the title bar and on the loading screen * Add AllowMultipleAddressesFromGroup to chainparams and use it in net.cpp * Remove unused/unneeded scripts from devnet geneses creation 1. OP_RETURN not needed in input script of devnet genesis 2. genesisOutputScript was unused * Fix copy/paste error in -allowprivatenet description * Improve -devnet parameter error handling - Only allow one of -devnet, -regtest or -testnet - Only allow -devnet=name to be specified once * Use different datadir for each devnet * Fix `devnet-devnet` issue * Fix devnet splashscreen (should use testnet img) * Avoid passing devNetName around (most of the time) * Remove nMaxTipAge from CDevNetParams Not present anymore after rebase on develop |
||
|---|---|---|
| .tx | ||
| build-aux/m4 | ||
| contrib | ||
| dash-docs | ||
| depends | ||
| doc | ||
| qa | ||
| share | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| autogen.sh | ||
| configure.ac | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| INSTALL | ||
| libdashconsensus.pc.in | ||
| Makefile.am | ||
| README.md | ||
Dash Core staging tree 0.12.2
master: 
develop: 
What is Dash?
Dash is an experimental new digital currency that enables anonymous, instant payments to anyone, anywhere in the world. Dash uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Dash Core is the name of the open source software which enables the use of this currency.
For more information, as well as an immediately useable, binary version of the Dash Core software, see https://www.dash.org/get-dash/.
License
Dash 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 meant to be stable. Development is normally done in separate branches.
Tags are created to indicate new official,
stable release versions of Dash Core.
The contribution workflow is described in CONTRIBUTING.md.
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
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 and Linux, OS X, and that unit and sanity tests are automatically run.
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 Dash 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 follow the forum.