github.com/jackcoble/blockbook@v0.3.2/docs/config.md (about)

     1  # Configuration
     2  
     3  Coin definitions are stored in JSON files in *configs/coins* directory. They are single source of Blockbook
     4  configuration, Blockbook and back-end package definition and build metadata. Since Blockbook supports only single
     5  coin index per running instance, every coin (including testnet) must have single definition file.
     6  
     7  Because most of coins are fork of Bitcoin and they have similar way to install and configure their daemon, we use
     8  templates to generate package definition and configuration files during build process. It is similar to build Blockbook
     9  package too. Templates are filled with data from coin definition. Although build process generate packages
    10  automatically, there is sometimes necessary see intermediate step. You can generate all files by calling
    11  `go run build/templates/generate.go coin` where *coin* is name of definition file without .json extension. Files are
    12  generated to *build/pkg-defs* directory.
    13  
    14  Good examples of coin configuration are
    15  [*configs/coins/bitcoin.json*](/configs/coins/bitcoin.json) and
    16  [*configs/coins/ethereum.json*](/configs/coins/ethereum.json) for Bitcoin-like coins and different coins, respectively.
    17  
    18  ## Description of coin definition
    19  
    20  * `coin` – Base information about coin.
    21      * `name` – Name of coin used internally (e.g. "Bcash Testnet").
    22      * `shortcut` – Ticker symbol (code) of coin (e.g. "TBCH").
    23      * `label` – Name of coin used publicly (e.g. "Bitcoin Cash Testnet").
    24      * `alias` – Name of coin used in file system paths and config files. We use convention that name uses lowercase
    25         characters and underscore '_' as a word delimiter. Testnet versions of coins must have *_testnet*
    26        suffix. For example "bcash_testnet".
    27  
    28  * `ports` – List of ports used by both back-end and Blockbook. Ports defined here are used in configuration templates
    29     and also as source for generated documentation.
    30      * `backend_rpc` – Port of back-end RPC that is connected by Blockbook service.
    31      * `backend_message_queue` – Port of back-end MQ (if used) that is connected by Blockbook service.
    32      * `backend_*` – Additional back-end ports can be documented here. Actually the only purpose is to get them to
    33         port table (prefix is removed and rest of string is used as note).
    34      * `blockbook_internal` – Blockbook's internal port that is used for metric collecting, debugging etc.
    35      * `blockbook_public` – Blockbook's public port that is used to comunicate with Trezor wallet (via Socket.IO).
    36  
    37  * `ipc` – Defines how Blockbook connects its back-end service.
    38      * `rpc_url_template` – Template that defines URL of back-end RPC service. See note on templates below.
    39      * `rpc_user` – User name of back-end RPC service, used by both Blockbook and back-end configuration templates.
    40      * `rpc_pass` – Password of back-end RPC service, used by both Blockbook and back-end configuration templates.
    41      * `rpc_timeout` – RPC timeout used by Blockbook.
    42      * `message_queue_binding_template` – Template that defines URL of back-end's message queue (ZMQ), used by both
    43         Blockbook and back-end configuration template. See note on templates below.
    44  
    45  * `backend` – Definition of back-end package, configuration and service.
    46      * `package_name` – Name of package. See convention note in [build guide](/docs/build.md#on-naming-conventions-and-versioning).
    47      * `package_revision` – Revision of package. See convention note in [build guide](/docs/build.md#on-naming-conventions-and-versioning).
    48      * `system_user` – User used to run back-end service. See convention note in [build guide](/docs/build.md#on-naming-conventions-and-versioning).
    49      * `version` – Upstream version. See convention note in [build guide](/docs/build.md#on-naming-conventions-and-versioning).
    50      * `binary_url` – URL of back-end archive.
    51      * `verification_type` – Type of back-end archive verification. Possible values are *gpg*, *gpg-sha256*, *sha256*.
    52      * `verification_source` – Source of sign/checksum of back-end archive.
    53      * `extract_command` – Command to extract back-end archive. It is required to extract content of archive to
    54         *backend* directory.
    55      * `exclude_files` – List of files from back-end archive to exclude. Some files are not required for server
    56         deployment, some binaries have unnecessary dependencies, so it is good idea to extract these files from output
    57         package. Note that paths are relative to *backend* directory where archive is extracted.
    58      * `exec_command_template` – Template of command to execute back-end node daemon. Every back-end node daemon has its
    59         service that is managed by systemd. Template is evaluated to *ExecStart* option in *Service* section of
    60         service unit. See note on templates below.
    61      * `logrotate_files_template` – Template that define log files rotated by logrotate daemon. See note on templates
    62         below.
    63      * `postinst_script_template` – Additional steps in postinst script. See [ZCash definition](/configs/coins/zcash.json)
    64         for more information.
    65      * `service_type` – Type of service. Services that daemonize must have *forking* type and write their PID to
    66         *PIDFile*. Services that don't support daemonization must have *simple* type. See examples above.
    67      * `service_additional_params_template` – Additional parameters in service unit. See
    68         [ZCash definition](/configs/coins/zcash.json) for more information.
    69      * `protect_memory` – Enables *MemoryDenyWriteExecute* option in service unit if *true*.
    70      * `mainnet` – Set *false* for testnet back-end.
    71      * `config_file` – Name of template of back-end configuration file. Templates are defined in *build/backend/config*.
    72         For Bitcoin-like coins it is not necessary to add extra template, most options can be added via
    73         *additional_params*. For coins that don't require configuration option should be empty (e.g. Ethereum).
    74      * `additional_params` – Object of extra parameters that are added to back-end configuration file as key=value pairs.
    75         Exception is *addnode* key that contains list of nodes that is expanded as addnode=item lines.
    76  
    77  * `blockbook` – Definition of Blockbook package, configuration and service.
    78      * `package_name` – Name of package. See convention note in the [build guide](/docs/build.md#on-naming-conventions-and-versioning).
    79      * `system_user` – User used to run Blockbook service. See convention note in the [build guide](/docs/build.md#on-naming-conventions-and-versioning).
    80      * `internal_binding_template` – Template for *-internal* parameter. See note on templates below.
    81      * `public_binding_template` – Template for *-public* parameter. See note on templates below.
    82      * `explorer_url` – URL of blockchain explorer. Leave empty for internal explorer.
    83      * `additional_params` – Additional params of exec command (see [Dogecoin definition](/configs/coins/dogecoin.json)).
    84      * `block_chain` – Configuration of BlockChain type that ensures communication with back-end service. All options
    85         must be tweaked for each individual coin separely.
    86          * `parse` – Use binary parser for block decoding if *true* else call verbose back-end RPC method that returns
    87             JSON. Note that verbose method is slow and not every coin support it. However there are coin implementations
    88             that don't support binary parsing (e.g. ZCash).
    89          * `mempool_workers` – Number of workers for BitcoinType mempool.
    90          * `mempool_sub_workers` – Number of subworkers for BitcoinType mempool.
    91          * `block_addresses_to_keep` – Number of blocks that are to be kept in blockaddresses column.
    92          * `additional_params` – Object of coin-specific params.
    93  
    94  * `meta` – Common package metadata.
    95      * `package_maintainer` – Full name of package maintainer.
    96      * `package_maintainer_email` – E-mail of package maintainer.
    97  
    98  ### Go template evaluation note
    99  
   100  We use *text/template* package to generate package definitions and configuration files. Some options in coin definition
   101  are also templates and are executed inside base template. Use `{{.path}}` syntax to refer values in coin definition,
   102  where *.path* can be for example *.Blockbook.BlockChain.Parse*. Go uses CamelCase notation so references inside templates
   103  as well. Note that dot at the beginning is mandatory. Go template syntax is fully documented
   104  [here](https://godoc.org/text/template).
   105  
   106  ## Built-in text
   107  
   108  Since Blockbook is an open-source project and we don't prevent anybody from running independent instances, it is possible
   109  to alter built-in text that is specific for Trezor. Text fields that could be updated are:
   110  
   111   * [about](/build/text/about) – A note about instance shown on the Application status page and returned by an API.
   112   * [tos_link](/build/text/tos_link) – A link to Terms of service shown as the footer on the Explorer pages.
   113  
   114  Text data are stored as plain text files in *build/text* directory and are embedded to binary during build. A change of
   115  theese files is mean for a private purpose and PRs that would update them won't be accepted.