mirror of
https://github.com/dashpay/dash.git
synced 2024-12-25 03:52:49 +01:00
Doc: fix broken formatting in markdown #headers (#1462)
* 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
UdjinM6
parent
39750439bf
commit
82a4643135
@ -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:
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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._
|
||||
|
||||
@ -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 `<cmd>` is replaced by TxID):
|
||||
|
||||
@ -23,7 +23,7 @@ When a wallet InstantSend transaction is successfully locked a shell command pro
|
||||
-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.
|
||||
|
||||
|
||||
@ -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):
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user