bitcoind: Your decentralized block explorer (HTTP REST API)

[jgarzik]

URL: https://github.com/bitcoin/bitcoin/pull/2844

Adding an HTTP REST API for bitcoind has been occasionally tossed about as a useful thing.  Such an API would essentially provide a decentralized block explorer capability, enabling easy external access to transaction/address/block indices that we maintain.

The first two implemented API calls are simple, returning a block or TX given a simple query string based on block hash, e.g.

Code:

     GET /rest/tx/TX-HASH

Code:

     GET /rest/block/BLOCK-HASH

This can be easily accessed via command line cURL/wget utilities. Output formats -- binary, hex or json -- may be selected by append a "/json" or "/hex" suffix to the URL, e.g.

Code:

     GET /rest/tx/TX-HASH/json

The general goal of the HTTP REST interface is to access unauthenticated, public blockchain information.  There is no plan to add wallet interfacing/manipulation via this API.

[NielDLR]

Great idea. So, how would you access this?

I went through the source code, but couldn't find it?

Would it work on the port exposed by the JSON-RPC interface set in the bitcoin.conf? So for example: localhost:8332/rest/tx/TX-HASH?

Would you have to set tx-index=1 to get transactions with all spent outputs? The same way the getrawtransaction works at the moment?

Great idea. I started building a Bitcoin-Node-API that exposes the commands in a similar way.

[jgarzik]

Would it work on the port exposed by the JSON-RPC interface set in the bitcoin.conf? So for example: localhost:8332/rest/tx/TX-HASH?

Yes.

Would you have to set tx-index=1 to get transactions with all spent outputs? The same way the getrawtransaction works at the moment?

Yes.

[d'aniel]

Are there plans for a call that returns a tx's merkle branch?

[jgarzik]

Are there plans for a call that returns a tx's merkle branch?

What is the use case?  That data falls into the category of "public blockchain data", so it is OK to add that sort of data, if there is a use.

Note that the JSON format of a TX outputs its confirmed block-hash, which enables discovery of a TX's merkle branch.

[jgarzik]

Updated OP and pull request to remove non-standard "Bitcoin-Format" header, and instead use github-style "clean" URLs.

[d'aniel]

Are there plans for a call that returns a tx's merkle branch?

What is the use case?  That data falls into the category of "public blockchain data", so it is OK to add that sort of data, if there is a use.

Note that the JSON format of a TX outputs its confirmed block-hash, which enables discovery of a TX's merkle branch.

No particular use case in mind at the moment; being able to easily prove a given tx was included in a block just feels generally useful to me, and a more targeted call than one that returns the full block is more efficient for both parties.

[Peter Todd]

Are there plans for a call that returns a tx's merkle branch?

No particular use case in mind at the moment; being able to easily prove a given tx was included in a block just feels generally useful to me, and a more targeted call than one that returns the full block is more efficient for both parties.

You may find this code interesting, specifically find_digest_in_block(): https://github.com/opentimestamps/opentimestamps-server/blob/master/otsserver/bitcoin.py#L93

Basically it first finds a specific digest in a block, checking every tx, and then rebuilds the merkle tree to extract a merkle path from that transaction to the block header.

[jgarzik]

The suggestion on github to permit selection of output format by file extension is interesting.  e.g.

GET /rest/tx/TX-HASH.json (JSON-format expanded tx)

GET /rest/tx/TX-HASH.txt (binary serialized tx, hex encoding)

etc.