more bitcoin -> dash

Closes #712
This commit is contained in:
UdjinM6 2016-03-06 18:26:01 +03:00 committed by Holger Schinzel
parent 8e560080a1
commit a2c6140cb1
17 changed files with 48 additions and 46 deletions

View File

@ -1,7 +1,7 @@
Contributing to Bitcoin Core Contributing to Dash Core
============================ ============================
The Bitcoin Core project operates an open contributor model where anyone is welcome to contribute towards development in the form of peer review, testing and patches. This document explains the practical process and guidelines for contributing. The Dash Core project operates an open contributor model where anyone is welcome to contribute towards development in the form of peer review, testing and patches. This document explains the practical process and guidelines for contributing.
Firstly in terms of structure, there is no particular concept of “Core developers” in the sense of privileged people. Open source often naturally revolves around meritocracy where longer term contributors gain more trust from the developer community. However, some hierarchy is necessary for practical purposes. As such there are repository “maintainers” who are responsible for merging pull requests as well as a “lead maintainer” who is responsible for the release cycle, overall merging, moderation and appointment of maintainers. Firstly in terms of structure, there is no particular concept of “Core developers” in the sense of privileged people. Open source often naturally revolves around meritocracy where longer term contributors gain more trust from the developer community. However, some hierarchy is necessary for practical purposes. As such there are repository “maintainers” who are responsible for merging pull requests as well as a “lead maintainer” who is responsible for the release cycle, overall merging, moderation and appointment of maintainers.
@ -67,9 +67,9 @@ Project maintainers aim for a quick turnaround on refactoring pull requests, so
"Decision Making" Process "Decision Making" Process
------------------------- -------------------------
The following applies to code changes to the Bitcoin Core project (and related projects such as libsecp256k1), and is not to be confused with overall Bitcoin Network Protocol consensus changes. The following applies to code changes to the Dash Core project (and related projects such as libsecp256k1), and is not to be confused with overall Dash Network Protocol consensus changes.
Whether a pull request is merged into Bitcoin Core rests with the project merge maintainers and ultimately the project lead. Whether a pull request is merged into Dash Core rests with the project merge maintainers and ultimately the project lead.
Maintainers will take into consideration if a patch is in line with the general principles of the project; meets the minimum standards for inclusion; and will judge the general consensus of contributors. Maintainers will take into consideration if a patch is in line with the general principles of the project; meets the minimum standards for inclusion; and will judge the general consensus of contributors.
@ -82,7 +82,7 @@ In general, all pull requests must:
- not break the existing test suite; - not break the existing test suite;
- where bugs are fixed, where possible, there should be unit tests demonstrating the bug and also proving the fix. This helps prevent regression. - where bugs are fixed, where possible, there should be unit tests demonstrating the bug and also proving the fix. This helps prevent regression.
Patches that change Bitcoin consensus rules are considerably more involved than normal because they affect the entire ecosystem and so must be preceded by extensive mailing list discussions and have a numbered BIP. While each case will be different, one should be prepared to expend more time and effort than for other kinds of patches because of increased peer review and consensus building requirements. Patches that change Dash consensus rules are considerably more involved than normal because they affect the entire ecosystem and so must be preceded by extensive mailing list discussions and have a numbered BIP. While each case will be different, one should be prepared to expend more time and effort than for other kinds of patches because of increased peer review and consensus building requirements.
###Peer Review ###Peer Review
@ -101,10 +101,10 @@ Project maintainers reserve the right to weigh the opinions of peer reviewers us
Where a patch set affects consensus critical code, the bar will be set much higher in terms of discussion and peer review requirements, keeping in mind that mistakes could be very costly to the wider community. This includes refactoring of consensus critical code. Where a patch set affects consensus critical code, the bar will be set much higher in terms of discussion and peer review requirements, keeping in mind that mistakes could be very costly to the wider community. This includes refactoring of consensus critical code.
Where a patch set proposes to change the Bitcoin consensus, it must have been discussed extensively on the mailing list and IRC, be accompanied by a widely discussed BIP and have a generally widely perceived technical consensus of being a worthwhile change based on the judgement of the maintainers. Where a patch set proposes to change the Dash consensus, it must have been discussed extensively on the mailing list and IRC, be accompanied by a widely discussed BIP and have a generally widely perceived technical consensus of being a worthwhile change based on the judgement of the maintainers.
Release Policy Release Policy
-------------- --------------
The project leader is the release manager for each Bitcoin Core release. The project leader is the release manager for each Dash Core release.

