
Chain, the Blockchain API for developers - jmduke
https://chain.com/?
======
nullc
Bitcoin was created to reduce the level of trust required for the operation of
monetary systems.

Everytime I see another centralized interface to Bitcoin it depresses me.
Centralized interfaces on top of Bitcoin are sort of a worst of all worlds,
gaining all of the disadvantages of both centralized and decentralized
approaches.

~~~
wyager
Exactly. Why can't people release packages for examining local copies of the
blockchain? The blockchain isn't exactly hard to acquire.

~~~
_pius
_Why can 't people release packages for examining local copies of the
blockchain?_

"People." Why don't you write one instead of just criticizing theirs from the
sideline?

~~~
qq66
It takes a lot more skill and capability to be a creator than a consumer. I
would like someone to make a movie about two time travelers who chase each
other through time like a car chase. However I have zero filmmaking skill and
I don't really know how to even start such a thing. My skills are best applied
elsewhere, that doesn't mean I can't cross my fingers and hope that a talented
filmmaker makes that movie.

------
Rygu
Having worked with the Blockchain.info API, I am quite disappointed that
Chain.com (great domain name!) haven't put much effort into building a better,
more developer-friendly API. I mean returning variables named "n" and some
awkwardly abbreviated to "reqSigs" ?

C'mon we need better than this. You can do better than this!

