Bitcoin Forum

I have successfully transferred bitcoins into my head.  They can't be hacked.  They exist nowhere but in my head.  If I die, they die with me.

As crazy as this sounds, it's true.

I simply picked a passphrase, and turned it into a bitcoin address with my open source Casascius Bitcoin Utility (available from github).  When I want to spend the funds, I will simply use the same passphrase to generate the same private keys, import them into a real wallet.dat, and then spend them.

What's my purpose in making this point?  While the entire Bitcoin community is reeling over the loss of Mybitcoin.com - not just the site, but the realization that keeping bitcoins in a web wallet is fundamentally flawed - I really want to pound in the idea that bitcoins can be kept on paper and in the form of codes or passphrases.  And when people do this, the bitcoins cannot be hacked.

Every sentence you can think of, corresponds to a Bitcoin address.  The bitcoin address can be given out freely, the sentence is the password that allows spending of bitcoins.  Once upon a time, I stored 0.25 bitcoins in the sentence "This string contains 0.25 BTC hidden in plain sight."... others were successfully able to retrieve the 0.25 BTC given the sentence.

The future of practicing safe Bitcoin is for people to be able to keep their private keys offline.  If you operate a Bitcoin-based website or exchange or are working on client code, please, for the future of Bitcoin, include the ability for people to enter and redeem the funds off of hand-typed private keys.

EDIT: Added, per suggestion, a reminder that any time you import Bitcoins from a private key into the current Satoshi client and spend less than all of them, you should spend the rest to new addresses, or at least back-up the wallet.dat.  This is because the portion you didn't spend (the change) gets sent to a brand new address that exists only in wallet.dat, and will be lost if you don't keep it safe.

I dont trust my memory. At all.

Not even to remember the opening line to your favorite childhood cartoon?  Or the motto of a group you belonged to?  Simply take a sentence you already know from memory, and add a few words to it (like "big fat ____" or "____ in the bed" or the name of a favorite artist etc.)

If not your memory, certainly you can use a piece of paper, or whatever you do to keep track of your regular passwords!

Only on Windows
*nix users, look at pp2k.py http://github.com/jackjack-jj/pp2k

iwearcoloredcodedbvdssize34to36

mygirlfriendlikesto(insert your own words here)withme

ithinkmywifeischeatingonmehencethisbitcoinstash

if2plus2equals4thenwhyisthegrassgreen

ilikeu238special3doorsdownandb52s

And you say this idea is sound? I agree!

It's useless without the key!

http://www.creditsnacks.com/photofiles/simpsonscreditcard.jpg

are private and public keys case sensitive? if they are not then i could probably eventually memorize 1 key pair.

Nice, just wait till a "Mind Reader" gets a hold of it  ;D.

