mirror of
https://github.com/dashpay/dash.git
synced 2024-12-24 11:32:46 +01:00
UdjinM6
Holger Schinzel
parent
8e560080a1
commit
a2c6140cb1
@ -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.
|
||||
|
||||
@ -67,9 +67,9 @@ Project maintainers aim for a quick turnaround on refactoring pull requests, so
|
||||
"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.
|
||||
|
||||
@ -82,7 +82,7 @@ In general, all pull requests must:
|
||||
- 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.
|
||||
|
||||
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
|
||||
@ -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 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
|
||||
--------------
|
||||
|
||||
The project leader is the release manager for each Bitcoin Core release.
|
||||
The project leader is the release manager for each Dash Core release.
|
||||
|
||||
@ -21,7 +21,7 @@ Construct a linear, no-fork, best version of the blockchain.
|
||||
|
||||
### [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) ###
|
||||
Utility to generate the pnSeed[] array that is compiled into the client.
|
||||
@ -46,7 +46,7 @@ Test and Verify Tools
|
||||
---------------------
|
||||
|
||||
### [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) ###
|
||||
These patches are applied when the automated pull-tester
|
||||
|
||||
@ -1 +1 @@
|
||||
{ CFBundleDisplayName = "Bitcoin Core"; CFBundleName = "Bitcoin Core"; }
|
||||
{ CFBundleDisplayName = "Dash Core"; CFBundleName = "Dash Core"; }
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
### 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.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
IF="eth0"
|
||||
#limit of the network interface in question
|
||||
LINKCEIL="1gbit"
|
||||
#limit outbound Bitcoin protocol traffic to this rate
|
||||
#limit outbound Dash protocol traffic to this rate
|
||||
LIMIT="160kbit"
|
||||
#defines the address space for which you wish to disable rate limiting
|
||||
LOCALNET="192.168.0.0/16"
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
# Helpful little script that spits out a comma-separated list of
|
||||
# language codes for Qt icons that should be included
|
||||
# in binary bitcoin distributions
|
||||
# in binary dash distributions
|
||||
|
||||
import glob
|
||||
import os
|
||||
|
||||
@ -152,7 +152,7 @@ def main():
|
||||
ips = [ip for ip in ips if PATTERN_AGENT.match(ip['agent'])]
|
||||
# Sort by availability (and use last success as tie breaker)
|
||||
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)
|
||||
# Look up ASNs and limit results, both per ASN and globally.
|
||||
ips = filterbyasn(ips, MAX_SEEDS_PER_ASN, NSEEDS)
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
### TestGen ###
|
||||
|
||||
Utilities to generate test vectors for the data-driven Bitcoin tests.
|
||||
Utilities to generate test vectors for the data-driven Dash tests.
|
||||
|
||||
Usage:
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ if [ -d "$1" ]; then
|
||||
cd "$1"
|
||||
else
|
||||
echo "Usage: $0 <datadir>" >&2
|
||||
echo "Removes obsolete Bitcoin database files" >&2
|
||||
echo "Removes obsolete Dash database files" >&2
|
||||
exit 1
|
||||
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
|
||||
0)
|
||||
echo "Error: no Bitcoin datadir detected."
|
||||
echo "Error: no Dash datadir detected."
|
||||
exit 1
|
||||
;;
|
||||
1)
|
||||
echo "Detected old Bitcoin datadir (before 0.7)."
|
||||
echo "Detected old Dash datadir (before 0.7)."
|
||||
echo "Nothing to do."
|
||||
exit 0
|
||||
;;
|
||||
2)
|
||||
echo "Detected Bitcoin 0.7 datadir."
|
||||
echo "Detected Dash 0.7 datadir."
|
||||
;;
|
||||
3)
|
||||
echo "Detected Bitcoin pre-0.8 datadir."
|
||||
echo "Detected Dash pre-0.8 datadir."
|
||||
;;
|
||||
4)
|
||||
echo "Detected Bitcoin 0.8 datadir."
|
||||
echo "Detected Dash 0.8 datadir."
|
||||
;;
|
||||
esac
|
||||
|
||||
|
||||
@ -12,9 +12,9 @@ For example:
|
||||
|
||||
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
|
||||
created. To use it for Bitcoin:
|
||||
created. To use it for Dash:
|
||||
|
||||
./configure --prefix=`pwd`/depends/x86_64-w64-mingw32
|
||||
|
||||
|
||||
@ -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,
|
||||
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:
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
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
|
||||
Windows. This is also used to build the release binaries.
|
||||
|
||||
@ -119,7 +119,7 @@ that run in -regtest mode.
|
||||
|
||||
**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
|
||||
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.
|
||||
@ -166,10 +166,12 @@ Threads
|
||||
|
||||
- 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).
|
||||
|
||||
- ThreadCheckDarkSendPool : Runs masternode list and sync data update loops
|
||||
|
||||
- Shutdown : Does an orderly shutdown of everything.
|
||||
|
||||
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
|
||||
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
|
||||
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`:
|
||||
@ -208,9 +210,9 @@ Development guidelines
|
||||
============================
|
||||
|
||||
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
|
||||
@ -321,7 +323,7 @@ Strings and formatting
|
||||
|
||||
- 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
|
||||
----------------------------
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
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.
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
to any third party.
|
||||
|
||||
@ -42,7 +42,7 @@ details of their operating practices.
|
||||
related to the DNS seed operation.
|
||||
|
||||
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
|
||||
[bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev).
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
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?
|
||||
------------------
|
||||
@ -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:
|
||||
|
||||
<message numerus="yes">
|
||||
<source>%n active connection(s) to Bitcoin network</source>
|
||||
<source>%n active connection(s) to Dash network</source>
|
||||
<translation>
|
||||
<numerusform>%n active connection to Bitcoin network</numerusform>
|
||||
<numerusform>%n active connections to Bitcoin network</numerusform>
|
||||
<numerusform>%n active connection to Dash network</numerusform>
|
||||
<numerusform>%n active connections to Dash network</numerusform>
|
||||
</translation>
|
||||
</message>
|
||||
|
||||
|
||||
@ -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
|
||||
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
|
||||
private keys or URLs. The travis client may be used to create these strings:
|
||||
|
||||
@ -66,8 +66,8 @@ address. The same address can be used in more than one notification.
|
||||
|
||||
For instance:
|
||||
|
||||
$ bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
|
||||
-zmqpubrawtx=ipc:///tmp/bitcoind.tx.raw
|
||||
$ dashd -zmqpubhashtx=tcp://127.0.0.1:28332 \
|
||||
-zmqpubrawtx=ipc:///tmp/dashd.tx.raw
|
||||
|
||||
Each PUB notification has a topic and body, where the header
|
||||
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
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
No authentication or authorization is done on connecting clients; it
|
||||
|
||||
Loading…
Reference in New Issue
Block a user