diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7442d57d8e..4d17b5f561 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -50,12 +50,12 @@ Pull Request Philosophy Patchsets should always be focused. For example, a pull request could add a feature, fix a bug, or refactor code; but not a mixture. Please also avoid super pull requests which attempt to do too much, are overly large, or overly complex as this makes review difficult. -###Features +### Features When adding a new feature, thought must be given to the long term technical debt and maintenance that feature may require after inclusion. Before proposing a new feature that will require maintenance, please consider if you are willing to maintain it (including bug fixing). If features get orphaned with no maintainer in the future, they may be removed by the Repository Maintainer. -###Refactoring +### Refactoring Refactoring is a necessary part of any software project's evolution. The following guidelines cover refactoring pull requests for the project. @@ -85,7 +85,7 @@ In general, all pull requests must: 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 Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Project maintainers take into account the peer review when determining if there is consensus to merge a pull request (remember that discussions may have been spread out over github, mailing list and IRC discussions). The following language is used within pull-request comments: diff --git a/doc/REST-interface.md b/doc/REST-interface.md index bf669235e3..4323ba2b8b 100644 --- a/doc/REST-interface.md +++ b/doc/REST-interface.md @@ -6,14 +6,14 @@ The REST API can be enabled with the `-rest` option. Supported API ------------- -####Transactions +#### Transactions `GET /rest/tx/.` Given a transaction hash: returns a transaction in binary, hex-encoded binary, or JSON formats. For full TX query capability, one must enable the transaction index via "txindex=1" command line / configuration option. -####Blocks +#### Blocks `GET /rest/block/.` `GET /rest/block/notxdetails/.` @@ -23,12 +23,12 @@ The HTTP request and response are both handled entirely in-memory, thus making m With the /notxdetails/ option JSON response will only contain the transaction hash instead of the complete transaction details. The option only affects the JSON response. -####Blockheaders +#### Blockheaders `GET /rest/headers//.` Given a block hash: returns amount of blockheaders in upward direction. -####Chaininfos +#### Chaininfos `GET /rest/chaininfo.json` Returns various state info regarding block chain processing. @@ -44,7 +44,7 @@ Only supports JSON as output format. * pruneheight : (numeric) heighest block available * softforks : (array) status of softforks in progress -####Query UTXO set +#### Query UTXO set `GET /rest/getutxos//-/-/.../-.` The getutxo command allows querying of the UTXO set given a set of outpoints. @@ -77,7 +77,7 @@ $ curl localhost:18332/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff76 } ``` -####Memory pool +#### Memory pool `GET /rest/mempool/info.json` Returns various information about the TX mempool. diff --git a/doc/guide-startmany.md b/doc/guide-startmany.md index 18adac571c..e38e34a873 100644 --- a/doc/guide-startmany.md +++ b/doc/guide-startmany.md @@ -1,4 +1,4 @@ -#start-many Setup Guide +# start-many Setup Guide ## Two Options for Setting up your Wallet There are many ways to setup a wallet to support start-many. This guide will walk through two of them. @@ -176,4 +176,4 @@ Command output should have "_Masternode successfully started_" in its `status` f Search your Masternodes on https://dashninja.pl/masternodes.html -_Hint: Bookmark it, you definitely will be using this site a lot._ \ No newline at end of file +_Hint: Bookmark it, you definitely will be using this site a lot._ diff --git a/doc/instantsend.md b/doc/instantsend.md index be24464417..a216d16d61 100644 --- a/doc/instantsend.md +++ b/doc/instantsend.md @@ -1,10 +1,10 @@ -##InstantSend Technical Information +## InstantSend Technical Information InstantSend has been integrated into the Core Daemon in two ways: * "push" notifications (ZMQ and `-instantsendnotify` cmd-line/config option); * RPC commands. -####ZMQ +#### ZMQ When a "Transaction Lock" occurs the hash of the related transaction is broadcasted through ZMQ using both the `zmqpubrawtxlock` and `zmqpubhashtxlock` channels. @@ -15,7 +15,7 @@ This mechanism has been integrated into Bitcore-Node-Dash which allows for notif * WebSocket: [https://github.com/dashpay/insight-api-dash#web-socket-api](https://github.com/dashpay/insight-api-dash#web-socket-api) * API: [https://github.com/dashpay/insight-api-dash#instantsend-transactions](https://github.com/dashpay/insight-api-dash#instantsend-transactions) -####Command line option +#### Command line option When a wallet InstantSend transaction is successfully locked a shell command provided in this option is executed (`%s` in `` is replaced by TxID): @@ -23,7 +23,7 @@ When a wallet InstantSend transaction is successfully locked a shell command pro -instantsendnotify= ``` -####RPC +#### RPC Details pertaining to an observed "Transaction Lock" can also be retrieved through RPC, it’s important however to understand the underlying mechanism. diff --git a/doc/keepass.md b/doc/keepass.md index 6b9756f77e..257e4b4e06 100644 --- a/doc/keepass.md +++ b/doc/keepass.md @@ -1,4 +1,4 @@ -###What is it about### +### What is it about More info regarding KeePass: http://keepass.info/ @@ -10,7 +10,7 @@ The implementation is dependent on the following: - OpenSSL for base64 encoding. regular util.h libraries were not used for base64 encoding/decoding since they do not use secure allocation. - JSON Spirit for reading / writing RPC communications -###What's new### +### What's new The following new options are available for dashd and dash-qt: - _-keepass_ Use KeePass 2 integration using KeePassHttp plugin (default: 0) @@ -25,7 +25,7 @@ The following rpc commands are available: - _keepass init_: sets up the association between dashd and keepass by generating an AES key and sending an association message to KeePassHttp. This will trigger KeePass to ask for an Id for the association. Returns the association and the base64 encoded string for the AES key. - _keepass setpassphrase_: updates the passphrase in KeePassHttp to a new value. This should match the passphrase you intend to use for the wallet. Please note that the standard RPC commands _walletpassphrasechange_ and the wallet encrption from the QT GUI already send the updates to KeePassHttp, so this is only necessary for manual manipulation of the password. -###How to setup### +### How to setup Sample initialization flow from _dash-qt_ console (this needs to be done only once to set up the association): diff --git a/doc/release-process.md b/doc/release-process.md index d229cf7e29..9f26eb59ca 100644 --- a/doc/release-process.md +++ b/doc/release-process.md @@ -6,7 +6,7 @@ Release Process * * * -###First time / New builders +### First time / New builders Check out the source code in the following directory hierarchy. cd /path/to/your/toplevel/build @@ -15,7 +15,7 @@ Check out the source code in the following directory hierarchy. git clone https://github.com/devrandom/gitian-builder.git git clone https://github.com/dashpay/dash.git -###Dash Core maintainers/release engineers, update (commit) version in sources +### Dash Core maintainers/release engineers, update (commit) version in sources pushd ./dash contrib/verifysfbinaries/verify.sh @@ -36,7 +36,7 @@ Check out the source code in the following directory hierarchy. * * * -###Setup and perform Gitian builds +### Setup and perform Gitian builds Setup Gitian descriptors: @@ -58,7 +58,7 @@ Check out the source code in the following directory hierarchy. pushd ./gitian-builder git pull -###Fetch and create inputs: (first time, or when dependency versions change) +### Fetch and create inputs: (first time, or when dependency versions change) mkdir -p inputs wget -P inputs https://bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch @@ -72,7 +72,7 @@ Check out the source code in the following directory hierarchy. tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.9.sdk.tar.gz MacOSX10.9.sdk -###Optional: Seed the Gitian sources cache and offline git repositories +### Optional: Seed the Gitian sources cache and offline git repositories By default, Gitian will fetch source files as needed. To cache them ahead of time: @@ -86,7 +86,7 @@ NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from ``` The gbuild invocations below DO NOT DO THIS by default. -###Build and sign Dash Core for Linux, Windows, and OS X: +### Build and sign Dash Core for Linux, Windows, and OS X: ./bin/gbuild --commit dash=v${VERSION} ../dash/contrib/gitian-descriptors/gitian-linux.yml ./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../dash/contrib/gitian-descriptors/gitian-linux.yml @@ -111,7 +111,7 @@ The gbuild invocations below DO NOT DO THIS by default. 4. OS X unsigned installer and dist tarball (dash-${VERSION}-osx-unsigned.dmg, dash-${VERSION}-osx64.tar.gz) 5. Gitian signatures (in gitian.sigs/${VERSION}-/(your Gitian key)/ -###Verify other gitian builders signatures to your own. (Optional) +### Verify other gitian builders signatures to your own. (Optional) Add other gitian builders keys to your gpg keyring @@ -125,7 +125,7 @@ The gbuild invocations below DO NOT DO THIS by default. popd -###Next steps: +### Next steps: Commit your signature to gitian.sigs: