dashpay · UdjinM6 · May 5, 2017 · May 3, 2017 · May 3, 2017 · May 3, 2017
diff --git 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
@@ -6,14 +6,14 @@ The REST API can be enabled with the `-rest` option.
 Supported API
 -------------
 
-####Transactions
+#### Transactions
 `GET /rest/tx/<TX-HASH>.<bin|hex|json>`
 
 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/<BLOCK-HASH>.<bin|hex|json>`
 `GET /rest/block/notxdetails/<BLOCK-HASH>.<bin|hex|json>`
 
@@ -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/<COUNT>/<BLOCK-HASH>.<bin|hex|json>`
 
 Given a block hash: returns <COUNT> 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/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>`
 
 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
@@ -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._
+_Hint: Bookmark it, you definitely will be using this site a lot._
diff --git 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,15 +15,15 @@ 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 `<cmd>` is replaced by TxID):
 
 ```
 -instantsendnotify=<cmd>
 ```
 
-####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
@@ -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
@@ -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 <b>DO NOT DO THIS</b> 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 <b>DO NOT DO THIS</b> 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}-<linux|{win,osx}-unsigned>/(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 <b>DO NOT DO THIS</b> by default.
 
 	popd
 
-###Next steps:
+### Next steps:
 
 Commit your signature to gitian.sigs: