helloblock.io API V1 Discussions

[Sidney Zhang]

The endpoints are not yet stable. Although they will probably mostly stay the same. 

A couple of questions comes to mind:

1. Do you need additional endpoints?

2. Do you need additional data for endpoints?

3. Do you need more parameters for better filtering?

Also:

Any return value that has a tag "meta" is only there for debugging purposes and will be removed prior to stable release so please do not rely on them.

[Aaron Blankenship]

The only thing I can think of is maybe a verbose filter, which can help limit the amount of data that is returned to only the most necessary bits, that will keep the amount of data down in large scale applications that don't need everything.

[Sidney Zhang]

Yeah good idea. 

I will work on that. It makes sense to have a verbose filter transaction returns a ton of stuff

[Sidney Zhang]

Hey Guys,

This is the work in progress rewrite of the Rails API into nodejs. I have high hopes for this and think this should give us much better response time and overall better scalability

https://github.com/sidazhang/node_bitcoin_api

@brookes, jp, aaron, you guys are all nodejs guys, please take a look. JP helped me with this, I am definitely new to node.

@Brooks, I am also working on a blockchain parser in Go that I plan use to write into the database. (It will first load the data from files and then load data from bitcoind). I hope to replace a key piece of dependency with this. I think you are familiar with the parsers etc, I would love to ask you a few things regarding that.

[Brooks Boyd]

I'm not that familiar with the Go language, but I am familiar with working with the raw binary format of  blocks/transactions/messages. So your application flow will be bitcoind -> database -> blockchain parser (Go) -> other database <-> API service (not quite sure what you mean by "first load the data from files and then load data from bitcoind"; what are the first "files" mentioned in that phrase? Meaning it looks up data in a local cache first, and if it can't find it there, it loads data from bitcoind?)? Meaning are you planning on pulling data from bitcoind's database, or communicating with it via JSON-RPC? The former will require parsing the binary data, while the latter won't (since it's JSON already, which Node won't have a problem with).

[Sidney Zhang]

Hey Brooks,

I am still not entire sure of the implementation details. But I am currently using https://github.com/bitcoin-abe/bitcoin-abe

It seems to have 2 modes:

1. It watches your block files (blk000??.dat) for changes and when there are new writes it reads from it

2. It could have a load to load raw block data via JSON RPC and then parse them, although i am not sure how this works.

so the application flow could be 

bitcoind -> dat files -> parse -> sql store -> API service

or 

bitcoind -> parse -> sql store -> API service

I am still wrapping my head around how abe works. I am able to parse dat files now. But still not sure how to parse it continuously. 

[Aaron Blankenship]

Hey Sidney, how goes the Node rewrite of the API?

Work has been crazy busy for me the last month and a half, but I've finally found time to get back to my Bitcoin project.

[Sidney Zhang]

I am going to cc Scott here

Aaron, the API rewrite is almost fully done

we even have a blockexplorer

check this out:

https://helloblock.io/testnet

The blockexplorer is entirely backed by the API. Let's skype and I will bring you up to date about the API? (documentation is still currently out of date)

[Brooks Boyd]

One project of mine (rather, a programming doodle of mine I did and haven't developed further) is this graphical display of a transaction's history:

http://btc-transaction-tree.gopagoda.com/?txn=57326023&g=3&prune

It's using blockchain.info as an API source right now, but since blockchain doesn't have the means to do a batch query for transaction data, I'd very quickly hit rate limits if I made this more public at this point. 

This graph was inspired by Google Analytics' "visitor flow" graphs, and I like how the size of the input/output connecting bands of each transaction are proportionate to the percentage of the transaction they contribute to, and the transactions themselves are taller if they have more value.

Remove the "&prune" query variable to see the non-essential addresses filled into the tree, and change "g" to set the number of generations to go back (max of 5).

I think this sort of graph is great for showing interactions between addresses, since in that example URL I gave, you can see that transaction 57326023 got three of its four inputs from 57315077, which got three of its four from 57303263 (that's a pattern), and both outputs of 57303591 contribute into 57326023, but through two different intermediary transactions with other addresses.

Coinbase transactions cause the graph to taper the other way: http://btc-transaction-tree.gopagoda.com/?txn=55240899&g=3

But, one huge limitation of the Blockchain.info API is it can't do look-ahead queries asking "is this transaction output spent? If so, by whom?" it can only query backwards "what is the output that correlates to this input?" (which is actually just part of the transaction structure itself how it identifies inputs). Meaning right now on the graph, I can't add a clickable area to "continue the tree this way" at the far right of the graph, since I don't know if those outputs are spent. So, might your API service be available as a new back-end for this graph? Does it have the capability to do a "is this output spent?" query?

Thanks!

Brooks

[Sidney Zhang]

Hey Brooks.

Actually it does do "is this output spent query", but it doesn't have an endpoint that allows you to seek who is it spent by

I do have plans to make that an optional field though. 

For example: 

https://test.helloblock.io/v1/transactions/54a50cc71cde249d6ac872e395d455e7af3f5b9c9a57d542b3c624d4529b7d26

This is a testnet transaction, if you look at the output it says "spent: false"

I can also add a beta endpoint that tells you who it is spent by (because I need that for the explorer)