Announcing BCCAPI

[amincd]

bump

[finway]

like it.

[Jan]

like it.

Thanks for the support. Lots of stuff happening with the bccapi these days. Two independent parties are working on Android apps, and It seems like they are ready for an open beta within a few weeks. For now you can try out the fully functional, secure, and lightweight example client SimpleClient here: http://code.google.com/p/bccapi/
(warning geek zone ahead)

[molecular]

Jan, a question: Is your API used by anyone as of now?

It seems to me to be _the_ solution to roll out mobile wallets.

Has the excitment about "bitcoin on mobile" I've been sensing all around ceased?

[Jan]

Jan, a question: Is your API used by anyone as of now?

So far the only generally available client is console/ASCII based. While this client is fully functional and secure, it is not meant for broader consumption (who wants to use an ASCII application these days?). It serves as an example of how you use the API to create your own client.

To answer your question: At the moment the API is used by at least two independent developers working on an Android clients. Development takes time, and many Bitcoin projects are done on spare-cycles. However, I have tested two apps and provided feedback. They are pretty far. I expect them to announce beta within the next few weeks, but this is not something I control.

I must admit that I had expected more buzz around the API, but maybe it drowned in all the scams and hacks that happened around the time of announcement. Anyway, work is being done, so lets see where this goes.

One interesting observation is that something that looks like a clone (http://www.reddit.com/r/Bitcoin/comments/lxpr0/bitventory_a_simple_secure_auditable_ewallet/) has been announced, which is great. It even contains some of my code. This shows that I am not the only one working in this direction.

It seems to me to be _the_ solution to roll out mobile wallets.

I totally agree, this is one of the 3 big hurdles on the way to hit the broader population:
1. Simple, secure & light-weight mobile clients
2. Ease of obtaining coins
3. Merchants

Has the excitment about "bitcoin on mobile" I've been sensing all around ceased?

This is hard to tell. A lot of the Bitcoin hysteria has ceased lately, which is nice. This leaves us time to develop solutions that make Bitcoin more accessible.
It is going to be interesting to see how the community receives the apps once they are announced.

[molecular]

Jan, thanks for your elaborate answer.

Jan, a question: Is your API used by anyone as of now?

So far the only generally available client is console/ASCII based. While this client is fully functional and secure, it is not meant for broader consumption (who wants to use an ASCII application these days?). It serves as an example of how you use the API to create your own client.

To answer your question: At the moment the API is used by at least two independent developers working on an Android clients. Development takes time, and many Bitcoin projects are done on spare-cycles. However, I have tested two apps and provided feedback. They are pretty far. I expect them to announce beta within the next few weeks, but this is not something I control.

I must admit that I had expected more buzz around the API, but maybe it drowned in all the scams and hacks that happened around the time of announcement. Anyway, work is being done, so lets see where this goes.

One interesting observation is that something that looks like a clone (http://www.reddit.com/r/Bitcoin/comments/lxpr0/bitventory_a_simple_secure_auditable_ewallet/) has been announced, which is great. It even contains some of my code. This shows that I am not the only one working in this direction.

Very nice to see activity is going on. Satisfying.

Has the excitment about "bitcoin on mobile" I've been sensing all around ceased?

This is hard to tell. A lot of the Bitcoin hysteria has ceased lately, which is nice. This leaves us time to develop solutions that make Bitcoin more accessible.
It is going to be interesting to see how the community receives the apps once they are announced.

I agree that all the bad news gave us time to develop. I also sense a lot of professionalizing is going on in the service sector. The Bitcoin Conference in Prague might deliver quite a push.

I assume app-reception will be slow, though, but mobile apps being available is very healthy (of not necessary) for a possible 2nd hype to happen at some point.

[MORA]

Very nice work, the blockchain is a bit complex to handle, and this project allows for a lot simpler clients, however I have found a few show stoppers.

1) You can only ever use the determistic addresses, there is no way to add a private key, from a coin or otherwise ?
2) Is there any plans to make a API call that will be able to list the balance and transactions of a public address, that you do not have in the wallet, and dont have the private key for ?

