Bitcoin Forum

The BCCAPI (BitCoin Client API) is a java library designed for making secure light-weight bitcoin clients. The BCCAPI connects to a server that holds the block chain, and which tracks the client’s wallet balance. The server only has knowledge of the clients public keys, and is in no position to spend funds owned by the client’s wallet.

Features include:

• Deterministic private keys
• No backup needed. No wallet.dat file
• Low bandwidth
• Low CPU usage
• Server cannot spend your coins
• Open source
• Free service, running on donations

Simply put the API is designed for making it easy to create light-weight secure Bitcoin wallets for handheld devices.

The sources include a very simple console based client, that shows how to use it. I am not an Android developer, and my hope is that the community will pick this up and make some great apps.

More information and the source: http://code.google.com/p/bccapi/wiki/WhatIsTheBCCAPI

Support the BCCAPI: 143SikKpjzwhBy5Z7Qg5knu5nKXWExSqQi

Great stuff, might be "the thing" to build smartphone apps on. Wallet on the phone with blockchain on server is the best combination IMO. In what stage is this project?

This looks pretty cool, nice work :)

I doubt I'll have time to make an Android client from this, but I'd be more than happy to test one!

The project is in the beta testing stage. There is a text-based console client implemented on top of the API, which allows you to connect to the production net or test net, and send/receive coins. I know that text-based UI sucks, but UI is not what I am good at. I need an Android developer grab this and make a cool app.

More info: http://code.google.com/p/bccapi/

Thanks.
There is a text-based client that You can test right away: http://code.google.com/p/bccapi/wiki/SimpleClient

I've added this to the Bitcoin wiki's client page:

https://en.bitcoin.it/wiki/Software#Bitcoin_clients

I copied and pasted the description you provided here.

Thanks, looking forward to some useful clients now.

This looks very interesting! Thanks for releasing this.

Can you say a little bit more about the server side? Is that part open source as well? And is it based on the Satoshi client or have you reimplemented the Bitcoin protocol yourself for the server side?

I've been waiting for somebody to create something like this for a while. I expect that eventually it will be commonplace for people to use clients that are retrieving the blockchain from elsewhere rather than downloading and storing it on their computer.

The server side uses BitcoinJ for keeping track of the block chain. While developing the server side I have found a few bugs in BitcoinJ, and have participated in fixing those for everybody's benefit. The server side is however not as clean and well documented as the client side, and I am not ready to make the server side open source. At least not yet.

Beautiful. Thanks for doing this!

now this is exactly what i wanted to be made, and you done it. (although my idea was never original in any way)

You should say "Zero backup needed", otherwise it sounds like a negative point.

will any server software be released to the public, so we can run internal servers.

Good point. Fixed.

No. At least not yet.My top priority is to get an easy, stable and safe way of handling bitcoins. And who knows, maybe I can make a dime or two on providing this service going forward. As noted on the wiki, my goal is to provide this for free, and running it on donations. If this is not enough for paying the Rackspace bills I may add the option of paying a small fee for getting connected to a priority server, which provides faster/extended service.

Hello Jan and congratulations for this project, I'll watch it very close :)

I would like to better understand this:
While I find this a very intriguing concept, does this means that the password can't be changed?

I mean: if the password is leaked may I simply change the password or the needed procedure is to create another wallet and transfer the funds there?

Thanks

There's a thread on deterministic wallets. Basically this prevents the lost of wallets as long as you have the original private key, every subsequent key can be regenerated from it, unlike the current process.

The drawback here is the possibility of your transactions being monitored (and possibly abused) once somebody manages to figure out what is yours. As always it's a trade-off between security and convenience.

Sorry, but the answer got quite long, please bear with me.

There is both a passphrase, salt, and a password (or PIN if you like) in play.

First time you start the client it asks for a passphrase and a salt. The passphrase should be long, secret and hard to guess. The salt should be a value that is easy to remember and preferably unique (I suggest you use your email address, which has these properties). The passphrase and salt are used for calculating the seed for a pseudo random number generator (PRNG). This calculation in complex and takes about 2 minutes on a decent Android device, and a few seconds on a standard desktop computer. It is based on Scrypt (http://www.tarsnap.com/scrypt/scrypt.pdf), which is designed for being hard to brute force using dedicated hardware.

Once the seed is calculated we can go ahead and generate private keys using the random generator. The nice thing about the PRNG is that if you use the same seed you generate the same series of keys. So the only thing we need to backup is the seed. Since the seed is generated deterministically from the passphrase and salt we do not need to back it up as long as we can remember those values.

Now, entering the passphrase and salt every time you launch the client is cumbersome, and on a slow device it will take rather long time to calculate the seed. Therefore the SimpleClient asks the user for a password (which could be shorter than the passphrase), which is hashed with the salt and used for encrypting the seed. The encrypted seed is stored on the device along with the salt. Next time the client is launched it simply asks for the password and decrypts the seed.

So how come the password can be shorter than the passphrase? The password can only be attempted brute forced if the seed file is leaked (stored on your device). The seed or passphrase+salt can be attempted brute forced once someone sees one of your transactions. However if the passphrase is long enough and your salt unique it will take until the end of the universe to do so.

Short answer:

• If your passphrase + salt is leaked anyone can get to your bitcoins. (The passphrase is not stored anywhere in the SimpleClient)
• If you password is leaked you are safe as long as your encrypted seed file is safe. Change your password and you are good. (The password is not stored anywhere in the SimpleClient)
• If your encrypted seed file is leaked you have a window to move your coins to another wallet. It will take some time to brute force your password and reach the seed. You need to create a new wallet using a different passphrase.

Using the BCCAPI you can make a client that does not store the seed at all. This is uber secure as everything is handled in memory. However, the user will have to enter the passphrase and salt every time the client is launched, and spend the time it takes to calculate the seed. This could however be an option for a client with two accounts.

• The one with small change, which uses a short password.
• The one with large amounts, which uses a long passphrase + salt.

Hmmm. Salted seeds, yummy!

Joke aside: this is awesome, Jan! Hadn't heard of the deterministic wallet idea up until now. It makes huge sense and seems secure to me.

It was clear something like this had to be done. Congrats and a donation for actually doing it!

Congrats on the release! Great stuff!

This thread seems to have gone a little quiet.  Are people interested in this service?  I've spent some time over the last few days working on an Android client.  Currently my app shows a page for generating a wallet from passphrase, salt and pin.  Once that's set up the app simply prompts the user for a pin.  When successfully connected the current balance and addresses are displayed.

I've wasted a bit of time last night and today with issues with the testnet but now I've managed to get some test bitcoins I want to work on sending bitcoins.  I really like the idea of BCC API but am a little concerned there isn't much interest. 

Cheers,

J

now that i look at it, it seems to be trying to do too much.

its asking for salts and seeds and stuff, a normal person will not have a single idea of what that is and just forget it.

really in an ideal world, it would simply just respond to queries for amounts of coins associated with an address, and accept signed transactions to send into the network.

I think there is a lot of interest for an app like that. Can you try to make it work on Android 2.1?

There's a lot of interest. I'm busy testing the text client and thinking about recommendations to pass back to the author.

This is great! Can't wait to see in action!


Unfortunately the bitcoin testnet is not very reliable. We have had 44 hours without any new blocks until finally this one appeared: http://blockexplorer.com/testnet/block/00000000006473df1d4700f6c5d78d4bba1590ce92bf348c5b6c4e6c830356ad
Maybe it is time to reset the testnet?


Look at the feedback on this thread so far, I am pretty amazed. You shouldn't worry, it takes time to absorb stuff like this.

Ideally there should be no passphrase, salt, and PIN or whatnot. Ideally there should be no hackers or bad guys in general.

There is a fine line between having a portable bitcoin wallet that is secure and one that a normal person would use. We need to find that sweet spot. I have written a wiki with an idea on how to get rid of the passphrase + salt without compromising security: http://code.google.com/p/bccapi/wiki/ManagingLongPassphrases

IMO, you should be contributing toward a standard for wallet communication (https://en.bitcoin.it/wiki/Wallet_protocol) rather than inventing yet another proprietary specific-usecase protocol.

you could call these 3 important things:

• your email-address (the salt)
• your PUK (the seed, STORE THIS SAFELY (both safe from theft and safe from loss)
• your PIN (your PIN, not so bad if you forget it, device asks for PUK and takes 2 minutes time, then you can enter new one)

If you can manage your SIM-card, you should be able to manage this.

Most SIM cards users i've seen had it unlocked at the store and never even acknowledge the existence of PINs and PUKs...

This is the reason why there's no one on testnet, because it can be reset.  Why not use namecoins, ixcoins, or i0coins?  You can buy a lot for a small amount of BTC and they won't disappear from a reset.
namecoin: https://exchange.bitparking.com/main
ixcoin: https://ixchange.bitparking.com/main
i0coin: https://i0exchange.bitparking.com/main

I don't see an exchange for testcoins, so maybe ixcoin isn't completely useless.

This is great!

I'm wondering how you plan to deal with requests from law enforcement for transaction history/identification?

Will you charge per request/is this part of your business model?

Not saying these are necessarily bad things, as it's pretty much the norm.

If it's not part of your business model, then do you have any plans, or know if it's possible to make your server unaware of transaction histories, and unable to map identities to transactions?

I'm not a developer, and have no idea how this would work, but PIR comes to mind.  Any thoughts on that?

Thanks for the great work!

On the server side an account is:

• a public key, identifying the account.
• a bunch of public (wallet) keys for each account.

There is no user data, just public EC keys.
The transaction log is the block chain. Everybody has it.


I am trying to run the service for free, paying bills on donations. However, going forward I may introduce that you can pay a small amount to get your account moved to a priority server with better response times and no limits on the number of account keys etc.


What is PIR?
The server knows very little about the end user which is not already in the block chain. I have no ideas as to how I can further reduce it.

Thanks for your response.

My worry is if the server will know which public addresses are derived from one another, and thus be able to link them all to a single pseudonym or identity.  Or if they are all linked to a single account on the server.

"A private information retrieval (PIR) protocol allows a user to retrieve an item from a server in possession of a database without revealing which item they are retrieving."

Edit: here's the link http://en.wikipedia.org/wiki/Private_information_retrieval (http://en.wikipedia.org/wiki/Private_information_retrieval)

Edit: Also worried if addresses can be linked by the server because their balances might be queried in batches, or by the same IP address.

You should document your protocol

The server side is well aware about which wallet public keys are linked to what account public key. This allows the server side to:

• accumulate the wallet balance and return a total.
• grab transactoin outputs sent to different addresses and combine them into new transactions.

If you are worried about this you could use several accounts and one key in each. However, this would greatly increase the bandwidth usage of your device and a heavier load on the server. Furthermore you should somehow make your requests come from different IP addresses (Tor) and not make them come in a bundle.

While using PIR might be a solution, it also introduces a big communication overhead.

Both methods defeat the purpose of the BCCAPI, as it should be light-weight in terms of communication and battery life. In the end you would be better off downloading the entire block chain to the device.

The BCCAPI is open source: http://code.google.com/p/bccapi/
This wiki puts some of it into words: http://code.google.com/p/bccapi/wiki/WhatIsTheBCCAPI
The API that the server implements is a simple interface: http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/api/BitcoinClientAPI.java
The client side implementation of that API is here: http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/core/BitcoinClientApiImpl.java

Too bad it won't work here, PIR seems really neat.

Since the server will indeed be carrying data that'll surely be valuable for law enforcement then, I'm wondering what country you operate in, and what your policy will be for requests from law enforcement for user data?

The servers are running at Rackspace US. If there is a lawful request/warrant or whatever I will have to comply unless I want to go to jail. Unlike many services out there I am not hiding behind Tor and nicknames. IMO, if we want bitcoin to succeed we need to go beyond the cloak and dagger business.

Sounds good.  Just wanted make sure you plan to assert your users' legal rights.
Totally agree.

Thanks again!

bump

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)

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?

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.


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

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.

Jan, thanks for your elaborate answer.


Very nice to see activity is going on. Satisfying.


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.

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.

The BCCAPi is split into the bare API defined in BitcoinClientAPI.java (http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/api/BitcoinClientAPI.java), which is implemented here (http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/core/BitcoinClientApiImpl.java) 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

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.

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 (https://bitcointalk.org/index.php?topic=52674.0) I think this is a perfect.

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 :)

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.

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 (https://bitcointalk.org/index.php?topic=144347.0), but the lack of transparency of the server side is a hindrance to its usage in serious systems.

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.


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

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 (https://bitcointalk.org/index.php?topic=53353.msg2528161#msg2528161). 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? :D

You said it.

Very cool looking...

Ha. I just realized that I am adding fuel to a thread I started two years ago. In Bitcoin land that is a very long time. Now that I am at it, please bear with me.
I am on my way home from a bitcoin meetup in Copenhagen, 3 1/2 hours each way.
Since the BCCAPI was announced 2 years and 4 days ago we have seen numerous attempts at starting Android wallets on top of it. The most successful being BitcoinSpinner.
We have all learned a lot about what in my mind was an experiment, at least back then. Now everything is different.
Bitcoin has gained tenfold or more in value. Well funded companies are shooting up all over. As for mysels, I have quit a sunning carrer in IT (at VMware), gained 10 pounds, my wife hardly recognizes me, and my children do not know who I am. Never the less, I have had the best time of my life doing what I am best at: developing great Bitcoin software.
What I am currently working on: The best mobile wallet on the planet (https://play.google.com/store/apps/details?id=com.mycelium.wallet&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5teWNlbGl1bS53YWxsZXQiXQ..)
What the future brings? I don't know, but I am sure it is going to be interesting and something with Bitcoin.

What did the last two years of bitcoin life bring to you?