The release of bchd 0.14.3 brings with it a long awaited feature, a public API, which makes bchd one of the top indexing blockchain servers in the Bitcoin Cash ecosystem.

For a little background most full node implementations, such as Bitcoin-Core, Bitcoin-ABC, or Bitcoin-Unlimited, only compute and store the bare minimum data necessary to maintain a local wallet. They typically do not compute and store enough data to serve applications such as wallets, block explorers, or the myriad of other applications built on top of Bitcoin Cash.

For this functionality developers typically turn to indexing servers, such as Bitpay’s Insight server. These servers are typically extra software that needs to be installed on top of the full node and which connects to it computes the required indexes and serves the data via a public API.

Developers who have worked with these servers can attest that they often leave much to be desired. They tend to be difficult to install, run, and keep running in a production environment. Further the APIs exposed by these servers are not that great. Insight uses a REST API for some types of data but then requires the use of WebSockets and socket.io for others. Libbitcoin uses ZMQ! Which requires developers to import a large C dependency. Electrum servers use a clunky and cumbersome stratum API. And so on.

With bchd Bitcoin Cash developers have an out-of-the-box solution that just works. You simply download the binary and run it. That’s it!

bchd --txindex --addrindex --grpclisten=0.0.0.0

You can checkout the documentation for more advanced usage.

While prior releases of bchd had indexing ability, the data was not exposed to users in a way that was easily accessible. That has changed with the introduction of the gRPC API.

You may be asking why gRPC? Or maybe even what is gRPC?

gRPC is a new RPC framework created by Google that offers many advantages over the legacy JSON-RPC used in the our ecosystem as well as over various REST/WebSocket APIs.

To be brief:

No more hunting down API documentation or dealing with poorly documented APIs — .proto is the canonical format for API contracts.

is the canonical format for API contracts. No more hand-crafted JSON call objects — all requests and responses are strongly typed and code-generated, with hints available in the IDE.

No more dealing with methods, headers, body and low level networking — everything is handled by gRPC.

No more second-guessing the meaning of error codes — gRPC status codes are a canonical way of representing issues in APIs.

No more one-off server-side request handlers to avoid concurrent connections — gRPC is based on HTTP2, with multiplexes multiple streams over the same connection. So no more head-of-line blocking.

No more problems streaming data from a server — gRPC supports both 1:1 RPCs and 1:many streaming requests. No more awkward REST/WebSocket combo APIs.

No more data parse errors when rolling out new binaries — backwards and forwards-compatibility of requests and responses.

No need to write ANY client code as the protoc compiler will auto-generate client libraries, including wire serialization and deserialization code, for just about every major language. The compiler writes thousands of lines of code so you don’t have to.

We currently have a public bchd server running at bchd.greyh.at:8335 . Feel free to try it out!

The following video is a tutorial for how to use the new API and also a general introduction to gRPC for developers.