View File

@ -21,7 +21,7 @@ Construct a linear, no-fork, best version of the blockchain.
### [Qos](/contrib/qos) ### ### [Qos](/contrib/qos) ###
A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Bitcoin network. This means one can have an always-on dashd instance running, and another local dashd/dash-qt instance which connects to this node and receives blocks from it. A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Dash network. This means one can have an always-on dashd instance running, and another local dashd/dash-qt instance which connects to this node and receives blocks from it.
### [Seeds](/contrib/seeds) ### ### [Seeds](/contrib/seeds) ###
Utility to generate the pnSeed[] array that is compiled into the client. Utility to generate the pnSeed[] array that is compiled into the client.
@ -46,7 +46,7 @@ Test and Verify Tools
--------------------- ---------------------
### [TestGen](/contrib/testgen) ### ### [TestGen](/contrib/testgen) ###
Utilities to generate test vectors for the data-driven Bitcoin tests. Utilities to generate test vectors for the data-driven Dash tests.
### [Test Patches](/contrib/test-patches) ### ### [Test Patches](/contrib/test-patches) ###
These patches are applied when the automated pull-tester These patches are applied when the automated pull-tester

View File

@ -1 +1 @@
{ CFBundleDisplayName = "Bitcoin Core"; CFBundleName = "Bitcoin Core"; } { CFBundleDisplayName = "Dash Core"; CFBundleName = "Dash Core"; }

View File

@ -1,5 +1,5 @@
### Qos ### ### Qos ###
This is a Linux bash script that will set up tc to limit the outgoing bandwidth for connections to the Bitcoin network. It limits outbound TCP traffic with a source or destination port of 9999, but not if the destination IP is within a LAN (defined as 192.168.x.x). This is a Linux bash script that will set up tc to limit the outgoing bandwidth for connections to the Dash network. It limits outbound TCP traffic with a source or destination port of 9999, but not if the destination IP is within a LAN (defined as 192.168.x.x).
This means one can have an always-on bitcoind instance running, and another local bitcoind/bitcoin-qt instance which connects to this node and receives blocks from it. This means one can have an always-on bitcoind instance running, and another local bitcoind/bitcoin-qt instance which connects to this node and receives blocks from it.

View File

@ -2,7 +2,7 @@
IF="eth0" IF="eth0"
#limit of the network interface in question #limit of the network interface in question
LINKCEIL="1gbit" LINKCEIL="1gbit"
#limit outbound Bitcoin protocol traffic to this rate #limit outbound Dash protocol traffic to this rate
LIMIT="160kbit" LIMIT="160kbit"
#defines the address space for which you wish to disable rate limiting #defines the address space for which you wish to disable rate limiting
LOCALNET="192.168.0.0/16" LOCALNET="192.168.0.0/16"

View File

@ -2,7 +2,7 @@
# Helpful little script that spits out a comma-separated list of # Helpful little script that spits out a comma-separated list of
# language codes for Qt icons that should be included # language codes for Qt icons that should be included
# in binary bitcoin distributions # in binary dash distributions
import glob import glob
import os import os

View File

