Is there a remote, trustless bitcoin API that doesn't require local storage?

[grau]

This might interest you too:

https://github.com/bitsofproof/supernode/wiki/API

My implementation of the protocol features a language independent (protobuf), dedicated message broker powered (STOMP) merchant centric API.
It is not yet fully tested, but it runs smoothly for months now...

[ripper234]

I don't get the requirement for instant startup. How often do you reinstall your servers? It takes, what, a few minutes to sync for the first time a newly installed server. Are you trying to run your service on a Raspberry Pi or something?

I plan to run my service on heroku. The way heroku works (similar to Google App Engine I guess), is you prepare a server image (git snapshot), and heroku can bring servers up or down as needed. When a version is updated, new servers are started, then the old servers are downed.

In this setup, I do not keep a server that is necessarily long-lived ... I do not manage the lifetime of my servers. Therefore, I wish to make the bootstrapping phase as fast as possible, and spending 0 time on blockchain initialization is desirable.

Relying on a third party site like blockchain isn't just a trust issue. You are externalizing some of your costs onto Ben. Why should he pay for a part of your server costs, for free? He might do so for now, because your site will start small and he's a nice guy, but it's kind of rude to assume that if your website gets really big he'll just pony up for serving all your API traffic.

You could also just use the JSON-RPC API on a regular Satoshi node. It's really not such a big deal.

But the details really depend on what you mean by "various operations".

APIs are meant to be used. Perhaps in a future version of his API, Ben might charge for its usage. Then, I can have the choice of either paying to enjoy the simplicity that I like, or implementing/running my own server layer that handles this API. Even if I were to host everything on my end, I might partition my servers into two kinds - stateless web servers, and a blockchain server (running bitcoinj or bitcoind). I think it just makes the architecture cleaner, and lets me create this service faster without having to build the blockchain server right now, while still letting me create it later if I need it.

[dogisland]

Hi,

I had some success deploying BitcoinJ to Heroku, I created a BitcoinJ datastore that would save the whole block to the database not just the headers. For this I used the JPA (Java persistence API).

After that I could do 2 things.

1. Transmit transactions to the network.
2. Query unspent outs (and therefore calculate balances and create transactoins).

I'd be happy to share the code with you.

[ripper234]

Hi,

I had some success deploying BitcoinJ to Heroku, I created a BitcoinJ datastore that would save the whole block to the database not just the headers. For this I used the JPA (Java persistence API).

After that I could do 2 things.

1. Transmit transactions to the network.
2. Query unspent outs (and therefore calculate balances and create transactoins).

I'd be happy to share the code with you.

Post what you have, it's always good to see some examples.
Publicly if you can, or pm if you prefer to keep it more private.

What app framework are you using btw? I'm comfortable with Play Framework which has excellent Heroku support and uses JPA/hibernate out of the box.

[dogisland]

I've uploaded to github.

https://github.com/ianpurton/bitcoinj-heroku

The main things to look at are the JPA classes which store the blockchain data.

https://github.com/ianpurton/bitcoinj-heroku/tree/master/src/main/java/com/strongcoin

The startup class is here https://github.com/ianpurton/bitcoinj-heroku/blob/master/src/main/java/com/strongcoin/StrongCoin.java

I did have to make a change to the core code of BitcoinJ as it wasn't easy to add listeners, that may have changed now, this code is over a year old.

The pom.xml in the root directory is what Heroku needs to deploy the project. Heroku will download BitcoinJ etc as part of the deployment, JPA will create the DB tables in Postgres.

I'd be happy to help fund a bounty to get this working again.

[ripper234]

I've uploaded to github.

https://github.com/ianpurton/bitcoinj-heroku

The main things to look at are the JPA classes which store the blockchain data.

https://github.com/ianpurton/bitcoinj-heroku/tree/master/src/main/java/com/strongcoin

The startup class is here https://github.com/ianpurton/bitcoinj-heroku/blob/master/src/main/java/com/strongcoin/StrongCoin.java

I did have to make a change to the core code of BitcoinJ as it wasn't easy to add listeners, that may have changed now, this code is over a year old.

The pom.xml in the root directory is what Heroku needs to deploy the project. Heroku will download BitcoinJ etc as part of the deployment, JPA will create the DB tables in Postgres.

I'd be happy to help fund a bounty to get this working again.

Thanks, interesting stuff.
Can you document the changes you made to bitcoinj and perhaps submit a pull request to the core project?
It's usually not a good idea to modify a 3rd party library directly, since you lose your update path in the process.

[dogisland]

The changes I needed to make were for listening to pending transaction, this was for an instant payment API.

So I would say this code has been battered around  a bit.

However I see it as a proof of concept.

1. It's possible to get BitcoinJ working on Heroku.
2. You can use the JPA as a blockstore and therefore use Postgres as a DB backend.
3. BitcoinJ can be configured just to track unspent outs.
4. BitcoinJ can forward transactions.

With 3 and 4, you can build pretty much any Bitcoin payment API you want. The hard part is tracking unspent outs.

[Mike Hearn]

We just released bitcoinj 0.7 which has a full pruning block chain implementation, with an example using the embedded SQL DB "H2". So you can query the set of unspent outs directly from that. Replacing H2 with a different database backend would be quite easy.

There are also more listeners and other things these days. I doubt you'd need to make many (any?) changes to the core now. So if you're still using the code I'd suggest trying to upgrade to the latest code.