typos
parent
89517aa39e
commit
eb87d530df
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
Loading…
Reference in New Issue