@ -152,7 +152,7 @@ def main():
ips = [ip for ip in ips if PATTERN_AGENT.match(ip['agent'])] ips = [ip for ip in ips if PATTERN_AGENT.match(ip['agent'])]
# Sort by availability (and use last success as tie breaker) # Sort by availability (and use last success as tie breaker)
ips.sort(key=lambda x: (x['uptime'], x['lastsuccess'], x['ip']), reverse=True) ips.sort(key=lambda x: (x['uptime'], x['lastsuccess'], x['ip']), reverse=True)
# Filter out hosts with multiple bitcoin ports, these are likely abusive # Filter out hosts with multiple ports, these are likely abusive
ips = filtermultiport(ips) ips = filtermultiport(ips)
# Look up ASNs and limit results, both per ASN and globally. # Look up ASNs and limit results, both per ASN and globally.
ips = filterbyasn(ips, MAX_SEEDS_PER_ASN, NSEEDS) ips = filterbyasn(ips, MAX_SEEDS_PER_ASN, NSEEDS)

View File

@ -1,6 +1,6 @@
### TestGen ### ### TestGen ###
Utilities to generate test vectors for the data-driven Bitcoin tests. Utilities to generate test vectors for the data-driven Dash tests.
Usage: Usage:

View File

@ -4,7 +4,7 @@ if [ -d "$1" ]; then
cd "$1" cd "$1"
else else
echo "Usage: $0 <datadir>" >&2 echo "Usage: $0 <datadir>" >&2
echo "Removes obsolete Bitcoin database files" >&2 echo "Removes obsolete Dash database files" >&2
exit 1 exit 1
fi fi
@ -16,22 +16,22 @@ if [ -f wallet.dat -a -f peers.dat -a -f chainstate/CURRENT -a -f blocks/index/C
case $LEVEL in case $LEVEL in
0) 0)
echo "Error: no Bitcoin datadir detected." echo "Error: no Dash datadir detected."
exit 1 exit 1
;; ;;
1) 1)
echo "Detected old Bitcoin datadir (before 0.7)." echo "Detected old Dash datadir (before 0.7)."
echo "Nothing to do." echo "Nothing to do."
exit 0 exit 0
;; ;;
2) 2)
echo "Detected Bitcoin 0.7 datadir." echo "Detected Dash 0.7 datadir."
;; ;;
3) 3)
echo "Detected Bitcoin pre-0.8 datadir." echo "Detected Dash pre-0.8 datadir."
;; ;;
4) 4)
echo "Detected Bitcoin 0.8 datadir." echo "Detected Dash 0.8 datadir."
;; ;;
esac esac

View File

@ -12,9 +12,9 @@ For example:
make HOST=x86_64-w64-mingw32 -j4 make HOST=x86_64-w64-mingw32 -j4
A prefix will be generated that's suitable for plugging into Bitcoin's A prefix will be generated that's suitable for plugging into Dash's
configure. In the above example, a dir named x86_64-w64-mingw32 will be configure. In the above example, a dir named x86_64-w64-mingw32 will be
created. To use it for Bitcoin: created. To use it for Dash:
./configure --prefix=`pwd`/depends/x86_64-w64-mingw32 ./configure --prefix=`pwd`/depends/x86_64-w64-mingw32

View File

@ -85,7 +85,7 @@ BerkeleyDB 5.1 or later, which break binary wallet compatibility with the distri
are based on BerkeleyDB 4.8. If you do not care about wallet compatibility, are based on BerkeleyDB 4.8. If you do not care about wallet compatibility,
pass `--with-incompatible-bdb` to configure. pass `--with-incompatible-bdb` to configure.
See the section "Disable-wallet mode" to build Bitcoin Core without wallet. See the section "Disable-wallet mode" to build Dash Core without wallet.
Optional: Optional:

View File

@ -1,7 +1,7 @@
WINDOWS BUILD NOTES WINDOWS BUILD NOTES
==================== ====================
Some notes on how to build Bitcoin Core for Windows. Some notes on how to build Dash Core for Windows.
Most developers use cross-compilation from Ubuntu to build executables for Most developers use cross-compilation from Ubuntu to build executables for
Windows. This is also used to build the release binaries. Windows. This is also used to build the release binaries.

