Chain, the Blockchain API for developers
chain.com
chain.com
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.
"People." Why don't you write one instead of just criticizing theirs from the sideline?
Sometimes companies need enterprise support, service level agreements, and outsourced business processes in order to focus on their core businesses. We will be seeing lots of non-currency related Bitcoin startups who sell services related to the blockchain. Either crawling it, or utilizing it for contracts / trades.
Introducing new paradigms are not always as simple as changing the playing field in one step. These centralized services are a good thing. They introduce to the playing field an entry point for the layperson who doesn't want to deal with the headaches, learning curve and stresses of doing things themselves. When they feel a burning need to take the reins, they will be able to, and will take the time to learn how, and no bank or government will be able to stop them.
Also, I wonder how much they paid for that domain.
C'mon we need better than this. You can do better than this!
For inspiriation: - https://www.parse.com/docs/rest - https://stripe.com/docs/api
$ curl https://GUEST-TOKEN@api.chain.com/bitcoin/addresses/1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp
{"hash":"1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp","balance":-7706880,"received":101730741984389,"sent":101730749691269,"unconfirmed_received":6750000,"unconfirmed_sent":0,"unconfirmed_balance":6750000}It's not like they are providing access to the Twitter firehose or the Google Search Index, which you couldn't have otherwise.
Edit: people are really downvote-happy on HN lately. You should not put a reasonable comment in the negative just because you disagree.
Can you point me to a ready-to-use address indexer for the blockchain, that can run on a lightweight server and only consumes a few gigabytes of data?
Chain.com is something I have been hoping to see for quite some time now, personally.
I run a "Bitcoin service", it calculates the future difficulty level[0], it's just not all that important to require the constant running of a full bitcoind node.
After I completed the Bitcoin version using the blockchain.info API, I realized there was literally no stable API for Namecoin and was forced to place the namecoin difficulty estimator on hold.
The minute that Chain.com implements their namecoin API, I will be subscribing.
Not because I don't have the competance to build and run a crypto coin daemon 24 hours a day, 7 days a week. I simply know that it's a waste of resources for my current needs.
Good point, but there are local tools that appear to provide the same functionality as this site: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) http://bitcore.io/
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
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.
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.
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.).
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...
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.
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.
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...
> 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.
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.