For inspiriation: \-
[https://www.parse.com/docs/rest](https://www.parse.com/docs/rest) \-
[https://stripe.com/docs/api](https://stripe.com/docs/api)

~~~
k0mplex
We are just getting started (day 2!), so stay tuned, and hopefully we will
turn you into a fan! And thank you for sharing those links, we love those as
role models as well.

~~~
saurik
These are the kinds of details you have to get right at day 0 as you can't
just randomly change the API later.

------
diego
If you're serious about building a Bitcoin service, you don't need an extra
layer between you and bitcoind (or bitcoinj). If you find it too hard to deal
with the blockchain on your own via those apis, you probably should think
twice about developing a Bitcoin service.

~~~
ryandotsmith
I put together balancebadge.com, a simple bitcoind related app. If I didn't
use the chain.com API I would have had to run a server with bitcoind (~20GB of
data), a server that indexes data from bitcoind (recall that a simple address
balance is not exposed in bitcoind), and stores the data in an alternate
database (~200GB). There is no way that I would have built balancebadge if I
had to setup and maintain 3 servers with 100s of gigabytes of data.

Also, should developers who don't want to run a PostgreSQL server think twice
about building web apps? I believe that general purpose software that requires
server maintenance and state management should be run as a service. App
developers should be focusing on the details of their product –not how to keep
general purpose infrastructure alive and well.

 _edit_ Full disclosure: I am one of the creators of chain.com

~~~
drdaeman
Does one really need to keep the whole blockchain to perform basic things like
tracking account balance?

I'm not really savvy on the details, but from the overall understanding of how
Bitcoin works I believe one should receive data, keep it until consensus is
confirmed (blocks had matured for good, so unless the network went into really
weird split-brain situation no "valid" branches would grow out from those
blocks), then aggregate and throw data away.

Keeping the whole transaction history up to genesis block seems nearly
pointless to me.

Not sure whenever bitcoind can do those, though. Seems that it keeps the whole
blockchain, at least for seeding purposes.

And, indeed, one would still need a database and running daemon that'd leech
data from Bitcoin network. So, no way to have a badge on static HTML site.
That's valid use case.

------
nwh
Anybody working with Bitcoin should really avoid services like this just for
their own sanity. You've a wealth of freely accessible data in the form of the
20GB blockchain, why rely on trusting a third party for their uptime, privacy
and security?

It sort of already shows in the Bitcoin ecosystem, every time Blockchain.info
(the biggest API provider) glitches up, all of the services relying on it die
as well. Last time it went down there were people complaining that their
_ATMS_ could no longer work without Blockchain.info functioning.

~~~
runeks
> You've a wealth of freely accessible data in the form of the 20GB
> blockchain, why rely on trusting a third party for their uptime, privacy and
> security?

Except an address index, which is the added value that most of these types of
services provide (balance of an address, transactions associated with a
particular address, etc.).

~~~
nwh
Nobody except for people running block explorers really needs this
information. If you think you need it then you're probably using Bitcoin
completely wrong. Address based indexes don't scale, which is why it doesn't
create or even need one.

------
imkevinxu
I'm more interested in how they got chain.com

~~~
saurik
Playing around on archive.org, this domain name seems to have never been used
for anything, so it was probably just a matter of obtaining enough money to
purchase it.

------
lisperforlife
I also found [http://blockcypher.com](http://blockcypher.com) to be quite
nice. In addition to the blockchain API, they also have APIs for creating
transactions and even provide web sockets and web hooks. They do not host the
wallet so you do not have to share your private key with them. They will
create a transaction for you and you can then sign it with your private key.
This is a good gateway for developers into the bitcoin system. The alternative
is running bitcoind to download the 17 gig blockchain and then start coding.
This provides instant gratification for developers to get started.

------
maccman
I'm am extremely excited about Chain.com, and the other tools being build up
around the Bitcoin ecosystem. The power of giving developers simple tools and
building blocks is often underestimated - but it often results in radical
innovations.

A case in point is Stripe's API, and the ecosystem that has been subsequently
built around it. Yes, it's possible to send CC auths/settlements and ACH
transactions yourself - but the barrier to entry stifles innovation. Often the
most interesting innovations in tech occur when there's an innovation in
tooling.

I'm particularly interesting in Chain.com though, because I think currency is
only the tip of the iceberg when it comes to Blockchains. I wouldn't be
surprised if we see a number of other use-cases for Blockchains soon. [1]

[1] - [https://www.igvita.com/2014/05/05/minimum-viable-block-
chain...](https://www.igvita.com/2014/05/05/minimum-viable-block-chain/)

------
damethos
To be honest I do not understand why this made it to the HN top posts when
there are already other more complete APIs out there such as the Biteasy.com
API. Good domain name though. Maybe that's why it made it up here?

------
StavrosK
I was just looking at the Blockchain.info transaction API yesterday, and I'm
in love with its simplicity. It doesn't even require an account, and it's one
endpoint.

You just call it with a destination address and a URL, and it returns a source
address. Whenever any funds reach the source address, it forwards them to the
destination and calls your webhook once for every confirmation it sees.

So simple, and so brilliant. I'm trying to brainstorm things to build with it,
but so far I've come up short.

------
yowmamasita
What we need is a bitcoin sdk, not another 3rd-party rest api that will go
down if business does not profit. Open source this!

~~~
k0mplex
It will be open source, and will have SDKs, soon.

~~~
sv123
Twice on Sundays.

------
alco
Why is it not open source? I smell lock in.

~~~
saurik
Would it really be that hard to reimplement this yourself if you needed to?
The idea seems to be that this is a service: it isn't doing anything that
difficult to accomplish, it is just doing something that happens to be
resource intensive.

~~~
nwh
CPU resources or human ones? This package by Bitpay solves the latter.

[https://github.com/bitpay/insight](https://github.com/bitpay/insight)

~~~
saurik
That's the wrong repository: that's a front-end (a UI written using angular);
the backend repository (which could be said to be an open-source
implementation of chain.com) is the one I link below. All this package does is
provide a node.js wrapper for the bitcoind API. Almost all of the code (in
both repositories) is project boilerplate or data marshaling: everything even
remotely difficult is just "run bitcoind". I maintain it would be difficult to
get locked in to a service like this just because it isn't open source: it
isn't that difficult to rewrite.

[https://github.com/bitpay/insight-api](https://github.com/bitpay/insight-api)

As for "resource intensive", I was thinking memory, disk space, and network
connectivity: the reason these services are valuable is because the blockchain
is 18GB at this point, so downloading it to clients or even storing it at all
on some clients, is at minimum "egregiously painful" and sometimes "pretty
much impossible". If you want to be able to answer tons of different kinds of
questions about transactions with low latency you are likely going to be
storing this information with a number of specialized indexes, further
increasing the database size requirement.

However, "people" is also a valuable point, but no: having an open source
project doesn't solve that; if you make a program that uses bitcoin, you
either have to download and manipulate the blockchain locally (which sounds
awesome, and is arguably half the point of bitcoin to many reasonable people,
but in practice is not realistic or even possible in many if not most
interesting situations) or use a service. You can either run your own service
or use someone else's. I enjoy running services: I accept that most people do
not ;P. Instead, they would rather use a hosted API such as this one (or any
of the numerous existing alternatives to this one) so they don't have to have
people maintaining servers.

~~~
nwh
The reality though is that most people will never, ever need this sort of
information. Unless you have a particular desire to run a block explorer or
other lookup service, you are only going to be interested in addresses that
you own and not those of the rest of the network. You don't need to store
extended lookup tables and indexes for an ever increasing amount of
information, doing so is foolish as it doesn't scale at all with the size of
the network.

If a service needs to have a wallet connected to the network without the
resources for storing the entire blockchain, they can just use a SPV [0]
client like BitcoinJ to set bloom filters on their peers. They then get a
stream of trustless information that's only relevant to the wallet at hand.
You end up with a local service that's faster, completely under your control,
and has a tiny resource footprint. You could happily run that a device like an
iPhone, no problem.

[0]:
[https://en.bitcoin.it/wiki/Scalability#Simplified_payment_ve...](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification)

~~~
saurik
So, this is the first I'd heard of the bloom filter feature: the descriptions
I've seen of SPV allowed the client to only store a subset of the data, but
still needed to download everything at least once in order to have any
semblance of trust in the data it was seeing. The web page you link you also
has a "See Also" to a page that makes bitcoinj sound horribly insecure, but
maybe that's no longer the case with the bloom filter extension? This was all
written before this bloom filter feature existed (which was late October of
2012); despite that being a little over a year and a half ago, there is almost
no mention anywhere of it... I will have to spend more time learning about
this feature and see how it changes things. (Maybe you are then correct:
having a service like this is totally useless. However, I would then argue
that it should be a really big priority to make people understand that this
feature exists, is deployed, is practical, and is secure, as otherwise people
are going to keep going about their lives as I have assuming this is all
impossible with the current implementation of Bitcoin.)

~~~
nwh
Ugh, yeah the documentation for anything related to Bitcoin is terrible.
Originally it didn't use bloom filters, they're a new thing as of Bitcoin
client version 0.8 and above.

> _the descriptions I 've seen of SPV allowed the client to only store a
> subset of the data, but still needed to download everything at least once in
> order to have any semblance of trust in the data it was seeing._

With bloom filters you don't need to bother with all of that. The headers of
the blocks are separate from the transaction data itself (that's in the merkle
tree), so the SPV client can download all of the headers up to the current
date and verify their difficulty in a few seconds. As the wallet gains
addresses it sets bloom filters with it's peers, when they announce a new
block on the network they send the SPV client the block header and also a
trimmed merkle tree with only the transactions relevant to the client left in
it. The SPV client can verify that the transaction is in the block by
following up the tree to the block header, without ever needing to download
the entire thing.

Privacy is gained by setting false positives in the filter, the more junk
results the less likely it in the peer can discover what the SPV client is
really interested in and what is being discarded. The SPV client ultimately
doesn't need to store anything but the outputs that are unspent, and
transaction history if this is required. There's no trust in the peers as at
worst they can withhold blocks from us that contain transactional data, to
counter this we can connect to multiple peers with the same filters set and
compare the difference.

> _However, I would then argue that it should be a really big priority to make
> people understand that this feature exists, is deployed, is practical, and
> is secure, as otherwise people are going to keep going about their lives as
> I have assuming this is all impossible with the current implementation of
> Bitcoin_

This is a problem really, we have lots of awesome crypto features but
everybody just insists on using solutions that don't scale like
blockchain.info. The original whitepaper describes some of the scaling
features but doesn't mention bloom filters specifically I don't think.

------
wesley
Would love if you guys added Nxt to this, it's completely different from
bitcoind (it's based on java and a completely new codebase). If we had an API
that would work across completely different systems, it would add great value.

[http://nxt.org](http://nxt.org)

------
GigabyteCoin
How much do you plan on charging for the API once it exits beta?

~~~
k0mplex
We're still working that out. What do you think is fair?

~~~
GigabyteCoin
I am wanting to use it for my site's difficulty predictor.

I would be making about 3 API calls per chain every 10 minutes to suffice for
my needs.

That's about 12,960 api requests in a 30 day month.

I wouldn't be willing to spend any more than $5 on those 12,960 requests...
because if that's what it cost, I could just setup a digital ocean vps and run
the namecoin blockchain for $5/mo.

So somewhere in the order of $5/13,000 requests or about $0.40 per 1,000
requests sounds fair to me.

------
Adlai
Why has nobody mentioned Obelisk?

[https://github.com/libbitcoin/obelisk](https://github.com/libbitcoin/obelisk)

------
kolev
Decentralized systems always centralize in time.

