Fix typos/grammar in docs

This commit is contained in:
grdddj 2023-07-13 13:35:08 +02:00 committed by Martin
parent 65cd73d081
commit a139dd5d52
4 changed files with 10 additions and 10 deletions

View File

@ -464,7 +464,7 @@ Blockbook supports BIP44, BIP49, BIP84 and BIP86 (Taproot) derivation schemes, u
- Output descriptors
Output descriptors are in the form `<type>([<path>]<xpub>[/<change>/*])[#checkum]`, for example `pkh([5c9e228d/44'/0'/0']xpub6BgBgses...Mj92pReUsQ/<0;1>/*)#abcd`
Output descriptors are in the form `<type>([<path>]<xpub>[/<change>/*])[#checksum]`, for example `pkh([5c9e228d/44'/0'/0']xpub6BgBgses...Mj92pReUsQ/<0;1>/*)#abcd`
Parameters `type` and `xpub` are mandatory, the rest is optional

View File

@ -11,7 +11,7 @@ Manual build require additional dependencies that are described in appropriate s
## Build in Docker environment
All build operations run in Docker container in order to keep build environment isolated. Makefile in root of repository
define few targets used for building, testing and packaging of Blockbook. With Docker image definitions and Debian
defines few targets used for building, testing and packaging of Blockbook. With Docker image definitions and Debian
package templates in *build/docker* and *build/templates* respectively, they are only inputs that make build process.
Docker build images are created at first execution of Makefile and that information is persisted. (Actually there are
@ -137,7 +137,7 @@ Blockbook versioning is much simpler. There is only one version defined in *conf
### Back-end building
Because we don't keep back-end archives inside out repository we download them during build process. Build steps
Because we don't keep back-end archives inside our repository we download them during build process. Build steps
are these: download, verify and extract archive, prepare distribution and make package.
All configuration keys described below are in coin definition file in *configs/coins*.
@ -153,7 +153,7 @@ have signed sha256 sums and some don't care about verification at all. So there
could be *gpg*, *gpg-sha256* or *sha256* and chooses particular method.
*gpg* type require file with digital sign and maintainer's public key imported in Docker build image (see below). Sign
file is downloaded from URL defined in *backend.verification_source*. Than is passed to gpg in order to verify archvie.
file is downloaded from URL defined in *backend.verification_source*. Than is passed to gpg in order to verify archive.
*gpg-sha256* type require signed checksum file and maintainer's public key imported in Docker build image (see below).
Checksum file is downloaded from URL defined in *backend.verification_source*. Then is verified by gpg and passed to
@ -201,12 +201,12 @@ export PATH=$PATH:$GOPATH/bin
```
Install RocksDB: https://github.com/facebook/rocksdb/blob/master/INSTALL.md
and compile the static_lib and tools. Optionally, consider adding `PORTABLE=1` before the
and compile the static_lib and tools. Optionally, consider adding `PORTABLE=1` before the
make command to create a portable binary.
```
sudo apt-get update && sudo apt-get install -y \
build-essential git wget pkg-config libzmq3-dev libgflags-dev libsnappy-dev zlib1g-dev libzstd-dev libbz2-dev liblz4-dev
build-essential git wget pkg-config libzmq3-dev libgflags-dev libsnappy-dev zlib1g-dev libzstd-dev libbz2-dev liblz4-dev
git clone https://github.com/facebook/rocksdb.git
cd rocksdb
git checkout v7.5.3

View File

@ -32,7 +32,7 @@ Good examples of coin configuration are
* `backend_*` Additional back-end ports can be documented here. Actually the only purpose is to get them to
port table (prefix is removed and rest of string is used as note).
* `blockbook_internal` Blockbook's internal port that is used for metric collecting, debugging etc.
* `blockbook_public` Blockbook's public port that is used to comunicate with Trezor wallet (via Socket.IO).
* `blockbook_public` Blockbook's public port that is used to communicate with Trezor wallet (via Socket.IO).
* `ipc` Defines how Blockbook connects its back-end service.
* `rpc_url_template` Template that defines URL of back-end RPC service. See note on templates below.
@ -82,7 +82,7 @@ Good examples of coin configuration are
* `explorer_url` URL of blockchain explorer. Leave empty for internal explorer.
* `additional_params` Additional params of exec command (see [Dogecoin definition](/configs/coins/dogecoin.json)).
* `block_chain` Configuration of BlockChain type that ensures communication with back-end service. All options
must be tweaked for each individual coin separely.
must be tweaked for each individual coin separately.
* `parse` Use binary parser for block decoding if *true* else call verbose back-end RPC method that returns
JSON. Note that verbose method is slow and not every coin support it. However there are coin implementations
that don't support binary parsing (e.g. ZCash).
@ -112,4 +112,4 @@ to alter built-in text that is specific for Trezor. Text fields that could be up
* [tos_link](/build/text/tos_link) A link to Terms of service shown as the footer on the Explorer pages.
Text data are stored as plain text files in *build/text* directory and are embedded to binary during build. A change of
theese files is mean for a private purpose and PRs that would update them won't be accepted.
these files is meant for a private purpose and PRs that would update them won't be accepted.

View File

@ -34,7 +34,7 @@ components of Blockbook, it is mandatory that coin implementations have these in
implemented in packages `blockbook/tests/rpc` and `blockbook/tests/sync` and both of them are declarative. For each coin
there are test definition that enables particular tests of test suite and *testdata* file that contains test fixtures.
Not every coin implementation support full set of back-end API so it is necessary define which tests of test suite
Not every coin implementation supports full set of back-end API so it is necessary to define which tests of test suite
are able to run. That is done in test definition file *blockbook/tests/tests.json*. Configuration is hierarchical and
test implementations call each level as separate subtest. Go's *test* command allows filter tests to run by `-run` flag.
It perfectly fits with layered test definitions. For example, you can: