Bitcoin Forum

http://bitcoin.stackexchange.com/questions/7697/is-there-a-remote-trustless-bitconi-api

This question (http://bitcoin.stackexchange.com/questions/2333/is-there-a-remote-bitcoin-api-that-doesnt-require-anything-to-be-stored-locally) asks about how to work with bitcoin via an API without requiring a local blockchain. The only answer (http://bitcoin.stackexchange.com/a/3991/78) is about blockchain.info's JSON API, but it appears that unlike the web version of blockchain.info, the JSON API requires the account passwords to be sent to the server.

Is there another remote API that allows one to perform various bitcoin operations without compromising security - without sending private keys anywhere, but rather signing transactions locally?

If I recall correctly then Stratum was supposed to be this API. Did it ever take off?

FYI SPV is of course not the answer I'm looking for, I'm interested in a client API that can just turn on, not download anything, and work.

Hi ripper234,

It doesn't answer your exact question but I thought I would mention it anyhow.

If you don't mind including a headers-only blockchain (currently 23.7 MB) you can get pretty close with bitcoinj now that bloom filters are available. (Uses bitcoind v0.8.0rc1 + bitcoinj v0.7-SNAPSHOT).

You can:
1) connect to whichever bitcoinds you like.
2) use fastcatchup to 'topup' your headers only blockchain (very quick).
3) set up a bloom filter for whatever you are interested in (very small bandwidth, quick)
4) send tx as you like.


It is not exactly trustless as the bitcoinds could 'overfilter' your tx of interest but with judicious use of a PeerGroup I think you could get round that (if you want to be completely trustless you are going to end up with a bitcoind I think).

The code to do all this is in bitcoinj/ MultiBit already so you could just take it and use it. No development required.

There is also BCCAPI (http://code.google.com/p/bccapi/), the server backend to BitcoinSpinner.

Interesting, didn't know of the blockchain tx transmission API. That might be an excellent answer.
I think bitcoinj will suffice, don't need a bitcoind for that (I'll be working in Java/Scala, so bitcoinj is a perfect fit).




Stratum (https://en.bitcoin.it/wiki/Stratum) is a proposal for an open source client-server "Overlay" protocol that enables thin clients (currently used by Electrum client).




Interesting, if the server was open source it would be a perfect fit.
I asked (https://bitcointalk.org/index.php?topic=36892.msg1532380#msg1532380) whether the server code can be open sourced.




Hmm, very interesting but I'm not sure this is sufficient.
I want to build a service that needs to do bitcoin tx, and I would want to architect it so it is as simple as possible.
The simplest architecture I can think of is having just a stateless set of web servers with a bitcoin client library (a-la BCCAIP). I want the servers to be able to start as fast as possible from zero previous data/state. While downloading 23.7 MB might be "almost instant", a pure stateless client library is even better.

I guess that out of the approaches above, perhaps the best one is:

1. Using blockchain.info for queries
2. Using bitcoinj to sign transactions (http://bitcoin.stackexchange.com/questions/7708/how-do-i-create-an-offline-transaction-in-java-to-broadcast-via-blockchain-info)
3. Using blockchain.info broadcast API to broadcast transactions

Blockchain.info is such a huge service that I can trust it to be reliable and secure - I can trust that it won't lie to me and its servers will be up 99.9% of the time.

And if you don't want to trust blockchain.info, you can always set up your own Abe server.

Abe server? What is that and how do I set one up?

https://en.bitcoin.it/wiki/Abe

But, is it just a browser, or does it also come with a way to push transactions to the network?

Ah, you are right about that.
I use a bitcoind and its api to create, sign and push transactions to the network. I use Abe to fetch unspent transactions.

Hmm, we have different definitions of "huge service". Blockchain.info is a site run by one man, if I understand correctly :)

You don't have to download the headers every time the server starts, obviously they can be saved to disk.

Try playing with MultiBit. It starts instantly. The need to fetch headers only happens at startup.

Well, huge compared to most other services in the bitcoin world (regarding number of users / transaction volume), and certainly larger than any service that I might start that relies on it.

How will MultiBit help? I think bitcoinj with SPV mode is very close to what I'm looking for ... still, I prefer the instant zero-blockchain-download that is blockchain.info

The main architectural difference between using blockchain.info and one based on bitcoinj/ MultiBit is whether you want to rely on a single server backend or the Bitcoin network as a whole.

Using one server backend is simpler, but you have a single point of failure.
blockchain.info is pretty high availability but it does occasionally go down for short periods.

(This is the same if you use BCCAPI - though I think that is multiple physical servers now at the backend - or your own ABE blockchain server).

Using a more distributed approach is more complicated but as there are working examples that are MIT licenced you don't have to do the dev work to take advantage of the network.

It does not give you your zero bytes starting point though. Only you can decide which of the various design factors are more important for your target application.

One approach you could take is to separate the various areas of:
+ blockchain/ tx reading
+ tx signing
+ tx transmission

So that you can change which service you use in each area (perhaps have multiple services you transmit the tx to for redundancy).

I don't think its possible. You need to store your private keys somewhere.

Either locally, so you need local storage.

Or remote, so you need trust. At the very minimum, you need to trust that the remote storage does not go away.

I will store my private keys in my data tier of course, but I was referring to storing the blockchain/SPV data, that needs constant updating and can't just work instantly when the server is up.

Well, I'm relying on a single logical endpoint, but that endpoint indeed can have multiple backing servers. I don't believe that blockchain.info runs on a single server.

I would like to separate the concerns - I want my app to focus on the business logic, and not on maintaining a blockchain - the other alternatives mentioned at this thread will probably do a better job at this than I am ... I have no reason to believe I'll have less downtime than them.


I think of opting to use blockchain.info as my backend as separating my concerns and focusing only on what's important for my app. I can always change the layer that access the blockchain later, and setup my own Abe/bitcoind/bitcoinj server if I need it.

I think bitcoinj is currently the best approach at trustless operation. However, you'd still need to download at least the blockchain headers plus relevant transactions on each start.

You can cut this down dramatically by using checkpoints. However, for this to work you need to update your client with the latest checkpoint data from time to time. Which is of course technically local storage again. Or trust, if you are bootstrapping your client from a remote server each time.

This class from the android app may be of some help https://github.com/blockchain/My-Wallet-Android/blob/master/src/piuk/MyRemoteWallet.java. It uses the blockchain API and BitcoinJ to sign locally.

Thanks, look promising - I'll take a closer look when I start implementing.

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?

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".

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...

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.



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.

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.

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.

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.

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.