sikkienl/dash
1
0
Fork 0
mirror of https://github.com/dashpay/dash.git synced 2024-12-24 19:42:46 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Doc: fix broken formatting in markdown #headers (#1462)

Browse Source 
* Doc: fix broken formatting in markdown #headers

Insert a space in markdown headers between the #'s and the header text.
(It appears that the space is required since a github update a year ago
https://github.com/blog/2100-github-pages-now-faster-and-simpler-with-jekyll-3-0)

* Update REST-interface.md

* Update guide-startmany.md

* Update instantsend.md

* Update keepass.md

* Update release-process.md
This commit is contained in:
Will Wray 2017-05-05 07:28:08 -04:00 committed by UdjinM6
parent 39750439bf
commit 82a4643135
6 changed files with 26 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
CONTRIBUTING.md
View File

@ -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. 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. 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. 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. 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: 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:

12
doc/REST-interface.md
View File

@ -6,14 +6,14 @@ The REST API can be enabled with the `-rest` option.
Supported API Supported API
------------- -------------
####Transactions #### Transactions
`GET /rest/tx/<TX-HASH>.<bin|hex|json>` `GET /rest/tx/<TX-HASH>.<bin|hex|json>`
Given a transaction hash: returns a transaction in binary, hex-encoded binary, or JSON formats. 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. 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/<BLOCK-HASH>.<bin|hex|json>`
`GET /rest/block/notxdetails/<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. 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>` `GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>`
Given a block hash: returns <COUNT> amount of blockheaders in upward direction. Given a block hash: returns <COUNT> amount of blockheaders in upward direction.
####Chaininfos #### Chaininfos
`GET /rest/chaininfo.json` `GET /rest/chaininfo.json`
Returns various state info regarding block chain processing. Returns various state info regarding block chain processing.
@ -44,7 +44,7 @@ Only supports JSON as output format.
* pruneheight : (numeric) heighest block available * pruneheight : (numeric) heighest block available
* softforks : (array) status of softforks in progress * 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>` `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. 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` `GET /rest/mempool/info.json`
Returns various information about the TX mempool. Returns various information about the TX mempool.

4
doc/guide-startmany.md
View File

@ -1,4 +1,4 @@
#start-many Setup Guide # start-many Setup Guide
## Two Options for Setting up your Wallet ## 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. 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 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._

8
doc/instantsend.md
View File

@ -1,10 +1,10 @@
##InstantSend Technical Information ## InstantSend Technical Information
InstantSend has been integrated into the Core Daemon in two ways: InstantSend has been integrated into the Core Daemon in two ways:
* "push" notifications (ZMQ and `-instantsendnotify` cmd-line/config option); * "push" notifications (ZMQ and `-instantsendnotify` cmd-line/config option);
* RPC commands. * 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. 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) * 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) * 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): When a wallet InstantSend transaction is successfully locked a shell command provided in this option is executed (`%s` in `<cmd>` is replaced by TxID):
@ -23,7 +23,7 @@ When a wallet InstantSend transaction is successfully locked a shell command pro
-instantsendnotify=<cmd> -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. Details pertaining to an observed "Transaction Lock" can also be retrieved through RPC, it’s important however to understand the underlying mechanism.

6
doc/keepass.md
View File

@ -1,4 +1,4 @@
###What is it about### ### What is it about
More info regarding KeePass: http://keepass.info/ 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. - 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 - JSON Spirit for reading / writing RPC communications
###What's new### ### What's new
The following new options are available for dashd and dash-qt: The following new options are available for dashd and dash-qt:
- _-keepass_ Use KeePass 2 integration using KeePassHttp plugin (default: 0) - _-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 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. - _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): Sample initialization flow from _dash-qt_ console (this needs to be done only once to set up the association):

16
doc/release-process.md
View File

@ -6,7 +6,7 @@ Release Process
* * * * * *
###First time / New builders ### First time / New builders
Check out the source code in the following directory hierarchy. Check out the source code in the following directory hierarchy.
cd /path/to/your/toplevel/build 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/devrandom/gitian-builder.git
git clone https://github.com/dashpay/dash.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 pushd ./dash
contrib/verifysfbinaries/verify.sh 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: Setup Gitian descriptors:
@ -58,7 +58,7 @@ Check out the source code in the following directory hierarchy.
pushd ./gitian-builder pushd ./gitian-builder
git pull 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 mkdir -p inputs
wget -P inputs https://bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch 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 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: 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. 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/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 ./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) 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)/ 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 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 popd
###Next steps: ### Next steps:
Commit your signature to gitian.sigs: Commit your signature to gitian.sigs: