|
Interesting project. I wish you luck.
|
|
|
|
"Watching-only" wallets/accounts. Using a deterministic wallet on an offline computer, only pass the public key of the first address and the "chaincode" to your primary (online) computer. Using some crypto-magic, this allows the online computer to generate a new address for the offline computer without actually needing any of the private keys. The private keys never touch the internet, yet you can create addresses and confirm payments from your primary computer! (The chaincode is sensitive for privacy purposes, but not security purposes--if this chaincode is compromised, someone could figure out that all the addresses are related, but can't get access to the money).
This is more or less what the BCCAPI allows you to do. The main differences are: - clients built on top of the BCCAPI upload each public key they want the server to monitor, rather than letting the server determine the public keys using a "chaincode".
- the server is not one that you run yourself.
The obvious drawback is that the server will know the relation between the public keys you upload. The big benefit is that you do not need to run and maintain a server, and the client app gets to have minimal memory/communication footprint. IMO this makes the client perfect for the mobile consumer market. Easy transfer of blockchain data to offline computer, and completed/signed transactions back to online computer. If your private key never touches the network, but it's not too cumbersome to send money from that account, BTC security gets a major upgrade.
This is what the BCCAPI does. The client can create a request (binary blob of data) for the server to return a SendCoinForm (binary blob of data) for some amount of coins. The SendCoinForm is basically an unsigned transaction. The client can then sign the form and send it to the server, which in turn validates and broadcasts it. Even though the BCCAPI was meant for Android phones you could write a simple client on top of it and use USB sticks to send the blobs back and forth. Extreme keystretching for encrypted online wallets. Your private keys are protected by encryption based on a passphrase. But in order to get from the passphrase to the encryption key, it must be hashed/mangled 10 million times. This means it will take on the order of 1-2s just unlock your wallet, which is acceptable for the user who enters the correct passphrase every time. But for an attacker, he's gotta do 10 million hashes/operations just to brute-force-check 1 key. This makes even simple passphrases much difficult to brute force, as it could take the attacker hours to test a million passphrases instead of seconds.[/li][/list]
The BCCAPI uses scrypt ( http://www.tarsnap.com/scrypt/scrypt.pdf) to achieve this, which puts constraints on both CPU and memory bandwidth, making a hardware based attack extremely expensive. Linking of phone accounts to computer accounts. Computer has smartphone private keys but won't use them unless the user hits the "HELP!" button. The wallet can then monitor/refill the phone account, and if the device is lost, the program can empty the money that was on the phone into non-phone addresses. With key-stretching above, you only need to hit the HELP! button within a 1-10 days of losing your phone to re-secure your funds.
Since the wallet is deterministic you can recreate the private keys from your passphrase on any device (phone/computer) and move the funds elsewhere. |
|
|
|
how do you force it not to force you to send the transaction fee?
With the official client you can't With older versions you can but then you run the risk of it never getting included in a block. A client built on top of the BCCAPI ( http://code.google.com/p/bccapi/) allows you to choose whatever fee you like. So far only the SimpleClient ( http://code.google.com/p/bccapi/wiki/SimpleClient) has been implemented, but an Android client is on the way. |
|
|
|
This appears to be a case of someone with more processing power working off-line and then dumping all of their blocks into the network at once.
Very interesting. Being a developer running stuff on the testnet I observed that we had a gap of about 1 1/2 days with no blocks. Pretty frustrating when you want to test stuff. At some point lurker ( https://bitcointalk.org/index.php?topic=37315.0) started mining. Great, I could move along with my testing. With current events it seems that the testnet was only mined by one big player, who for some reason was not posting his blocks for some time (be on purpose or due to software failure). This explains the long gap with no blocks, and the sudden longer chain. Excellent example of why bitcoin depends on many small miners as opposed to a few big pools. |
|
|
|
I've been mining on testnet for the last few days, trying to help things along. 45 blocks so far.  Wohoo, I'm rich...,or not. Thank you for stabalizing the testnet. |
|
|
|
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. |
|
|
|
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_retrievalEdit: 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. |
|
|
|
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. |
|
|
|
The wallet of my dreams is something I can carry around. Let's assume that it is an Android app on my smartphone. It contains a number of wallets with different security settings: - It has a wallet for small change. The wallet is always open, i.e I can always see the balance or spend coins by just starting the app.
- It has a wallet for larger sums. This wallet is closed when I start the app, i.e. I have to enter a password to see the balance and to spend coins.
- It has my vault. This is where I store my stash. This wallet is closed when I start the app. I can open it by entering a long passphrase, and wait say 10 minutes. When the wallet is open I can see the balance and spend coins.
I want this with the following features: - Feature 1. If I loose my device I want to be able to recreate my wallets on a different device.
- Feature 2. I do not want to do periodic backups.
- Feature 3. I do not want to trust a third party for keeping my wallet private keys.
All of the above can be achieved using the BCCAPI: - Feature 1. All wallets are deterministically generated from passphrases. If you loose your device you can resurrect your wallets from their passphrases plus a salt.
- Feature 2. You do not need periodic backup beacuse of feature 1. You do however need to remember the passphrases + salt or write them down. (Going forward we may even avoid this. See the wiki on Managing Long Passphrases http://code.google.com/p/bccapi/wiki/ManagingLongPassphrases)
- Feature 3. The wallet private keys are never leaving the device.
Implementing the wallets using the BCCAPI: - Wallet for small change: You already have it in the SimpleClient example of the BCCAPI. You just need to use an empty PIN and turn it into an Android app.
- Wallet for larger sums: You already have it in the SimpleClient example of the BCCAPI. You just need to turn it into an Android app.
- Vault: You already have it in the SimpleClient example of BCCAPI. You just need to reinitialize the wallet from scratch from a passphrase and salt, and never store the root seed on the device. This way every trace of your private keys are only ever in memory.
Of course each wallet should use be based on different passphrases. Read my wiki on the Security of Deterministic Wallets: http://code.google.com/p/bccapi/wiki/SecurityAndDeterministicWalletsApart from this the app should be able to scan QR codes containing receiver's address, display my own addresses as QR codes, have a nice UI and so forth. All of the above is also available here: http://code.google.com/p/bccapi/wiki/TheWalletOfMyDreams |
|
|
|
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 |
|
|
|
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/00000000006473df1d4700f6c5d78d4bba1590ce92bf348c5b6c4e6c830356adMaybe 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. |
|
|
|
Just ordered 1 BTC through btcnow.net. I'll keep you posted Got 2 confirmation emails: 1. "Order recepit" from Google Checkout 2. "coins sent" from pierce403@gmail.comGot my first confirmation. My 1 BTC is safe. Now, what is really baking my noodle is how it all worked without me entering my credit card numbers. I must have done a purchase using google checkout before. However, I don't remember this :-) |
|
|
|
Just ordered 1 BTC through btcnow.net. I'll keep you posted Got 2 confirmation emails: 1. "Order recepit" from Google Checkout 2. "coins sent" from pierce403@gmail.comGot my first confirmation. My 1 BTC is safe. |
|
|
|
Just ordered 1 BTC through btcnow.net. I'll keep you posted Got 2 confirmation emails: 1. "Order recepit" from Google Checkout 2. "coins sent" from pierce403@gmail.com |
|
|
|
Just ordered 1 BTC through btcnow.net. I'll keep you posted |
|
|
|
Or if you are dead set on the actual testnet you could set gen=1 in your bitcoin client for the testnet.
I can't imagine the difficulty is too high in the testnet.
I will have to try that. I am not a miner and can only mine using my CPU. I am pretty sure that the difficulty is too high for me to go anywhere like this. Is it time to restart the testnet? The testnet fauchet is also running dry and only giving out 0.11 BTC pr visit. |
|
|
|
You can use testnet-in-a-box to solve this. It can be mined with CPUs as it's minimal difficulty.
Yes. I have been doing this in my summerhouse for a few weeks where there was only sporadic edge connection. And it works very well. Problem is if you want ppl to test the stuff you have built you are not going to ask them to set up their own test-net. |
|
|
|
There we have it. 24 hours with no blocks. This makes it hard to develop experimental software. No more striking, miners get to work! |
|
|
|
|
Show Posts
