spacecruft
/
blockbook
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

typos

pull/50/head
Jakub Matys 2018-08-29 09:47:56 +02:00
parent 89517aa39e
commit eb87d530df
3 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
CONTRIBUTING.md
View File

@ -22,7 +22,7 @@ them to Blockbook. Actually implemented coins are listed [here](/docs/ports.md).
You should follow few steps bellow to get smooth merge of your PR.
> Altough we are happy for support of new coins we have not enough capacity to run them all on our infrastructure.
> Although we are happy for support of new coins we have not enough capacity to run them all on our infrastructure.
> Actually we can run Blockbook instances only for coins supported by Trezor wallet. If you want to have Blockbook
> instance for your coin, you will have to deploy your own server.
@ -77,13 +77,13 @@ Coin implementation is stored in *bchain/coins* directory. Each coin must implem
There are several approaches how to implement coin support in Blockbook, please see examples below.
Bitcoin package *blockbook/bchain/coins/btc* is reference implementation for Bitcoin-like coins. Most of functinality is
Bitcoin package *blockbook/bchain/coins/btc* is reference implementation for Bitcoin-like coins. Most of functionality is
same so particular coin should embed it and override just different parts.
Bitcoin uses binary WIRE protocol thus decoding is very fast but require complex parser. Parser translate whole
pubkey-script to databse ID and therefore it is usually possible store transactions without change.
pubkey-script to database ID and therefore it is usually possible store transactions without change.
ZCash package *blockbook/bchain/coins/zec* on the other side uses JSON version of RPCs therefore it dosn't require
ZCash package *blockbook/bchain/coins/zec* on the other side uses JSON version of RPCs therefore it doesn't require
specialized parser. Only responsibility that parser has is to translate address to database ID and vice versa.
Ethereum package *blockbook/bchain/coins/eth* must have stand alone implementation because Ethereum uses totally
@ -134,7 +134,7 @@ There are several groups of methods defined in *bchian.BlockChainParser*:
Most of coins use pubkey-script as ID.
* *AddressToOutputScript* and *OutputScriptToAddresses* – Convert address to output script and vice versa. Note that
*btc.BitcoinParser* uses pointer to function *OutputScriptToAddressesFunc* that is called from *OutputScriptToAddress*
method in order to rewrite implementation by types embdedding it.
method in order to rewrite implementation by types embedding it.
* *PackTxid* and *UnpackTxid* – Packs txid to store in database and vice versa.
* *ParseTx* and *ParseTxFromJson* – Parse transaction from binary data or JSON and return *bchain.Tx.
* PackTx* and *UnpackTx* – Pack transaction to binary data to store in database and vice versa.
@ -154,4 +154,4 @@ Add unit tests and integration tests. Tests are described [here](/docs/testing.m
#### Deploy public server
Deploy Blockbook server on public IP addres. Blockbook maintainers will check implementation before merging.
Deploy Blockbook server on public IP address. Blockbook maintainers will check implementation before merging.

8
docs/build.md
View File

@ -43,7 +43,7 @@ mandatory, of course.
> back-end configuration and Blockbook configuration as well. There were many options that were duplicated across
> configuration files and therefore error prone.
>
> Actually all configuration options and also build options for both Blockbook and backend are defined in single JSON
> Actually all configuration options and also build options for both Blockbook and back-end are defined in single JSON
> file and all stuff required during build is generated dynamically.
Makefile targets follow simple pattern, there are few prefixes that define what to build.
@ -70,8 +70,8 @@ For example we want to build some packages for Bitcoin and Bitcoin Testnet.
build/backend-bitcoin_0.16.1-satoshilabs-1_amd64.deb build/backend-bitcoin-testnet_0.16.1-satoshilabs-1_amd64.deb build/blockbook-bitcoin_0.0.6_amd64.deb
```
We have built two backend packages – for Bitcoin and Testnet – and Blockbook package for Bitcoin. Before build have been
performed there was cleaned build directory and rebuilt Docker image.
We have built two back-end packages – for Bitcoin and Testnet – and Blockbook package for Bitcoin. Before build have
been performed there was cleaned build directory and rebuilt Docker image.
### Extra variables
@ -244,7 +244,7 @@ Blockbook require full node daemon as its back-end. You are responsible for prop
daemon configuration are defined in *configs/coins* and *build/templates/backend/config* directories. You should use
specific installation process for particular coin you want run (e.g. https://bitcoin.org/en/full-node#other-linux-distributions for Bitcoin).
When you have running back-end daemon you can start Blockbook. It is highly recomended use ports described in [ports.md](/docs/ports.md)
When you have running back-end daemon you can start Blockbook. It is highly recommended use ports described in [ports.md](/docs/ports.md)
for both Blockbook and back-end daemon. You can use *contrib/scripts/build-blockchaincfg.sh* that will generate
Blockbook's blockchain configuration from our coin definition files.

2
docs/config.md
View File

@ -99,7 +99,7 @@ Good examples of coin configuration are
We use *text/template* package to generate package definitions and configuration files. Some options in coin definition
are also templates and are executed inside base template. Use `{{.path}}` syntax to refer values in coin definition,
where *.path* can be for example *.Blockbook.BlockChain.Parse*. Go uses CammelCase notation so references inside templates
where *.path* can be for example *.Blockbook.BlockChain.Parse*. Go uses CamelCase notation so references inside templates
as well. Note that dot at the beginning is mandatory. Go template syntax is fully documented
[here](https://godoc.org/text/template).