RanchiMall/flosight-api
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #161 from maraoz/update/README

Browse Source 
Update readme
This commit is contained in:
Gustavo Maximiliano Cortez 2014-08-22 12:01:08 -03:00
commit 3ecb754ed2
1 changed files with 48 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

85
README.md
View File

@ -1,45 +1,29 @@
# *insight API*
*insight API* is an open-source bitcoin blockchain REST
and websocket API. Insight API runs in NodeJS and use LevelDB for storage.
*insight API* is an open-source bitcoin blockchain REST
and websocket API. Insight API runs in NodeJS and uses LevelDB for storage.
*Insight API* allows to develop bitcoin related applications such as wallets that
This is a backend-only service. If you're looking for the web frontend application,
take a look at https://github.com/bitpay/insight.
*Insight API* allows to develop bitcoin-related applications (such as wallets) that
require certain information from the blockchain that bitcoind does not provide.
A blockchain explorer front-end have been developed to top of *Insight API*, it can
A blockchain explorer front-end has been developed on top of *Insight API*. It can
be downloaded at [Github Insight Repository](https://github.com/bitpay/insight).
## IMPORTANT: Upgrading from v0.1 to v0.2
In order to optimize some queries, the key-value layout in Level DB has been changed.
If you are running v0.1.x, a total resync needs to be done, running `$ util/sync.js -D`. This
needs to run while *insight-api* is shut off. See details at: **Synchronization**.
## IMPORTANT: v0.2 Caching schema
In v0.2 a new cache schema has been introduced. Only information from transactions with
INSIGHT_SAFE_CONFIRMATIONS+ settings will be cached (by default SAFE_CONFIRMATIONS=6). There
are 3 different caches:
* nr. of confirmations
* transaction spent information
* scriptPubKey for unspent transactions
Cache data is only populated on request, i.e., only after accessing the required data for
the first time, the information is cached, there is not pre-caching procedure. To ignore
cache by default, use INSIGHT_IGNORE_CACHE. Also, address related calls support `?noCache=1`
to ignore the cache in a particular API request.
## Prerequisites
* **bitcoind** - Download and Install [Bitcoin](http://bitcoin.org/en/download)
*insight API* needs a *trusted* bitcoind node to run. *insight API* will connect to the node
thru the RPC API, Peer-to-peer protocol and will even read its raw .dat files for syncing.
through the RPC API, bitcoin peer-to-peer protocol, and will even read its raw block .dat files for syncing.
Configure bitcoind to listen to RPC calls and set `txindex` to true.
The easiest way to do this is by copying `./etc/bitcoind/bitcoin.conf` to your
bitcoin data directory (usually `"~/.bitcoin"` on Linux, `"%appdata%\Bitcoin\"` on Windows,
or `"~/Library/Application Support/Bitcoin"` on Mac OS X).
bitcoin data directory (usually `~/.bitcoin` on Linux, `%appdata%\Bitcoin\` on Windows,
or `~/Library/Application Support/Bitcoin` on Mac OS X).
bitcoind must be running and must have finished downloading the blockchain **before** running *insight API*.
@ -69,7 +53,7 @@ bitcoind must be running and must have finished downloading the blockchain **bef
Please note that the app will need to sync its internal database
with the blockchain state, which may take some time. You can check
sync progress from within the web interface.
sync progress at http://localhost:3001/api/sync.
## Configuration
@ -102,15 +86,26 @@ In case the network is changed (testnet to livenet or vice versa) levelDB databa
## Synchronization
The initial synchronization process scans the blockchain from the paired bitcoind server to update addresses and balances. *insight* needs one (and only one) trusted bitcoind node to run. This node must have finished downloading the blockchain before running *insight*.
The initial synchronization process scans the blockchain from the paired bitcoind server to update addresses and balances. *insight-api* needs exactly one trusted bitcoind node to run. This node must have finished downloading the blockchain before running *insight-api*.
While *insight* is synchronizing the website can be accessed (the sync process is embedded in the webserver), but there may be missing data or incorrect balances for addresses. The 'sync' status is shown at the `/api/sync` endpoint.
The blockchain can be read from bitcoind's raw `.dat` files or RPC interface. Reading the information from the `.dat` files is much faster so it's the recommended (and default) alternative. `.dat` files are scanned in the default location for each platform (for example, `~/.bitcoin` on Linux). In case a non-standard location is used, it needs to be defined (see the Configuration section). As of June 2014, using `.dat` files the sync process takes 9 hrs. for livenet and 30 mins. for testnet.
The blockchain can be read from bitcoind's raw `.dat` files or RPC interface.
Reading the information from the `.dat` files is much faster so it's the
recommended (and default) alternative. `.dat` files are scanned in the default
location for each platform (for example, `~/.bitcoin` on Linux). In case a
non-standard location is used, it needs to be defined (see the Configuration section).
As of June 2014, using `.dat` files the sync process takes 9 hrs.
for livenet and 30 mins. for testnet.
While synchronizing the blockchain, *insight* listens for new blocks and transactions relayed by the bitcoind node. Those are also stored on *insight*'s database. In case *insight* is shutdown for a period of time, restarting it will trigger a partial (historic) synchronization of the blockchain. Depending on the size of that synchronization task, a reverse RPC or forward `.dat` syncing strategy will be used.
While synchronizing the blockchain, *insight-api* listens for new blocks and
transactions relayed by the bitcoind node. Those are also stored on *insight-api*'s database.
In case *insight-api* is shutdown for a period of time, restarting it will trigger
a partial (historic) synchronization of the blockchain. Depending on the size of
that synchronization task, a reverse RPC or forward `.dat` syncing strategy will be used.
If bitcoind is shutdown, *insight* needs to be stopped and restarted once bitcoind is restarted.
If bitcoind is shutdown, *insight-api* needs to be stopped and restarted
once bitcoind is restarted.
### Syncing old blockchain data manually
@ -120,18 +115,21 @@ If bitcoind is shutdown, *insight* needs to be stopped and restarted once bitcoi
Check util/sync.js --help for options, particulary -D to erase the current DB.
*NOTE* that there is no need to run this manually since the historic synchronization is embedded on the web application, so by running you will trigger the historic sync automatically.
*NOTE*: there is no need to run this manually since the historic synchronization
is built in into the web application. Running *insight-api* normally will trigger
the historic sync automatically.
### DB storage requirement
To store the blockchain and address related information, *insight* uses LevelDB. Two DBs are created: txs and blocks. By default these are stored on
To store the blockchain and address related information, *insight-api* uses LevelDB.
Two DBs are created: txs and blocks. By default these are stored on
``~/.insight/``
Please note that previous version's of Insight-API store that on `<insight's root>/db`
Please note that some older versions of Insight-API store that on `<insight's root>/db`.
this can be changed on config/config.js. As of June 2014, storing the livenet blockchain takes ~35GB of disk space (2GB for the testnet).
This can be changed at config/config.js. As of June 2014, storing the livenet blockchain takes ~35GB of disk space (2GB for the testnet).
## Development
@ -146,6 +144,19 @@ To run the tests
Contributions and suggestions are welcome at [insight-api github repository](https://github.com/bitpay/insight-api).
## Caching schema
Since v0.2 a new cache schema has been introduced. Only information from transactions with
INSIGHT_SAFE_CONFIRMATIONS settings will be cached (by default SAFE_CONFIRMATIONS=6). There
are 3 different caches:
* Number of confirmations
* Transaction output spent/unspent status
* scriptPubKey for unspent transactions
Cache data is only populated on request, i.e., only after accessing the required data for
the first time, the information is cached, there is not pre-caching procedure. To ignore
cache by default, use INSIGHT_IGNORE_CACHE. Also, address related calls support `?noCache=1`
to ignore the cache in a particular API request.
## API
@ -205,7 +216,7 @@ Sample return:
}
]
```
Please note that in case confirmations are cached (because the number of confirmations if bigger that INSIGHT_SAFE_CONFIRMATIONS) the return will include the pair confirmationsFromCache:true, and confirmations will equal INSIGHT_SAFE_CONFIRMATIONS. See noCache and INSIGHT_IGNORE_CACHE options for details.
Please note that in case confirmations are cached (which happens by default when the number of confirmations is bigger that INSIGHT_SAFE_CONFIRMATIONS) the response will include the pair confirmationsFromCache:true, and confirmations will equal INSIGHT_SAFE_CONFIRMATIONS. See noCache and INSIGHT_IGNORE_CACHE options for details.
@ -273,7 +284,7 @@ POST response:
/api/peer
```
### Status network
### Status of the bitcoin network
```
/api/status?q=xxx
```