Announcing BCCAPI

[Mike Hearn]

Congrats on the release! Great stuff!

[1713510924]

1713510924

[1713510924]

1713510924

[1713510924]

1713510924

[1713510924]

1713510924

[1713510924]

1713510924

[lostdroid]

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

[ctoon6]

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.

[molecular]

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. 

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

[ffe]

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

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

[Jan]

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.

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

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. 

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?

I really like the idea of BCC API but am a little concerned there isn't much interest. 

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.

[Jan]

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.

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

[Luke-Jr]

IMO, you should be contributing toward a standard for wallet communication rather than inventing yet another proprietary specific-usecase protocol.

[molecular]

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.

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.

[TiagoTiago]

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

[Tril]

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?

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.

[d'aniel]

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!

[Jan]

This is great!

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

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.

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.

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.

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!

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.

[d'aniel]

This is great!

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

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.

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.

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.

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!

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

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.

[nimnul]

You should document your protocol

[Jan]

Thanks for your response.

My worry is that 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 that 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

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

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.

[Jan]

You should document your protocol

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

[d'aniel]

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.

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?

[Jan]

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.

[d'aniel]

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.

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

IMO, if we want bitcoin to succeed we need to go beyond the cloak and dagger business.

Totally agree.

Thanks again!