View File

@ -119,7 +119,7 @@ that run in -regtest mode.
**DEBUG_LOCKORDER** **DEBUG_LOCKORDER**
Bitcoin Core is a multithreaded application, and deadlocks or other multithreading bugs Dash Core is a multithreaded application, and deadlocks or other multithreading bugs
can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure
CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of which locks CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of which locks
are held, and adds warnings to the debug.log file if inconsistencies are detected. are held, and adds warnings to the debug.log file if inconsistencies are detected.
@ -166,10 +166,12 @@ Threads
- ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used in 500ms. - ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used in 500ms.
- ThreadRPCServer : Remote procedure call handler, listens on port 8332 for connections and services them. - ThreadRPCServer : Remote procedure call handler, listens on port 9998 for connections and services them.
- BitcoinMiner : Generates bitcoins (if wallet is enabled). - BitcoinMiner : Generates bitcoins (if wallet is enabled).
- ThreadCheckDarkSendPool : Runs masternode list and sync data update loops
- Shutdown : Does an orderly shutdown of everything. - Shutdown : Does an orderly shutdown of everything.
Ignoring IDE/editor files Ignoring IDE/editor files
@ -178,7 +180,7 @@ Ignoring IDE/editor files
In closed-source environments in which everyone uses the same IDE it is common In closed-source environments in which everyone uses the same IDE it is common
to add temporary files it produces to the project-wide `.gitignore` file. to add temporary files it produces to the project-wide `.gitignore` file.
However, in open source software such as Bitcoin Core, where everyone uses However, in open source software such as Dash Core, where everyone uses
their own editors/IDE/tools, it is less common. Only you know what files your their own editors/IDE/tools, it is less common. Only you know what files your
editor produces and this may change from version to version. The canonical way editor produces and this may change from version to version. The canonical way
to do this is thus to create your local gitignore. Add this to `~/.gitconfig`: to do this is thus to create your local gitignore. Add this to `~/.gitconfig`:
@ -208,9 +210,9 @@ Development guidelines
============================ ============================
A few non-style-related recommendations for developers, as well as points to A few non-style-related recommendations for developers, as well as points to
pay attention to for reviewers of Bitcoin Core code. pay attention to for reviewers of Dash Core code.
General Bitcoin Core General Dash Core
---------------------- ----------------------
- New features should be exposed on RPC first, then can be made available in the GUI - New features should be exposed on RPC first, then can be made available in the GUI
@ -321,7 +323,7 @@ Strings and formatting
- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers - For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers
- *Rationale*: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion - *Rationale*: Dash Core uses tinyformat, which is type safe. Leave them out to avoid confusion
Threads and synchronization Threads and synchronization
---------------------------- ----------------------------

View File

@ -1,12 +1,12 @@
Expectations for DNS Seed operators Expectations for DNS Seed operators
==================================== ====================================
Bitcoin Core attempts to minimize the level of trust in DNS seeds, Dash Core attempts to minimize the level of trust in DNS seeds,
but DNS seeds still pose a small amount of risk for the network. but DNS seeds still pose a small amount of risk for the network.
As such, DNS seeds must be run by entities which have some minimum As such, DNS seeds must be run by entities which have some minimum
level of trust within the Bitcoin community. level of trust within the Dash community.
Other implementations of Bitcoin software may also use the same Other implementations of Dash software may also use the same
seeds and may be more exposed. In light of this exposure, this seeds and may be more exposed. In light of this exposure, this
document establishes some basic expectations for operating dnsseeds. document establishes some basic expectations for operating dnsseeds.
@ -16,7 +16,7 @@ and not sell or transfer control of the DNS seed. Any hosting services
contracted by the operator are equally expected to uphold these expectations. contracted by the operator are equally expected to uphold these expectations.
1. The DNS seed results must consist exclusively of fairly selected and 1. The DNS seed results must consist exclusively of fairly selected and
functioning Bitcoin nodes from the public network to the best of the functioning Dash nodes from the public network to the best of the
operator's understanding and capability. operator's understanding and capability.
2. For the avoidance of doubt, the results may be randomized but must not 2. For the avoidance of doubt, the results may be randomized but must not
@ -26,7 +26,7 @@ urgent technical necessity and disclosed.
3. The results may not be served with a DNS TTL of less than one minute. 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 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 for the operation of the service or urgent health of the Dash
network and must not be retained longer than necessary nor disclosed network and must not be retained longer than necessary nor disclosed
to any third party. to any third party.
@ -42,7 +42,7 @@ details of their operating practices.
related to the DNS seed operation. related to the DNS seed operation.
If these expectations cannot be satisfied the operator should If these expectations cannot be satisfied the operator should
discontinue providing services and contact the active Bitcoin discontinue providing services and contact the active Dash
Core development team as well as posting on Core development team as well as posting on
[bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev). [bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev).