If 2) is added, this could be used as a backend for webshops to check their balance and verify payments, without having to keep the block chain them selves.

(Maybe asked before) Do you log which IP accesses which accounts ?
One of the cool things about bitcoin, as I see it, is that by downloading the blockchain, noone knows which address you are interested in, and therefore your payment gateway can reside somewhere else than the sensitive equipment.

[Jan]

Very nice work, the blockchain is a bit complex to handle, and this project allows for a lot simpler clients, however I have found a few show stoppers.

1) You can only ever use the determistic addresses, there is no way to add a private key, from a coin or otherwise ?

The BCCAPi is split into the bare API defined in BitcoinClientAPI.java, which is implemented here and a bunch of optional helper classes on top. If you want to add any public key you can either use the API directly, or you can implement your own ECKeyManager which does not use deterministic keys (This is probably what I would do).
However, there is a catch... read below

2) Is there any plans to make a API call that will be able to list the balance and transactions of a public address, that you do not have in the wallet, and dont have the private key for ?

If 2) is added, this could be used as a backend for webshops to check their balance and verify payments, without having to keep the block chain them selves.

I Agree. But... The server side assumes that the public keys added are new in the sense that no coins have been sent to them yet. This allows the server to only scan for new transactions. Otherwise the server would have to either rescan the entire block chain as you can do with the Satoshi client (expensive long running operation) or manage a database that is optimized for determining the public key -> Transaction relation in real-time, which would require a much more powerful server, more memory, IOps etc.

(Maybe asked before) Do you log which IP accesses which accounts ?
One of the cool things about bitcoin, as I see it, is that by downloading the blockchain, noone knows which address you are interested in, and therefore your payment gateway can reside somewhere else than the sensitive equipment.

Agreed. Using the BCCAPI you reveal your (IP address, public key) relation to the server. The goal with the BCCAPi is to make really light weight clients, and I don't see a solution where you can have as light weight a client, without revealing the relation of your public keys. You can however hide your IP address using proxies or something like Tor.
To answer your IP address question: I do not log any IP addresses.

The worst thing I can do is reveal public-key/IP relations and lie about your balance. If I ever did that people would quickly move their funds elsewhere. I can never run away with your coins. For a small change wallet like BitcoinSpinner I think this is a perfect.

[MORA]

2) Is there any plans to make a API call that will be able to list the balance and transactions of a public address, that you do not have in the wallet, and dont have the private key for ?

If 2) is added, this could be used as a backend for webshops to check their balance and verify payments, without having to keep the block chain them selves.

I Agree. But... The server side assumes that the public keys added are new in the sense that no coins have been sent to them yet. This allows the server to only scan for new transactions. Otherwise the server would have to either rescan the entire block chain as you can do with the Satoshi client (expensive long running operation) or manage a database that is optimized for determining the public key -> Transaction relation in real-time, which would require a much more powerful server, more memory, IOps etc.

Okay, I think that is acceptable limits, even if the addresses is not new, the API would be able to fetch the new transactions right ?
I am really only interested in transactions, not so much the current balance.

ie. Customer gets a public key to pay to, same key is being monitored using bccapi, when a transaction is received/confirmed a database is updated with current amount of confirmations.
0 confirmation = Payment received message to customer, 2-6confirmations=order accepted
I presume the API is pull only? so in a timer the client should recheck if there are new transactions for the wallet.

btw: I see in FAQ a pay version with faster server may be added, I think many would be interested in a pay service, since it should mean better survival, for now the donate link should do

[MoonShadow]

Are there any plans to release the server code so that users can set up their own servers and redirect Bitcoin Spinner to use that server?  If not, is there any plans to add the option of using Tor, so that even the presence of such a client cannot be determined?

[Jan]

Are there any plans to release the server code so that users can set up their own servers and redirect Bitcoin Spinner to use that server?  If not, is there any plans to add the option of using Tor, so that even the presence of such a client cannot be determined?

There are no plans to release the server side code at the moment. However this may change going forward.
Regarding connecting through Tor. I don't think it is trivial to do that, but I may be wrong. In the end BitcoinSpinner was designed for simplicity and ease of use. I have to be very careful when adding complex features that only a handful will use, and I think Tor would be one of those features.

[MoonShadow]

Are there any plans to release the server code so that users can set up their own servers and redirect Bitcoin Spinner to use that server?  If not, is there any plans to add the option of using Tor, so that even the presence of such a client cannot be determined?

There are no plans to release the server side code at the moment. However this may change going forward.
Regarding connecting through Tor. I don't think it is trivial to do that, but I may be wrong. In the end BitcoinSpinner was designed for simplicity and ease of use. I have to be very careful when adding complex features that only a handful will use, and I think Tor would be one of those features.

You don't actually have to change anything to the server code to permit Tor access.  You have to add a tor node to run along side your server on the same machine, and set up a 'hidden service'.  I don't claim that is an easy task, nor that it's likely to be used by more than a small minority of people unless a version of bitcoin spinner is released that uses tor natively.  That is why I asked if the server code would be released, so I could do it myself.

[ripper234]

Are there any plans to release the server code so that users can set up their own servers and redirect Bitcoin Spinner to use that server?  If not, is there any plans to add the option of using Tor, so that even the presence of such a client cannot be determined?

There are no plans to release the server side code at the moment. However this may change going forward.

Can you reconsider? Perhaps create a bounty address, and once a sufficient bounty is gathered, you'll release the code?
What would you consider sufficient compensation for your efforts thus far?

Right now BCCAPI might be the best way to build light/simple clients, but the lack of transparency of the server side is a hindrance to its usage in serious systems.

[Richy_T]

Hi Jan, I've mentioned a little about this in other threads related to Bitcoinspinner but this is actually related to the API itself so I'm posting it here.

I've been trying to work out getting mined coins to show up in the transaction history for Bitcoinspinner. The balance shows correctly but these transactions are not listed. I've been working with the source of Bitcoinspinner, adding a fair chunk of log output. By mixing up some mining and direct sending, I appear to have arrived at something of a dead end with an issue with the BCCAPI itself.

It appears that the BCCAPI does not return transactionsummary information for mined coins transactions. I have the following

I am working with wallet address 1PJjX4odnhAt6ePrPvcXxaLUxZVaUSTmGP

This currently has two transactions:

edea1cdb08252f746f57e1ac5885715295e79aeef38b8a9f6625bdc2ac4046ce

Which is a mined transaction

1620ff431acccb3ad5db05d41de89ebec9bcf328c6ba251b78e28acc2317e6e7

Which is a straight transfer.

If the app does a transactionsummary request for both of these, it appears that only one response gets returned. If individually, the straight transfer gets one item, the mined gets zero.

This actually causes a null pointer error on the emulator (though oddly enough, I have not had it on my phone which is a different wallet)

I'll add a little debugging output below. Hopefully you'll understand what's going on.

05-11 16:42:05.752: E/Blah(1890): Adding.edea1cdb08252f746f57e1ac5885715295e79aeef38b8a9f6625bdc2ac4046ce
05-11 16:42:05.752: E/Blah(1890): Adding.1620ff431acccb3ad5db05d41de89ebec9bcf328c6ba251b78e28acc2317e6e7
05-11 16:42:05.752: E/Blah(1890): Here1.2
05-11 16:42:05.752: E/Blah(1890): queryTransactionSummary
05-11 16:42:05.752: E/Blah(1890): [B@40cd9e98
05-11 16:42:05.762: E/Blah(1890): 73
05-11 16:42:08.408: E/Blah(1890): Called deserialize
05-11 16:42:08.412: E/Blah(1890): DS.17.144.0100000003830000001620FF431ACCCB3AD5DB05D41DE89EBEC9BCF328C6BA251B78E 28ACC2317E6E73E980300EFB98D510100001F29FA8D28556A3B30137DCC6BCED135E424AA9B4BAD 1A0000000000020000F4AD54C5CD955051176551A08AB4F08A0312BC3DA086010000000000001F2 9FA8D28556A3B30137DCC6BCED135E424AA9B5B63180000000000A0980300
05-11 16:42:08.412: E/Blah(1890): ==1
05-11 16:42:08.422: E/Blah(1890): Called deserialize
05-11 16:42:08.453: E/Blah(1890): DS.3.131.1620FF431ACCCB3AD5DB05D41DE89EBEC9BCF328C6BA251B78E28ACC2317E6E73E9803 00EFB98D510100001F29FA8D28556A3B30137DCC6BCED135E424AA9B4BAD1A0000000000020000F 4AD54C5CD955051176551A08AB4F08A0312BC3DA086010000000000001F29FA8D28556A3B30137D CC6BCED135E424AA9B5B63180000000000
05-11 16:42:08.453: E/Blah(1890): Here2.1
05-11 16:42:08.473: E/Blah(1890): 1620ff431acccb3ad5db05d41de89ebec9bcf328c6ba251b78e28acc2317e6e7
05-11 16:42:08.502: E/Blah(1890): here4
05-11 16:42:08.532: W/dalvikvm(1890): threadid=13: thread exiting with uncaught exception (group=0x40a71930)
05-11 16:42:08.562: E/AndroidRuntime(1890): FATAL EXCEPTION: Thread-107
05-11 16:42:08.562: E/AndroidRuntime(1890): java.lang.NullPointerException
05-11 16:42:08.562: E/AndroidRuntime(1890):    at com.bccapi.ng.async.AsynchronousApi$QueryRecentTransactionsCaller.callFunction(AsynchronousApi.java:179)
05-11 16:42:08.562: E/AndroidRuntime(1890):    at com.bccapi.ng.async.AsynchronousApi$SynchronousFunctionCaller.run(AsynchronousApi.java:60)
05-11 16:42:08.562: E/AndroidRuntime(1890):    at java.lang.Thread.run(Thread.java:856)

The Null pointer was not at line 179 in the original code (I believe it was 171 where the s is a null pointer)

The ==1 is the number of transactionsummary objects returned from the call (which would ideally be 2).

[Amitabh S]

Has anyone using this to make an online wallet?  Where is the server residing?

[Richy_T]

Has anyone using this to make an online wallet?  Where is the server residing?

From what I can tell, this is pretty tied to Java (it basically passes serialized Java objects around). Which is fine as far as it goes but somewhat limits things in terms of coding clients.

[Jan]

Has anyone using this to make an online wallet?  Where is the server residing?

From what I can tell, this is pretty tied to Java (it basically passes serialized Java objects around). Which is fine as far as it goes but somewhat limits things in terms of coding clients.

Correct. If you mimic the serialization used by the Java implementation you will be golden.
The server is running at RackSpace, and is also used by BitcoinSpinner. Right now a lot of things are shifting in this space now that the Mycelium Bitcoin Wallet is marching through its beta. Eventually the BCCAPI will be retired.

[Richy_T]

Has anyone using this to make an online wallet?  Where is the server residing?

From what I can tell, this is pretty tied to Java (it basically passes serialized Java objects around). Which is fine as far as it goes but somewhat limits things in terms of coding clients.

Correct. If you mimic the serialization used by the Java implementation you will be golden.
The server is running at RackSpace, and is also used by BitcoinSpinner. Right now a lot of things are shifting in this space now that the Mycelium Bitcoin Wallet is marching through its beta. Eventually the BCCAPI will be retired.

I'm not planning on writing a client but I would suggest you consider implementing an interface that is a bit more implementation agnostic such as XML or JSON (which is de-facto agnostic). If not instead of, then at least in addition to. Then again, if it's going away, why bother?

[Jan]

You said it.

[Kuroth]

Very cool looking...