(this response is a little OT from OP's thoughts, but regardless) That pretty much works, except that you have to mark the one address that's created before the password is added as unsafe, because it's already been saved unencrypted to the hard drive. It's also not very user-friendly, compared to creating a wallet that's encrypted before ever being saved.

You could be right: nobody knows if this experiment called Bitcoin will stand the test of time.

Regardless, if you're sick of bitcoin, my advice to you is: leave. (Please leave.)

One other note regarding bip32.org: if you have a good source of randomness, it's probably safe to use this page. Please read and follow the advice here first: https://en.bitcoin.it/wiki/Paper_wallet#Producing_safe_paper_wallets

For ideas on a good source of randomness, this thread talks about good ways to shuffle a deck of cards to get good randomness out of it: https://bitcointalk.org/index.php?topic=682842.0. Don't come up with your own scheme to create randomness, though. There are many things which seem random, like mashing on a keyboard, which have very poor entropy.

I'm sorry, but this reply is providing more problems than solutions. Hopefully someone more knowledgeable on the state if BIP32 software will come along and help...

Re bip32.org: I'm not familiar with them, but I took a quick look. They are producing BIP32 brain wallets, which is something you really don't want.

Re terminology / printouts: you'll want to save your "master extended public key" on one sheet, and your "master extended private key" on the other. Because the master extended public key can be derived from the master extended private key, you don't need to have both on the private sheet. It's up to you if you want to encrypt your master extended private key, but if you do, you should make sure it's encrypted using the BIP38 standard (simply because it's a standard likely to be supported by many wallets).

Although you shouldn't use bip32.org to create them, just for the sake of completeness: your master extended private key is next to the label "BIP32 Extended Key", and your master extended public key can be found by choosing "Info: m" next to "Derivation Path", and then looking next to "Derived Public Key"

Unfortunately, there's a lot I can't answer, e.g.:

• Easy and secure way to generate a BIP32 paper wallet (and not a brain wallet)
• BIP32 mobile app that's not in beta (there are several that are still in beta testing)
• BIP32 mobile app that supports a watching-only wallet

If you have an iPhone, you might want to look at breadwallet. I don't know anything about it, but I do see that it's apparently not in beta, and it supports BIP32. I don't know if it supports watching-only wallets.

Good luck....

As you noted it's all just obfuscation, and so I assume you know how much better encryption is at privacy protection over obfuscation.

So what is it you're really trying to accomplish? Given an answer to this, the better solution is to apply encryption to what you're trying to accomplish instead of obfuscation, isn't it?

For example, are you trying to improve privacy (to make it more difficult for malware to read pubkeys, txs, and the like)? Then (as you already noted in your follow-up post) a better solution would be to add a second password, let's call it the "watching-only" password, which encrypts the entire wallet. The "privkey" password would continue to work as-is. The watching-only password would need to remain in memory, so it wouldn't protect against malware that has acquired root, but it would help otherwise.


This I like, given that it will prevent plaintext privkeys from ever seeing a hard drive platter. Some wallets already implement this, and it'd be nice to see Bitcoin Core do so as well.

This is mysterious....

First, a little background (if you're interested, if not just skip to the questions):

Bitcoin Core makes two checks when validating your password.

A. Run the password through a key derivation function (PBKDF1-SHA512) to generate a derived_key.
B. Use the derived_key to decrypt (with AES256) the 48-byte long encrypted_mkey (from the wallet) into a decrypted_mkey.
C. Check (1): make sure the decrypted_mkey is exactly 32 bytes long plus 16 valid padding bytes at the end.
D. Use the decrypted_mkey to decrypt a single (arbitrary) encrypted_privkey (from the wallet) into a decrypted_privkey.
E. Mathematically derive from the decrypted_privkey a derived_pubkey.
F. Check (2): make sure the derived_pubkey is equal to the pubkey stored in the wallet file.

JtR doesn't bother with check (2) in the interest of speed. This should be OK, because the likelihood that check (1) passes, but check (2) fails should be extremely small (something like 1 in 2^128).

pywallet doesn't bother with check (1) (in other words, it always "accepts" the password at first), it simply truncates the decrypted_mkey to 32 bytes in length and ignores any padding (even when the padding is invalid). It only uses check(2) (running that check against every encrypted_privkey if you answer "y" to that question it asked).

If JtR thinks you have the right password, but pywallet and Bitcoin Core disagree... than I'm not sure what's going on.

So... questions...

Could you try btcrecover (another Python script)? (use "--passwordlist --wallet wallet.dat" for its options.) It should use the same single check as JtR.

Where did you get your JtR? If you compiled it from source, how recent is it (there were some recent Bitcoin-related updates to JtR)?

Do you have any wallet.dat backups (even if they're encrypted)?

The best advice I can offer regarding which wallet is the best is "don't follow anyone's advice."

The reason is simple: different wallets are geared towards different goals. One person's personal favorite might not be a good choice for you.

Instead, visit the Bitcoin.org getting started page here: https://bitcoin.org/en/getting-started

Read step 1, "Inform yourself" (don't worry, it's not long), then move on to step 2, "Choose your wallet." At the bottom of the choose-your-wallet page there's a link to "secure your wallet" which you should read before choosing a wallet. (edited; I think I misunderstood you) You've already said that "few resources" is a requirement, so don't choose a wallet that says it's a "full node."

If you have any specific questions, please ask, I'm sure someone will be along who can help.

Oh yes, and welcome!

A brain wallet, with a given password, will always be significantly less secure than a traditional wallet encrypted with that same password. Hopefully this is self-evident to everyone here.

Given this significant disadvantage, there would have to be some significant advantage a brain wallet could give you that no other wallet can before any reasonable person would prefer a brain wallet. So.... what is this advantage?

The size option is there mostly for hard drive scans. For a wallet, just choose a size that's larger than the wallet size.

You need to append a (strange) unit to the end of the size, so for example --recov_size=100Mo means 100 megaoctets.

(Be sure to take a backup of the wallet file before running pywallet on it, just in case)

Why are "more transactions with fees" desirable?

If you start with the assumption that the purpose of Bitcoin is to make money for miners, then yes "more transactions with fees" would be desirable.

But the purpose (or at least a purpose) of Bitcoin is to permit transactions and permit stored value. In other words, the decentralized transactions themselves, as well as the stored value of bitcoins, is the purpose of (capital-B) Bitcoin. Miners are just a necessary component in securing Bitcoin. Transaction spam, whether it includes fees or not, is still spam.

Technical discussions aside, OP's idea has problems for at least two other reasons.

First of all, I don't like lotteries. I like blackjack. I therefore think it would be unfair for zero-trust lotteries to be added to the blockchain unless blackjack is also added. Would anyone else like to add something? (Poker would be pretty cool I think.)

Secondly, unregulated lotteries are illegal in many (most?) jurisdictions. Although transactions can be used for either legal or illegal purposes, unregulated lotteries would always be illegal in those jurisdictions. The fact that something is illegal isn't reason enough to avoid it, for example if it were added to right some terrible evil, but I really don't see lotteries as an inalienable human right that Bitcoin should concern itself with.

This means that JtR was able to decrypt the mkey (and verify that the padding bytes were correct, which makes it extremely likely that the password was correct). JtR doesn't try to actually decrypt any private keys to check them against the stored public keys.

If the first private key, or its associated public key, is corrupted, this will happen (although that seems unlikely to me...). If this is the case, `pywallet.py --recover` can help.

CDNinATL, can you let us know how this turns out? I'm personally interested...

Also, does your password contain any non-ASCII characters (any characters not list here: https://en.wikipedia.org/wiki/ASCII#ASCII_printable_code_chart)?

True, but most printers run close-source software that do things many don't know about and may not want, even home printers. For example it's known that many (most?) printers will refuse to print counterfeit money using various technologies[1], and some printers surreptitiously include nearly-invisible identifiers to link the printed document to the individual printer which printed it[2]. If they can do this, who knows what could be next (I know this does sound a bit tin-foil-hattish...)

Printers can also be theoretically infected by malware remotely, although I don't think there are any documented cases of this outside a research setting[3] (not yet, anyways).

Some paper wallets / BIP32 backups (e.g. Armory) allow you to encrypt before printing. If you write down the encryption password on the printout, you'll have everything you need to restore the wallet in one place, and you'll remain safe from such printers.

[1] http://en.wikipedia.org/wiki/EURion_constellation
[2] https://www.eff.org/issues/printers
[3] http://www.bbc.com/news/technology-29203776

Farmer17, just who do you think you are, asking an on-topic question like this??

Seriously though, it's a good question and I'm interested to see what Fabiola! thinks.

There are a lot of if's here, but if you're sure it's your private keys that you wrote down, and if you're sure there are no typos, and if you never add any new receiving addresses to your wallet, than you should be safe.

Edited to add: and also if they're either unencrypted, or you are sure you know their password.

With blockchain.info, you need to create backups after each new receiving address you create. As long as you have a recent backup, you can reclaim your bitcoin.

There are other online services (and also desktop wallets too) where you only need to create a single backup (either printed out or written down). You may want to consider one of these...

(They include Armory, Electrum, GreenAddress, BitGo, and probably others.)

I'd take issue with that statement... look at the choose-your-wallet page on bitcoin.org here: https://bitcoin.org/en/choose-your-wallet

There are at least two or three other free online wallets that I'd rate at least as good, if not better, than blockchain.info.

I just wanted to add that if you choose a full-node client for your online wallet (e.g. Armory), and if you also choose not to keep that full-node client connected most of the time, you could run into delays.

Armory (the one you have running online) for will refuse to create a transaction until it has finished syncing.

Do you have any older backups?

Have you changed your password over time? If so, you might be able to try to import an older (automatically created by MultiBit) backup key file using an older password.

There's also a free & open source password recovery tool you could try. You will need to do a bit of reading to get it set up and running though, so if you don't have the time, a wallet recovery service is a good option.

If you'd like to try recovering it yourself, the Tutorial and the Quick Start are here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial

If you have any questions, feel free to ask (I'm the dev of that tool).

Good luck...

inf,

I think you've uncovered a bug in Armory's HMAC implementation. I very well could be (and in fact I hope I'm) wrong though....

In particular, this doesn't produce what I'd expect:


Here's the definition of HMAC256 in ArmoryUtils.py:


I believe the problem is that this HMAC function takes and uses the hash size as a parameter (256 bits for SHA256), but it should be taking and using the block size instead (512 bits for SHA256).

Could someone verify this, or hopefully correct me?

That last sentence is squarely on point.

With respect to your point #2, it's something I think we'd all like to see change. I don't know exactly how to change it, but until it's changed, we'll continue to propagate the all-boys-club image.