View File

@ -1,7 +1,7 @@
Translation Strings Policy Translation Strings Policy
=========================== ===========================
This document provides guidelines for internationalization of the Bitcoin Core software. This document provides guidelines for internationalization of the Dash Core software.
How to translate? How to translate?
------------------ ------------------
@ -85,10 +85,10 @@ In Qt code use tr's third argument for optional plurality. For example:
This adds `<numerusform>`s to the respective `.ts` file, which can be translated separately depending on the language. In English, this is simply: This adds `<numerusform>`s to the respective `.ts` file, which can be translated separately depending on the language. In English, this is simply:
<message numerus="yes"> <message numerus="yes">
<source>%n active connection(s) to Bitcoin network</source> <source>%n active connection(s) to Dash network</source>
<translation> <translation>
<numerusform>%n active connection to Bitcoin network</numerusform> <numerusform>%n active connection to Dash network</numerusform>
<numerusform>%n active connections to Bitcoin network</numerusform> <numerusform>%n active connections to Dash network</numerusform>
</translation> </translation>
</message> </message>

View File

@ -29,7 +29,7 @@ trigger cache-invalidation and rebuilds as necessary.
These caches can be manually removed if necessary. This is one of the the very few These caches can be manually removed if necessary. This is one of the the very few
manual operations that is possible with Travis, and it can be done by the manual operations that is possible with Travis, and it can be done by the
Bitcoin Core committer via the Travis web interface. Dash Core committer via the Travis web interface.
In some cases, secure strings may be needed for hiding sensitive info such as In some cases, secure strings may be needed for hiding sensitive info such as
private keys or URLs. The travis client may be used to create these strings: private keys or URLs. The travis client may be used to create these strings:

View File

@ -66,8 +66,8 @@ address. The same address can be used in more than one notification.
For instance: For instance:
$ bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332 \ $ dashd -zmqpubhashtx=tcp://127.0.0.1:28332 \
-zmqpubrawtx=ipc:///tmp/bitcoind.tx.raw -zmqpubrawtx=ipc:///tmp/dashd.tx.raw
Each PUB notification has a topic and body, where the header Each PUB notification has a topic and body, where the header
corresponds to the notification type. For instance, for the corresponds to the notification type. For instance, for the
@ -87,9 +87,9 @@ arriving. Please see `contrib/zmq/zmq_sub.py` for a working example.
## Remarks ## Remarks
From the perspective of bitcoind, the ZeroMQ socket is write-only; PUB From the perspective of dashd, the ZeroMQ socket is write-only; PUB
sockets don't even have a read function. Thus, there is no state sockets don't even have a read function. Thus, there is no state
introduced into bitcoind directly. Furthermore, no information is introduced into dashd directly. Furthermore, no information is
broadcast that wasn't already received from the public P2P network. broadcast that wasn't already received from the public P2P network.
No authentication or authorization is done on connecting clients; it No authentication or authorization is done on connecting clients; it