Hello Jan and congratulations for this project, I'll watch it very close  I would like to better understand this: Deterministic private keys 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 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.
|
|
|
|
will any server software be released to the public, so we can run internal servers.
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. |
|
|
|
You should say "Zero backup needed", otherwise it sounds like a negative point.
Good point. Fixed. |
|
|
|
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?
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. |
|
|
|
I have been working on a java library for some time now, which allows you to create a bitcoin client that works along the lines you describe. The technique of spending CPU cycles on deriving a seed is also called key stretching. I am using Scrypt ( http://www.tarsnap.com/scrypt/scrypt.pdf) for this purpose, which not only requires CPU cycles, but also demands a certain amount of memory for its calculations. This makes hardware based brute force attacks much more expensive and less practical, as the chip will require too much cache memory. I am expecting to have the first version of the library publicly available within a week. The BCCAPI is now available: https://bitcointalk.org/index.php?topic=36892.msg453652#msg453652It's a Java library for making secure lightweight bitcoin clients. All keys are deterministically generated from a passphrase and a salt. There is no wallet.dat to backup. |
|
|
|
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! Thanks. There is a text-based client that You can test right away: http://code.google.com/p/bccapi/wiki/SimpleClient |
|
|
|
In what stage is this project?
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/ |
|
|
|
The BCCAPI ( Bit Coin 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/WhatIsTheBCCAPISupport the BCCAPI: 143SikKpjzwhBy5Z7Qg5knu5nKXWExSqQi |
|
|
|
I'd like to re-propose "shadow wallets" that use this idea.
An objection I’ve heard is that the user can be negligent and use weak passwords. This, of course, is a weakness of any cryptographic protection of keys or wallets. The true objection is that there is a transaction out there in the public block chain transferring coin to your key that is subject to a dictionary attack. A thief could scan the block chain for keys generated by weak passwords. He’s not targeting you in particular, but, given human nature, he will harvest a few if this method of generating keys gets popular.
Using a salt and increasing the time / work required to check each key would help. I propose the following functionality for the client:
• By clicking a “shadow” button, the client is instructed to put aside the main wallet and create a “shadow wallet” at any time.
• The shadow wallet resides in RAM and is never put on the hard disk. It is actively cleared from memory when the user is done with it and switches back to the main wallet. (Any tricks to keep it off the swap files during memory management should be used.)
• The shadow wallet is created by generating 1000 keys seeded from a user passphrase as described below. The idea is the user can go to ANY bitcoin client he trusts (on any machine he trusts) and bring up HIS shadow wallet by typing in his passphrase.
• The client runs through the block chain populating the key balances when the user swaps in a shadow wallet.
• The salt has to be something unique to that user but is doesn’t have to be secret. I propose the salt be a hash of his full name. This is something he will never forget yet it is enough to thwart a scan of the block chain against a dictionary looking for weak passwords. The attacker would have to target YOU in particular to know what salt to use when checking keys.
• To increase the work load on the attacker, I propose picking a HASHCOUNT that is the number of SHA256 hashes a typical CPU can calculate in 120 seconds.
• The INITIALSEED is calculated as SHA256(passphrase, fullname, HASHCOUNT) and the final SEED is calculated as HASHCOUNT repetitions of SHA256(SHA256(SHA256 … SHA256(INITIALSEED))))
So the user has to remember his passphrase and his name. The attacker will despair because each key in the block chain he checks will take him a minute to check against a SINGLE GUESS from his dictionary that may be 100,000 entries of common passwords. This is for an attack against a SINGLE USER that the attacker is targeting because each user will have a different salt.
This architecture completely solves the problem of protecting your standard wallet cryptographically someplace. (As a fall back for people who like to have a thumb drive in hand, you can have a tool generate a very strong passphrase and protect that encrypted on the thumb drive. Nothing at all to remember since with a super passphrase you can leave the fullname null.)
I have been working on a java library for some time now, which allows you to create a bitcoin client that works along the lines you describe. The technique of spending CPU cycles on deriving a seed is also called key stretching. I am using Scrypt ( http://www.tarsnap.com/scrypt/scrypt.pdf) for this purpose, which not only requires CPU cycles, but also demands a certain amount of memory for its calculations. This makes hardware based brute force attacks much more expensive and less practical, as the chip will require too much cache memory. I am expecting to have the first version of the library publicly available within a week. |
|
|
|
|
Satoshi's paper is vague, and doesn't provide much detail. I consider it a concept paper. The bitcoin client is the real source of truth.
|
|
|
|
|
Post a link to a site that uses it so we cab see some samples.
|
|
|
|
It would be a better idea to put them into a bounty for badly needed projects to help solve problems of wallet theft and wallet loss for the average user.
Eg. A user-friendly, secure liveCD or live USB drive configured for automatic online backup.
+1 There are several high priority obstacles for bitcoin. Why not make a bounty for the first person/group that solves them? - 1. Convincing 10 new merchants to accept BTC.
- 2. Make a secure/useable android/iPhone wallet.
- 3. etc...
|
|
|
|
For the last two weeks every larger fall in value has been followed by an equivalent rise in value after it, only a bit slower (taking hours instead of minutes). I figured it was boomerang-like with a reasonable chance, and therefore safe to invest in.
Now the bitcoin has fallen from ~17 to about ~16.5 and it looks like it's slowly falling further instead of rising ? What do you figure is going on and why, and when will it be back to 17+ ? And should those who have BTC sell out in expectance of an even greater fall or wait for it to rise ?
If I were the holder of many a bitcoin and I wanted to turn a significant portion into USD, I would not sell everything in one big splash, as this would significantly lower the prices. Instead I would use Dark Pools, where my order doesn't show up, and I would only sell a little at a time. This makes room for other ppl to buy while I am selling, leaving the price at status quo. If several entities are doing this move at the same time we see a slow decline in value. I could imagine that this is what is happening right now. This is a fair thing and a natural phenomenon in an open market, especially after what we have experienced over the last few weeks. Over time this will evaporate, and we can continue 'normal' business. My personal hope is that BTC stabilizes at some level and has a slow growth over time. Be it 5$, 10$ or 20$ a coin, I don't care. What is important is stability so we can get merchants and 'normal' people into bitcoin. My own investment in BTC is about 200$ at 20$ a coin, and some mining. I am here in the hope of being part of the revolution of online payment. |
|
|
|
|
Let's assume that you have completed a block. You have the opportunity to include any available unconfirmed transactions.
Would you as a miner choose not to include transactions with no fee?
Probably yes.
Would you as a miner choose not to include transactions with low fees, and only take transactions with high fees (for suitable definitions of low and hisgh)?
Probably no.
If you choose not to include transactions with low fees you will earn less from your block, leaving a higher bounty for the next block. You would bacically ignore a free lunch.
|
|
|
|
Send it to the US government, with a big red stamp that says 'TOP SECRET'.
+1 |
|
|
|
|
testnet-in-a-box almost works for me with the current bitcoin client on a windows system.
Observations:
I can start the two clients on the same windows box (two processes running).
Only one of them has a UI, and the other is headless until i stop the first.
The first client correctly displays 192 blocks and 3650 coins, and the second zero coins.
The -deamon option seems not to make any difference.
Issuing the getinfo command gives me a dialog "error: couldn't connect to server"
Is testnet-in-a-box only supported on a Linux system?
|
|
|
|
|
Request for Whitelist. See my postings, I am new to the forum, but also serious to get started developing an alternate & secure bitcoin client.
|
|
|
|
So how about source code resources? I am a developer and have some ideas for an alternative type of bitcoin client. Instead of writing everything from scratch I would like to reuse as much as possible. Here is what I have so far: |
|
|
|
|
Show Posts
