[Feat Request] - Solution for Lost Wallet Passphrase

[AliceWonder]

Since I joined this forum, I've seen more than one thread where someone forgot their passphrase to their encrypted wallet and wanted help cracking it.

What if as an option, a user could enter the address of, say, a paper wallet beforehand.

Then whenever the user enters the passphrase to decrypt the wallet, a transaction is created and signed but not sent - that would send all inputs to that address. This transaction is then stored in the data directory.

In the event that the user can not recall their passphrase, that transaction could then be sent so at least the user has not lost all their coins.

Obviously it would not be able to include inputs created after the last time the user decrypted the wallet.dat but it could include all inputs that could be spent the last time wallet.dat was decrypted.

It might soften the financial blow to some people when they forget their passphrase.

Speaking as someone who sometimes has memory problems due to head injuries, I think it would be a welcome addition, and might even convince me to not keep my passphrase on a piece of paper in my desk drawer (There are days I can not even remember my own phone number).

[1714777796]

1714777796

[1714777796]

1714777796

[TierNolan]

Since I joined this forum, I've seen more than one thread where someone forgot their passphrase to their encrypted wallet and wanted help cracking it.

What if as an option, a user could enter the address of, say, a paper wallet beforehand.

This is pretty much what Armory does.  However, it doesn't need to actually generate the transaction.

You have 1 root key and all public and private keys can be generated from that.  You can then print that key to a sheet of paper and keep it somewhere safe.

If you give the software your root key, then it can scan the chain and find all coins that are yours (and send them to an address).

Then whenever the user enters the passphrase to decrypt the wallet, a transaction is created and signed but not sent - that would send all inputs to that address. This transaction is then stored in the data directory.

This would have to be one transaction per coin output.  Effectively, when a coin is received, a tx is created to send it to some other fixed address.

You still need to secure that other address though.

So, you don't get much benefit over a deterministic wallet.

[AliceWonder]

One of the problems I have with the alt clients, I don't know if Armory does this, but it seems that many of them use the same address for change every time.

That's a problem because if someone is able to identify any address with me, it then is possible for them to figure out what address was used as change when the input for that address was spent. And if the change address is the same every time, it's game over, they now can identify all kinds of addresses I sent money to and sent money from.

That's the primary reason I'm sticking with bitcoin-qt. It uses fresh change address each time change is needed.

[TierNolan]

One of the problems I have with the alt clients, I don't know if Armory does this, but it seems that many of them use the same address for change every time.

I don't know what Armory does, but I would be surprised if it re-uses addresses.  The whole point of the system is that you can easily generate new addresses.

If that is your only concern, then you should just ask in the Armory forum.

I think deterministic wallets are being considered for the main-client, but I don't know what the timeline is.

With Armory, the root key consists of 2 parts, the private key and the chaincode.

If someone obtains your chaincode, they can generate the public key (but not the private key) for all your transactions.

For full privacy, you need to protect both.

However, a merchant would have to put their chaincode on the customer facing server, or it wouldn't be able to generate new public keys.  However, the private root key should be kept on a different/more secure server.

[jl2012]

One of the problems I have with the alt clients, I don't know if Armory does this, but it seems that many of them use the same address for change every time.

That's a problem because if someone is able to identify any address with me, it then is possible for them to figure out what address was used as change when the input for that address was spent. And if the change address is the same every time, it's game over, they now can identify all kinds of addresses I sent money to and sent money from.

That's the primary reason I'm sticking with bitcoin-qt. It uses fresh change address each time change is needed.

Armory does not reuse address by default

[etotheipi]

Use Armory.  Print a paper backup.  Keep it in a safe place.

Armory never reuses addresses.  All change always goes to the next address in your infinite list of addresses backed up by your paper backup.  It's the "right way", as evidenced by the fact that BIP 32 is basically an extension of that that will eventually used in Bitcoin-Qt and other alt clients.

[gmaxwell]

Since I joined this forum, I've seen more than one thread where someone forgot their passphrase to their encrypted wallet and wanted help cracking it.
What if as an option, a user could enter the address of, say, a paper wallet beforehand.

In that case: Just write the passphrase down.  It has the same security exposure to as your paper wallet backup, but its simpler and involves less things to get wrong.

[grau]

Use Armory.  Print a paper backup.  Keep it in a safe place.

Armory never reuses addresses.  All change always goes to the next address in your infinite list of addresses backed up by your paper backup.  It's the "right way", as evidenced by the fact that BIP 32 is basically an extension of that that will eventually used in Bitcoin-Qt and other alt clients.

Are serialized BIP32 keys interoperable with Armory? If not yet, is it planned?

[etotheipi]

Use Armory.  Print a paper backup.  Keep it in a safe place.

Armory never reuses addresses.  All change always goes to the next address in your infinite list of addresses backed up by your paper backup.  It's the "right way", as evidenced by the fact that BIP 32 is basically an extension of that that will eventually used in Bitcoin-Qt and other alt clients.

Are serialized BIP32 keys interoperable with Armory? If not yet, is it planned?

I am about 70% done with the new wallet format that will accommodate all sorts of new stuff, including BIP 32.  I plan to standardize the wallet operations to BIP 32 as closely as possible, for interoperability.  But I got distracted by some the RAM issues and am working on that right now.  As soon as I'm done, I'll be upgrading the wallets.