27 comments

[ 2.3 ms ] story [ 71.4 ms ] thread
Nice looking site :) But, doesn't Blockchain.info already offer a developer API?
Glad you brought this up. Prior to building helloblock, I built a couple of other open source apps (tippercoin / sparecoins) which used the blockchain.info API.

There were a few problems that I encountered. Blockchain.info is focused on consumer and their API is structured to back their consumer facing sites. As such, they have no testnet support. This is a deal breaker. Because that means, any integration tests come at a tangible financial cost.

Furthermore, their API has always been a documented internal API rather than a public one. That meant, there is no versioning on the API and they sometimes make breaking changes without deprecation notice. The lack of versioning caused a bit of issues.

And in general, I found the API is set up in a way that is, frankly, a bit strange. For example, instead of a status code of 400 for an client side error, they generate a 200 status code with an error text in the body. That also caused issues for debugging and error handling too.

In the end, the various quirks finally led us to build this API.

You forgot another reason. I've been trying to run several businesses on the BlockChain.info API and it's just plain unreliable. Funds forwarding and notifications of transactions can take hours and that's just not acceptable if you're trying to run a business.
Do you mean the HTTP webhook for notifications of transactions?
Yes, but only with the transaction forwarding feature.

They offer a free service where you can give their API a destination address and a webhook and they'll give you back a individual deposit address.

You can then give that deposit address to your customer. In theory, the customer is supposed to make the payment, Blockchain.info sees the transaction, notifies your webhook, and forwards the payment to the destination address.

The problem is that the system that looks for the transactions sometimes doesn't see them for hours and the webhook isn't notified until the payment is swept.

For example, one of my customers transactions was this one. https://blockchain.info/address/1PD8c6fjiYT4Hdq3SFavLBGNgV1B...

The money was received but it took 2 hours and 15 minutes for my webhook to be notified that payment was received and for it to be forwarded. In the meantime, the customer who was told that the transaction would be approved after 1 block confirmation was furious.

This seems to happen about 30% of the time with their API.

We are about to release a webhook feature which you can register your deposit addresses (you can also set it at a predetermined confirmation count). That way at least you will get notified immediately (so you can confirm it with your customer). although the forwarding is still up to blockchain.info to be timely. Contact us over scott@helloblock.io if you are interested.
Why don't you just .... use Bitcoin Core. Or bitcoinj, or any API that doesn't rely on third party infrastructure?
I'd be curious to have your perspective on the risks of relying on 3rd party infrastructure. That 3rd party can't really try to feed wrong blocks or transactions, it would ruin its business. Then from a practical standpoint, the only attack it can run is a Sybil attack which, when not spending any transaction, can't result in double-spends. So what do you see as a problem relying on 3rd party infra for Bitcoin development?
The OP was complaining that blockchain.info has outages (which it does), so there's one reason. But more generally, the whole point of Bitcoin is you don't have to rely on trusted third parties. You might as well say, "the bank can't really try to gamble with your money, it'd ruin its business". But it happens! Now block explorer sites can't gamble with your money, but they can do plenty of other things. The assumption that they won't do problematic things because it'd hurt their business is just as weak. E.g. what happens if they start charging you fees?

But more generally I wonder why people are doing this. If your app really needs indexed access to the entire block chain, you probably designed it wrong. If your app doesn't, then you could as well use local software.

Ya this is really slick looking. There are some issues here and there but it's a new site so that is to be expected.

The close tie in with testnet is a nice touch. A lot of developers seem to forget that testnet is there to help them.

Do you plan on trying to farm additional details regarding transactions such as estimated originating IP address or known address labels?

We already collect that information about relaying IPs (although you can never really be sure who is the originating IP). We have custom nodes that specifically listen for that information. However, we decided this wasn't useful enough to be included in the versioned API.

Although, we are about to release labs.helloblock API, which will include a bunch of experimental features, including information about IP addresses.

Out of curiosity, what do you plan to use information about IP addresses for?

I work in digital forensics so information like an IP address can be just another piece of the puzzle. It's not something we would base our entire case around but I'm sure it would be helpful in some way.

I certainly understand that it is just an estimate though, thanks to the beauty of the btc network in general and other fun tools like tor and your own transaction relay.

As a consumer of the API, I can attest that the developers of HelloBlock have a put a lot of thought into the API. Developers of Bitcoin apps might find the Testnet faucet particularly useful: https://helloblock.io/docs/ref#faucet
In particular, these endpoints are designed to be used as part of the 'before hook' in your integration tests so that you can start with fresh testnet coins in every test.
Do you have any plans to offer the API for altcoins as well?
Which altcoin would you like to see support for?

Although, given the similarities, if we can probably support all the popular altcoins if we do decide to extend support.

Honestly, none in particular at the moment and yet also any that's needed. I just see a situation where if I did need to work with two currencies, having an API for one and then building the infrastructure in house for the other seems silly, especially since most alt coins are literally clones of each other.
That is true. I can certainly see that.

If enough developers want support for altcoin. I think that wouldn't too hard to do

> Which altcoin would you like to see support for?

In all seriousness, dogecoin. I'm interested in the kind of apps where low transaction fees and a tipping-oriented culture are necessary.

They are clearly a mac shop - their CSS requests the 'menlo' font only for their code examples.

Looks like Times Roman on everything I own :)

Those poking around the blockchain might also be interested in coinsecrets.org which shows all OP_RETURN metadata on the main blockchain as well as testnet.
I took "Show HN" out of the title. "Show HN" is for products and projects that readers can play with now, not just sign up for.

Edit: That's the principle, but it didn't apply to this case. I reverted the change.

I'm posting comments like this for two reasons: for greater transparency, and so you all can tell me when I get it wrong. There is too much material on HN for anyone to evaluate it all accurately, so we're relying on you. Our goal is to have the best stories on the front page.

dang, this is not just to sign up for.

The project is actually fully functional. The link links to the front page, but if you see the top tab, you will both the API documentations and the blockexplorer.

So everyone can try the product now? In that case, I'll put it back. Sorry for getting it wrong in your case.

It's often difficult to make this call, but I do think it's important that HN distinguish email signup and fundraising posts from things people can actually play with.

I'm going to make this thread drop to the bottom to clear the way for on-topic comment. Best of luck!

Have you put any thought in to enabling CORS?
That should already be supported. Are you having issues?
Nope, I haven't tried, I was just looking for a quick answer without having to try it out myself!

Thanks for facilitating my laziness. :)