This XKCD strip (http://xkcd.com/538/) comes to mind.

"I want a big mac and large fries to go, but only if you accept bitcoins via passphrases like this"

"oh wait, double that order, please"

"yes its me again. still accepting bitcoins via passphrases like this?"

"the usual, please and thank you"

etc

-MarkM- (Darn, I forgot the password from Saberhagen's "Octagon". Chapel Perilous? Something related to that...)

I put a bomb in the blockchain, prepare to be stricken with alzheimer's

Could you explain the process behind those apps?

I'm thinking of using a different type of wallet along with my Safebit wallet, one that will allow users to move addresses from place to place rather than them being attached to a singular wallet file, which I find extremely inefficient and quite simply a stupid idea in the first place when you can store individual addresses and manipulate them directly.

You don't memorize the keys themselves. You memorize a string whose hash is the private key. You can use any algorithm to convert the string to a key that you like, case sensitive or case insensitive.

Exactly.

Every private key is just a 32-byte hex number.  Every 32-byte hex number can be used as a private key.  And hence, every 32-byte hex number has a corresponding Bitcoin address.

Just by coincidence (or perhaps not), the SHA256 hash algorithm can produce a 32-byte hex number from any text input.  And while the output isn't predictable, it always produces the same output given the same input text.

So the idea is just to pair these two ideas.  Pick a passphrase, compute the SHA256 of it, use that as a private key.

All the Casascius Bitcoin Utility does, is calculate the Bitcoin address that corresponds to your 32 bytes as the matching private key.

You aren't remembering the private key itself, you're merely remembering the text that will produce your private key when plugged back into the SHA256 hash algorithm.  Which is good enough.

(When using Casascius Bitcoin Utility / SHA256, the passphrases ARE case sensitive by the way)

I'm sure one of bitcoinporn's private keys will be generated by inputting Canticles 1:13 into this key generator.  ;D

That is bloody brilliant.  I mean, really, really, really.

Bloody brilliant!  Given a popular and accessible conversion utility and interface...well.  I have to go outside and breath slowly now.

Too bad that your hacked computer immediately after putting your keys in the 'real wallet.dat' already has transferred all your bitcoins to the thief's wallet before you were able to touch any key!
 :P

If you'd temporarily store your passphrase in a file and execute (in Linux) the following

gpg --print-md sha256 <file with passphrase>

would that do the trick also?
I'm not sure how to input the passphrase through the keyboard into gpg, but that would be much better.

Anyone that understands the principle involved here isn't likely to be the kind of person to have insecure interfaces.

Did you run that past a cryptographer first?  I haven't read FIPS 186-3 in detail, but I seem to recall that ECDSA keypair generation involved more than tossing a bunch of bits together.

Also, did you test this?

It is a well-known and well-understood property. Yes, ECDSA keypair generation does involve more than tossing a bunch of bits together. You follow the normal ECDSA keypair generation process except instead of generating a random private key, you use a hash.

To an attacker who does not know the input to a hash algorithm, the output of that hash algorithm is effectively random.

It's a well-known property of ECDSA. It has been used to transfer bitcoins. (You can actually do it with RSA as well, it's just more complicated. You must use the hash to seed an agreed-upon PRNG.)

Yeah, I have some bitcoins in my head too.  This is what I talked about with ThoughtCoins a few weeks ago:

https://bitcointalk.org/index.php?topic=29187.0

Just remember that the entropy (read: cryptographic strength) of even a long passphrase with numbers and symbols is quite a bit lower then an actual private key.  In other words where it is impractically to search the entire key space of private keys it is possible to search the passphrase keyspace looking for valid wallets.  Whereas the encryption of your wallet file with a passphrase requires access to your encrypted wallet to try to brute force your passphrase, a passphrase only wallet or ThoughtCoins as I called it requires nothing, anyone can start brute forcing that keyspace right now.  Nevertheless, choose a good passphrase, and bitcoins in your head have some very interesting properties, as I discussed in my thread.

Information on the entropy of passphrases: http://en.wikipedia.org/wiki/Passphrase

j

Absolutely. You want at least 128-bits of entropy in the passphrase to provide security comparable to what ECDSA is already providing. Note that you can increase the number of effective bits by using a more complex algorithm, such as multiple iterations. You'd still be vulnerable to rainbow tables.

To be clear though, if your passphrase has 128-bits of entropy in it, such that an attacker would need to try on the order of 2^128 passphrases to hit on yours, this scheme is no less secure than straight ECDSA. (Except that both people know the private key, so either can claim the funds.)

So who takes the prize for being the first person in history to store money in their mind?

;D

Say HI to address collisions. :)

After some trying I found a SHA256 hash generator for Linux:

$ gpg --print-md sha256 < /dev/stdin<Enter>
   <your passphrase><Enter>
   <Ctrl-D><Ctrl-D>

which gives the same results as

$ gpg --print-md sha256 <file><Enter>

where <file> is a file containing <your passphrase>

and also the same results as

http://www.xorbin.com/tools/sha256-hash-calculator (http://www.xorbin.com/tools/sha256-hash-calculator) in which you type:

<your passphrase><Enter>

Only if two people use the same passphrase. Obviously, if someone you can't trust knows or can guess your passphrase, you are doomed.

I am not sure rainbow tables would be a concern. Rainbow tables would help someone get your passphrase from your 32-byte private key, but they don't even have that. They don't even have your public key either if you have never sent funds from the address. 

'123456' is pretty common :D

Sure, but good luck grabbing a large number of coins out of that one's resulting address, what is its average time until next checked for coins by rainbow corp or whoever does the rainbow stuff?

-MarkM-

Edit so anyway, obviously we need to use "123456" (or whatever we manage to memorise as our hash type cypher passphrase) to generate a table of 256 distinct hash routines, so that our hash type selection phrase's hash can be used to look up hash routines to use to hash our actual phrase. Thus forcing users to use 123456 three times in a row, which would result in...

This sounds pretty awesome. Do you have a direct link to this utility?

Thanks!

Are people really gonna be imaginative enough with the phrases for the risk of collision to be negligible?

<smartalec>
That prize was probably awarded centuries ago. Early stock markets worked that way, traders just kept the transactions of the day in their heads. They'd be written down and/or directly executed only after the market closed.
</smartalec>

My program refuses passphrases below 40 characters or 7 words, casascius should do that too...

But it's not just random jibberish with good variety of low and high caps, numbers, symbols etc, people are gonna use words and phrases that tend to make sense

That and you have to wear a tinfoil hat so the government can't read your thoughts from space...

Yep
I will force users to use some special characters

Cool, so am I to believe that I can use this method to generate a bitcoin address and then use it for transactions? If so... you win the internet for the day and I will donate 0.05btc to you (hey it's better than nothing).

That's not the way they would do the attack. They would build a rainbow table of a few trillion passphrases and the corresponding bitcoin addresses. Everytime a new bitcoin address appeared in the hash chain, they would check that address against the rainbow table. If they found a match, they would derive the private key again and claim the funds immediately.

Yeah, mine does that too.
The rules aren't exactly the same, but close.  And if you mix symbols, uppercase, and lowercase, and numbers together, it will let you do a somewhat shorter phrase.

While I wouldn't put it past anyone, that rainbow table is going to be ridiculously slow to build to the point of near infeasibility.  The operation of deriving the public key from the private key, as I'm sure you know, is super expensive in CPU time.

You only need to do it once. But yeah, trillions is going to be awfully tough.

Okay so I have no problems generating a SHA256 hash, personally I would use multiple hash algo's on my passowrd pharse which included a key , then I would Vigenere Encrypt that, or Xor then MD5 hash that and then finally SHA256 the result to generate a custom SHA256 key. now my question is how do I use that generated SHA256 hash in the bitcoin client as a wallet address? I have only just started using the bitcoin client as a wallet since mybitcoin problems. Could someone explain how to use a custom generated SHA256 key as there wallet address in the bitcoin client please?

https://github.com/jackjack-jj/pywallet

$ echo your mom | sha256sum 
6e96e45029870a9b08cff2ed6ac840ccde3edce244327cc1bddefa1e555bc81f  -

The 'echo' command, by default, puts a newline at the end of its input. You can suppress this behavior with '-n'. (You can do it either way, but this may explain why different tools might given different results.)

So let me get this straight. You can create a private key with a passphrase import it into a wallet. Transfer funds to it and then delete the wallet.dat and recover it by repeating the process?

yep

Effing sweet! What are the odds of someone using the same private key. I've actually been wondering this for a awhile. What is someone just tries to hoard all possible private keys? Or is it the keypair that matters?

Hey,
I'm quite new to bitocin so I just wondered: why are they several private keys stored in a wallet.dat? Given what you explained, you only need to know 1 private key, right?  :-\

its soposed to give more anonymity. however i find it pointless, and would rather the client just make a new address when requested.

Yes, that's much better than my 'solution', thanks!

Thanks for the addition, very helpful!

No. Once you spend your coins from the imported address, the change will be returned to a new address stored in your wallet. If you delete it then, you will lose everything.
What you have to do after the import, is to send the entire remaining amount back to your chosen address in a new transaction.
.

You don't have to import the key to transfer funds to it, and should not do it

I hope alternate clients consider addresses more like accounts (with change returned to the same by default) and move this non-deterministic 'wallet' as an optional part of a greater laundering/anonymity regime. The wallet with newly generated keys is a major source of confusion and the anonymity provided is a joke. Only geeks 'get it' - everyone else has to learn the hard way.

I think it would be wildly cool to pass a slip of paper "The dog barks at midnight 3879273". The ultimate swiss bank account. Or "Congratulations My Son 8360324" or "Bitcoin gold parity. I told you so. Haz Haq Hah! Pennies for the poor."

Oh, by the way, deletes any trailing spaces in "your mom", "your mom ", "your mom  " etc.

$ echo -n " your mom        " | sha256sum 
888eb5c57140830728b64def5c3d9230f8b7f8d6567814542a92259be16e6007  -

Ok  ;D

Question sneakily inserted: Is the ownership of the file blk0001.dat the same as that of the file blkindex.dat?

(I thought I might as well ask that in here as you guys seem to know everything anyway, and my question isn't being answered where I originally posed it (https://bitcointalk.org/index.php?topic=35553.msg439855#msg439855).)

The answer to Indio007's question is "yes in theory", but with the current client, the answer "no" is correct to the extent that the change is likely to go to a newly generated address.

I'd be willing to bet that "pywallet" either does, or could be trivially modified, to fill the unused keypool within wallet.dat with hundreds or thousands of pre-generated addresses that can be derived from the passphrase so the bitcoin client didn't have to.

One passphrase can seed thousands or millions or any number of bitcoin addresses, all of which can be recovered with the same passphrase.  If passphrase is "my passphrase", then the first address is based on "my passphrase1" and the second on "my passphrase2", and the millionth on "my passphrase1000000".  IIRC, bitcoind only adds keys to the key pool if the number of keys in the pool falls below 100.  If you used a deterministic wallet generator to generate a wallet.dat with 10,000 addresses - most of them going into the key pool - you would probably never need to worry about the change going to a new address.

How about "Is Bargle with you?"

http://2.bp.blogspot.com/-Xol0oNRs-vo/TbFxOK23w_I/AAAAAAAAAg0/pazrEHDvpNc/s1600/Kill+Bargle.jpeg

It would be REALLY cool if the bitcoin client could do this whole process automatically. Don't even have a wallet.dat flile; just have the user input a passphrase that will automatically convert to an SHA2 hash and store in memory throughout the session. Bloody brilliant idea, OP.

I do worry about accidental duplication of passphrases, though. I would want to come up with one that combines an easy to remember phrase, some arbitrary data (DOB, birthplace, mother's maiden name...), and some random data (Rand()).

What I did when I stored bitcoins in my head was create a passphrase and a pin number.  The pin number represents the number of times to run SHA256.  I now only remember the "first bits" to the public address, the passphrase, and a pin.  I have my savings account now that I've confirmed it several times with different pass phrases and smaller amounts.  To avoid the change problem I always send the entire balance out, and send change back in manually.

I think it's pretty secure.  Nevertheless it is very easy to hack with a rubber hose... just saying.

Anyone know of a calculator for passphrase entropy?

j

Yeah, just tell me your passphrase in PM and your entropy is 1 bit.

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

In a centralize authentication system (bcrypt) the required work effort can be increased periodically to keep up with Moore's Law. However, the bitcoin keys already publicly visible in the block chain can not be later 'upgraded'. A key based on a passphrase is only as strong as the passphrase. A username as seed is essentially just a new passphrase' = passphrase+username.

That is not to say I think a deterministic seeded wallet is a bad idea. Indeed it would decentralize the client wallet! I see two use cases: (1) a transferable one time "swiss bank account" (bitbills) and (2) a truly deniable deterministic personal wallet.

if somebody pmed you their password, would you not have 0 bits of entropy?

Maybe you're right. I was thinking about the possibility that the password is false.

You need to take a closer look of what these commands produce.

for example produces a completely different string than the one you get at https://bitcointools.appspot.com/?s=test&r=1 when you enter the passphrase "test"

"F2CA1BB6 C7E907D0 6DAFE468 7E579FCE 76B37E4E 93B76050 22DA52E6 CCC26FD2"
versus
"9f86d081 884c7d65 9a2feaa0 c55ad015 a3bf4f1b 2b0b822c d15d6c15 b0f00a08"
!

The newline.


Good demonstration of the avalanche effect (http://en.wikipedia.org/wiki/Avalanche_effect), no?

Exactly.

Every private key is just a 32-byte hex number.  Every 32-byte hex number can be used as a private key.  And hence, every 32-byte hex number has a corresponding Bitcoin address.

Just by coincidence (or perhaps not), the SHA256 hash algorithm can produce a 32-byte hex number from any text input.  And while the output isn't predictable, it always produces the same output given the same input text.

So the idea is just to pair these two ideas.  Pick a passphrase, compute the SHA256 of it, use that as a private key.

All the Casascius Bitcoin Utility does, is calculate the Bitcoin address that corresponds to your 32 bytes as the matching private key.

You aren't remembering the private key itself, you're merely remembering the text that will produce your private key when plugged back into the SHA256 hash algorithm.  Which is good enough.

(When using Casascius Bitcoin Utility / SHA256, the passphrases ARE case sensitive by the way)

This guy just started using Bitcoin after coming to this forum and only reading this thread:

http://www.oweiss.com/blog/wp-content/uploads/2010/02/guy-of-numbers_03_s.jpg

Pretty cool.

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.

I wanted to point out this thread


He’s building a web site that keeps part of your wallet but, crucially, not the secret keys. The secret keys are kept in your client on your machine.

He refers to this thread as a source of ideas for his web site.

I’d like to applaud the combination. A web site that enables mental bitcoin wallets. The web site would:

•   Keep an up to date block chain.
•   Keep a list of all your public keys and their balances.
•   Respond to balance queries from the client
•   Accept fully signed transactions from the client and transmits them over the bitcoin network
•   Pushes a vanilla JavaScript client to the user’s browser

The user client would:

•   Be a phone app or a JavaScript client that downloads from the web site (would normally be catched)
•   Accept your name and password and locally create all your keys (mental wallet as described in this thread)
•   Query the web site for the balances on the keys
•   Allow the user to send coin by creating signed transactions and sending them to the web site for publication.

Notice, the user has no need to trust the web site. Also this client is an excellent candidate to be written as a phone app since it has no need to deal with the block chain.

Well, the web site would have to be trusted to at least SOME extent... to:

• Not have been rooted and be serving malicious content placed there by a hacker
• Serve the javascript client that it claims it serves, rather than serving something that collects the password...
• Tell the truth about what transactions are in the block chain when asked

• A server that lied about the value of a particular input transaction (by understating it) could convince a client to sign off a transaction that was actually worth more than the client thought it was... assuming the client had a check to confirm it was signing a transaction for the amount it was told, the extra funds could still be concealed as a large transaction fee
• A server could lie to the client about how many bitcoins he really has, making him think he has more than he does, by telling the client about past transactions that have already been spent, without telling the client about the transactions that spent them... the client will be convinced and have no way to verify, it just won't be able to produce a valid transaction to spend those coins

[/list]

I agree about the javascript. It could cost you your coin. Maybe you should get your client from a trusted source. (Wait! circular logic here. Are we saying the only trusted client is the original one?)

The rest is just maliciousness for the sake of evil. The site can't steal your coins if you're careful and would quickly lose credibility if it tried those things.

Still, much better than the e-wallet solutions that are out there today.

(emphasis mine)

Be careful using common phrases... collisions could be costly.  I personally will only use this technique after I develop my own custom preprocessor for the passphrase before passing it to the sha256 algorithm.

Guess I should have read the rest of the thread first ;).

I really wish MtGox would just offer a paper bitcoin wallet generator (either random or from a passphrase) where you could just print your paper wallet straight from MtGox.  And a corresponding function to redeem private keys back into your MtGox account.  The same with every other trusted Bitcoin bank-like site.

MtGox is already halfway there with their "MtGox codes" but those require the BTC to be kept in MtGox and can't be taken anywhere else.  How nice if the average joe could just print a paper wallet, send their BTC to it, and stash it in a safe.

With just two functions, people could keep all of their bitcoins offline until the instant they want to spend them, mooting the need for many things like wallet encryption in the client, or long step-by-steps on how to TrueCrypt, or how to rescan wallet.dat.  In fact, that pretty much moots the need for the average joe to ever bother downloading the bitcoin client in the first place unless he wants to mine.

Perhaps I need to offer my paper bitcoin wallet generator in a free web-based edition.

Please, please do.

You could generate the wallet from a fingerprint or retina scan.

Don't forget to throw in some of those cyborg patrols and self-aware laser turrets and we're set.

Well, I'm off to the hologram theatre now, see ya later folks!

the use of biometrics as security (and sometimes identification for that matter) is typically a bad idea.

Some biometric locks are surprisingly easy to crack

83 posts and only one post about how using this method can lose all your bitcoins because the change gets sent to a different address that gets stored in the wallet.dat that is generated when using the paper/wetware-stored key in the client. 

Or is that just FUD, 'cause it seems an important detail and shouldn't be glossed over.  How about a disclaimer at the top of the thread like: Warning using this technique improperly, even once, could result in a loss of all your bitcoins

Am I totally off base here?  It seems rather scary to attempt this technique with any large amount of btc.

I think the key advantage is that hackers could not break into the website and steal Bitcoins (like in the MyBitcoin case). Yes, the could install malicious code, but that would be noticed quickly and the damage would be far less. Also the website could go down and no bitcoins would be lost (like in the bitomat case).

In the case of memorizing it is better to have a simpler but longer passphase than to have a shorter but complex one. The idea is to pad your passphrase to a long length with a certain character.

So you could have easy to remember passphrase like:
buzz123$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

which is quite simple but strong simply because it is so long.

Nice job man!
Correct me if I'm wrong, but it would further increase security to use numbers and special characters.  This could avoid a cracking algorithm that tests patterns based on a dictionary.

eh, id use a pattern like

password314password314314314314314314314

easy to remember, and is long, with padding that is also easy to remember.

As a safety measure, I edited the original post to include this warning.

These aren't very good.  They lack entropy and are relatively easy to crack.  Rather than being a strong password, these are merely passwords that depend on the cracker simply omitting trying these low entropy passwords.  Imagine I chose "β" as a password.  It's arguably super-strong if I depend on the assumption that crackers won't think to try Greek letters, but very weak if I turn out to be wrong.

The BCCAPI is now available: https://bitcointalk.org/index.php?topic=36892.msg453652#msg453652

It'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.

Owning your own wallet.dat and having the bitcoin client running on your own machine is absolutely fine for the technologically inclined, but this methodology is totally at odds with the mainstream.

Normal people have big problems with security on their home PCs, they routinely forget even basic passwords or write them down and stick them on the fridge. Most have trojans of some kind installed, and email phishing scams frequently work because the general public is too dumb to realise when they are being scammed. Having mainstream users look after their own wallet.dat and be completely responsible for the security of it is a recipe for disaster.

In addition to that, the home desktop is becoming a thing of the past. More and more people just have a home laptop, a work desktop, a smartphone and maybe a tablet too where they access the internet, so the idea of a computer which is always on is totally alien to many, let alone one that has to be on so they can access their bitcoins and spend them.

People are getting used to having their Gmail wherever they are, and being able to log into their online banking, Paypal account and so on from any device, regardless of whether there is a particular service running on their home network at that particular moment.

If we are to make Bitcoin a mainstream success, the only way to do so is with web-based or cloud-based wallets (accounts) which users sign in and out of like their Gmail or Paypal accounts. We must have sites like mybitcoin, but ones which are trustworthy and secure.

One setback should not deter us from the goal of simple to use, web based Bitcoin wallets. We must not shy away from learning from the mistakes of others.

No Shit Sherlock. 
Your post is totally off-topic. 
Problem is in personnel, funding, and insurance for such a project.  For starters. 
But please go find another thread among the many that are already discussing this, like in Project + Technical Development.  If you can code, it is open source.  There has been an outstanding 1000 btc bounty for an android bitcoin app for a long time. 

OP is talking about something totally different for very advanced users.  Keeping an off-computer piece of information that can be used to store bitcoins.  Joe six-pack is never, ever going to use this technique, so don't worry about it.

I flicked to a page about Kevin Mitnicks life on the run and it mentioning `tweaking the hash` ... tweaking a md5sum so that the hash remains the same even after alteration...  might this effect this somehow?

You mean accidental collision of distinct passphrases? Not in your lifetime.

Given a KNOWN hash, it has been shown in very specific circumstances that some carefully modified plaintext message can generate the same hash result. But that is not relevant here, simply because the target hash is unknown. If it were known, you'd already have control of the bitcoin balance.

Mental wallets are probably the worst idea I've ever heard. There is no less reliable way to store data than a human memory other than writing it in chalk on the sidewalk. A simple memory lapse is all it takes for you to lose your coins, and you'll literally go crazy trying to remember.

And what happens if you die? Your wife / kids / girlfriend or whatever can't access your Bitcoins, they are lost forever! You have to strike a balance between absolute security and accessibility.

I think the old ways of security are often the best. If I had a significant number of Bitcoins, I'd have passwords, hashes, private keys and so on with full instructions on how to access the funds that anyone could follow both printed out on paper & stored on a couple of USB keys and locked in a safe, with backups held in a safety deposit box in a bank somewhere in case my house burned down.

I would prefer to use this passphrase generation and write it in a paper that I store somewhere. People have to know:

1) That text contains bitcoins
2) How many times you do the hash to obtain the private key.

Seems better than bitbill's bitbank.
You could even write: "Old testament chapter X line Y", or "bitcoin whitepaper, last 210 characters". And then read in the book/text to redeem the coins. Or just take some random book at home and underline a paragraph.

I like the idea, but I don't like to memorize.

Some people can remember a lot very accurately. I don't have the best memory myself, but I reckon I could manage a phrase or two pretty easily.

What about remembering a chapter number of a book you have and using the first paragraph?
The passphrase would be much secure.

That's quite clever. You could have "Page 3 Paragraph 5 Sentence 4" written down on a piece of paper, and even if someone found the paper they wouldn't be able to crack your password unless they knew which book you were referring to...

...or the last letter of every line. Assume every page of this book is a potential key and you don't write anything down at all. History is littered with similarly cracked methods. No matter your method, if you can't trust your friends, family or self, your bitcoins will die with you.

Yes, but if your family doesn't know what your printed QR-code in your drawer is, your bitcoins are also going to disappear if you die.

Exactly. I think a memorized 'travel wallet' is perfectly fine. But one really needs to print a deterministic 'savings wallet' and including it in the will (or a ceramic piggie bank).

I kind of like the idea that the bitcoins disappear with their owner: it's like a donation to the bitcoin community since the value of the remaining bitcoins is increased in proportion of the lost coins.
That's the beauty of a limited money supply combined with infinite divisibility.

The technique is only appropriate for holding coins to be transferred whole. Once the coins are claimed, they are no longer stored in a "mental wallet", period.

That is true for the current implementation of the C++ client, which, considering it's still beta is not a trivial point. Alternate change output is an unintuitive hack which fails to create anonymity but successfully creates confusion and lost coins.

EDIT: Demonstrating the point are 3 of 4 posters on this page with a presumably static bitcoin address in their signature.

Are you saying that sending change to a fresh address is useless because some people will publicly announce their address and reuse it?

I think his point is that people will continue to use the same receiving address even after they've transferred some coins from it, leaving some coins at their known account and some at various accounts unknown to them. This makes it very hard for human beings to know what they need to protect in order to be assured of not losing their coins.

I think he applauds the mental bitcoin idea. He's only bitching that the 'might lose coins after spending' problem is a problem with the client, not with mental bitcoin wallets. Rather than warn people about the numerous ways they might lose coins after sending, the client might instead return change to the sending address by default, just as anyone would intuitively expect.


In order for mental bitcoin wallets to be well supported, standard clients will need to (a) return change to the same address or (b) deterministic wallets where the 'key' is really a seed or (c) some other brilliant yet unknown to me feature or (d) continually explain the 100 key pool problem to users after they've lost their fortune polish bitomat style.

You're right.
For the piggie bank you can leave precise instructions so family can redeem the bitcoins.

casascius, is there any way you could compile a Windows binary for your bitcoin address utility.  :-D  I am not a techie, and although I MIGHT be able to figure out how to compile it myself, there's a good chance I'd fuck it up.  Similarly, I have to wait until bitcoin v0.4 comes out before I can take advantage of the import/export private keys patch (assuming it's included in that build).  But when the official client does have the capability to import new keys, having your program so that I could create addresses out of my own password would be very very handy!  I'm just not enough of a computer guy to do it myself--even though I see that the ability is out there...

Sure.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

btcaddress.zip SHA256 hash: 6475b20ab235ea685b73ef117283aaf0c8d9f021dd0a3434dfc6e7ab7f0da3d5

http://www.casascius.com/btcaddress.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJObU1dAAoJEFou6PHxF1ojUqIIAInIKSS8aitXDHANGtBfeQbi
SUejbeqsiVtLZsPzSeC4jdWCYfOSXfAMbo0Lg3IXMgHLZjlJCTSK7tRElMwBYAwm
zscUPpJnA7mv9fziAZjAzcluJ+WMuHiINvZeiTWEFVhZdSXnWdm1T1kLO7gJdjww
4wVD+fiZJkTqi6Asgs0nreDDNTv051e+U9gnEkBfB+k8kJedFiUGsmiFQZGyPTVd
lnRMursoWX9wHnZ6C/7xsJKf/nW6++9Y8YIVHdjiMvC6UE/Ai7Pi6vh2BQNSEatk
iazs6w7htVcUlo0OMX1AxTN1R4JDNHak6F/ueEOgOZEeyaMDjoECj7tlPFM532A=
=xzg7
-----END PGP SIGNATURE-----

Words cannot describe how grateful I am, so here's a picture accurately representing it.

https://i.imgur.com/42hQ6.jpg

Assuming a dumb user who uses a simple password (this is always a starting condition for designing any system) this means that when they pick their bad password, they will eventually lose all their money to someone who just brute forces it.

I could see just using a large random alphanumeric string for the seed for the wallet, so in essence a user could just copy their entire wallet by just copying that string.

You could have a client that when it starts up it generates the string, or asks if you already have one. At that point, bang, you have any number of addresses at your disposal. If you want to backup, all you need is the seed string for the client. If you want to move (or keep in sync) with another client, you just copy the string into it. A client could handle multiple wallets, each with their own string. Your wife and you (or a group of people in an organization) could share a joint wallet that both have the same string, but you would each also have your individual wallets.

Your wallet becomes a minuscule line of text. The only thing that might add some weight is if you use an address book.

This is a valid concern, even for the example passphrases given.

If the passphrase has ever been published on the Internet, it may cost a suprisingly small amount to determine if any substrings on the the Internet (of limited complexity) correspond to a public address in the block-chain when hashed. If you use a dictionary word, you have no chance: it does not take any special hardware to check.

You only need 3 things:

• The ability to buy CPU time (https://aws.amazon.com/elasticmapreduce/).
  
• The ability to break the problem into small parts (http://aws.amazon.com/articles/1632).
  
• Access to a copy of the Internet (http://search.slashdot.org/story/11/11/15/0057200/common-crawl-foundation-providing-data-for-search-researchers). (The block chain is easy to get a copy of.)
  

Now the SHA-2 function is likely expenive enough, as is the address conversion, that simple queries will likely cost more than $100. However, I would be surprised it the cost rose more than an order of magnitude larger (Read: $10,000 budget, not including coding time).

That is why the passcode itself shouldn't be something the user created, and is some very long string. Though this isn't a mental bitcoin wallet, it makes for a very easy to copy, sync, backup, and even printout and archive wallet.

Just for fun I may eventually take a common top 1000 passwords list create addresses based up them, and see if they ever pop up as being funded.

http://2.bp.blogspot.com/-BkERaIBlD58/TdbdMFiLmtI/AAAAAAAAAos/mAj_QioBHnA/s1600/johnny-mnemonic-1995-06-g.jpg

If the blockchain gets any bigger you might get a nose bleed!

Then your head explodes.

http://3.bp.blogspot.com/_25NR6PyWRhg/TJ-fXMNpllI/AAAAAAAAALg/qCCAVFMdyd4/s400/scanners.jpg