[PULL] private key and wallet export/import

[runeks]

Adding the following line to bitcoinrpc.cpp

Code:

#include <boost/filesystem.hpp>

fixes the above issue for me.

[1714177133]

1714177133

[1714177133]

1714177133

[1714177133]

1714177133

[casascius]

It would be fine if this index were built on the beginning of the address (e.g. the first 32 bits) rather than the entire thing, in order to save on space, at the minor expense that a few blocks might occasionally be consulted that don't actually contain transactions for the bitcoin address being searched

If key import is the use case, you could also make the index smaller by pointing at only the first block that mentions an address.  If I send coins today, such an index would immediately eliminate 152,000 blocks from the search.  I'd guess that imported keys typically have a short time between initial funding and sweeping to a semi-permanent address.

I would recommend the index point to all of the blocks that mention an address, otherwise I could DoS websites offering private key import simply by repeatedly trying to deposit private keys from transactions done a long time ago, even if those keys had no funds.

But there is one place I would put a derivative of the idea you just mentioned: in the -rescan command.  I frequently need to import large numbers of private keys.  I have patched my own bitcoind so that importprivkey doesn't rescan the wallet immediately, so it returns instantly.  After importing keys, I shutdown and do a rescan.  I have it so that I can do bitcoind -rescan=150000, that it will only rescan from block 150000 if I know I'm only importing recent keys... saves me tons of time importing private keys in the absence of that index.  (in a nutshell, I added an optional "nSkip" parameter to ScanForWalletTransactions()).  Of course, having the index would be much sweeter.

[K1773R]

just try'd to import/merge a encrypted wallet, i cant neither import a privkey to a encrypted wallet, nor can i merge a unencrypted wallet into a encrypted one.
any plans on implementing this? is there a way (i google'd, couldnt find anything) to decrypt my wallet.dat so i got a unecrypted one where i can add privkeys and later reecrypt it?

greetings

[Red Emerald]

It would be fine if this index were built on the beginning of the address (e.g. the first 32 bits) rather than the entire thing, in order to save on space, at the minor expense that a few blocks might occasionally be consulted that don't actually contain transactions for the bitcoin address being searched

If key import is the use case, you could also make the index smaller by pointing at only the first block that mentions an address.  If I send coins today, such an index would immediately eliminate 152,000 blocks from the search.  I'd guess that imported keys typically have a short time between initial funding and sweeping to a semi-permanent address.

I would recommend the index point to all of the blocks that mention an address, otherwise I could DoS websites offering private key import simply by repeatedly trying to deposit private keys from transactions done a long time ago, even if those keys had no funds.

But there is one place I would put a derivative of the idea you just mentioned: in the -rescan command.  I frequently need to import large numbers of private keys.  I have patched my own bitcoind so that importprivkey doesn't rescan the wallet immediately, so it returns instantly.  After importing keys, I shutdown and do a rescan.  I have it so that I can do bitcoind -rescan=150000, that it will only rescan from block 150000 if I know I'm only importing recent keys... saves me tons of time importing private keys in the absence of that index.  (in a nutshell, I added an optional "nSkip" parameter to ScanForWalletTransactions()).  Of course, having the index would be much sweeter.

Do you have these rescan changes as another pull request?

I'm also looking forward to this pull request. I want to merge some wallets and would like to use official code.

[Pieter Wuille]

Key import/export has just been merged for 0.6.

Wallet import/export needs a bit of work still, so is delayed.

Key removal support has been dropped, because of too many dangerous side-effects on wallets (in particular in combination with accounts). I'm willing to maintain this as a separate branch, though.

[Pieter Wuille]

just try'd to import/merge a encrypted wallet, i cant neither import a privkey to a encrypted wallet, nor can i merge a unencrypted wallet into a encrypted one.
any plans on implementing this? is there a way (i google'd, couldnt find anything) to decrypt my wallet.dat so i got a unecrypted one where i can add privkeys and later reecrypt it?

greetings

Did you unlock your wallet? (walletpassphrase RPC command)

[btc_artist]

Key import/export has just been merged for 0.6.

Wallet import/export needs a bit of work still, so is delayed.

Key removal support has been dropped, because of too many dangerous side-effects on wallets (in particular in combination with accounts). I'm willing to maintain this as a separate branch, though.

This is great news!  This is only import/export of keys, right (not sweeping and sending funds to a new key)?

[DeathAndTaxes]

Thoughts?

That'd be exactly when the power goes out.

Ok have wallet generate address, export it it, advise user to print a copy before hitting NEXT.  When user hits next it creates the transaction.

[Red Emerald]

Key import/export has just been merged for 0.6.

Wallet import/export needs a bit of work still, so is delayed.

Key removal support has been dropped, because of too many dangerous side-effects on wallets (in particular in combination with accounts). I'm willing to maintain this as a separate branch, though.

<3

[blueadept]

Key import/export has just been merged for 0.6.

Wallet import/export needs a bit of work still, so is delayed.

Key removal support has been dropped, because of too many dangerous side-effects on wallets (in particular in combination with accounts). I'm willing to maintain this as a separate branch, though.

This seems to work great for me on an unencrypted wallet with vanity-gen generated keys. Thanks!

[K1773R]

i hope it will work with encrypted wallets too, pywallet cant do this atm so this would be the only alternative.

[SgtSpike]

Key import/export has just been merged for 0.6.

Wallet import/export needs a bit of work still, so is delayed.

Key removal support has been dropped, because of too many dangerous side-effects on wallets (in particular in combination with accounts). I'm willing to maintain this as a separate branch, though.

Wheeee!

This, combined with the offline transaction creation, should finally make one of my projects viable!

[Pieter Wuille]

i hope it will work with encrypted wallets too, pywallet cant do this atm so this would be the only alternative.

It does. You do need to unlock the wallet via RPC first though, via walletpassphrase().

[K1773R]

i hope it will work with encrypted wallets too, pywallet cant do this atm so this would be the only alternative.

It does. You do need to unlock the wallet via RPC first though, via walletpassphrase().

great finally a solution

[casascius]

Now all we need is a way to get rid of the block chain scan...

either an index built on first use, or perhaps an abbreviated one maintained in memory so it is only built once per invocation of bitcoind (e.g. a tree/hashtable that maps the first 32bits of hash160 to a list of pointers to block indexes, so memory usage isn't ridiculous)

[deepceleron]

Now all we need is a way to get rid of the block chain scan...

either an index built on first use, or perhaps an abbreviated one maintained in memory so it is only built once per invocation of bitcoind (e.g. a tree/hashtable that maps the first 32bits of hash160 to a list of pointers to block indexes, so memory usage isn't ridiculous)

Maybe Bitcoin shouldn't automatically rescan after a key import, but the new "rescan" button starts blinking to insist you should do it, and a per-address flag is set in the wallet to indicate the block chain hasn't been analyzed yet for that address's true balance. Progress bar during online rescan, etc. I suppose a method for RPC also needs to be implemented, or maybe auto-rescan is limited to once every 15 minutes or such.

A full index could be significant in size. When it gets messed up do we then get to do a -reindex? How about when it is corrupted and points to nonexistent blocks and crashes bitcoin, etc.

[netrin]

How is it that there is no index already? I'd like to see an index for native client firstbits support.

[SgtSpike]

How is it that there is no index already? I'd like to see an index for native client firstbits support.

Maybe it could be implemented into the Electrum client.  I know he was planning to implement firstbits lookups in the GUI, so maintaining an index shouldn't be too far from it.
https://bitcointalk.org/index.php?topic=50936

[netrin]

But how does the local blockchain work if the addresses are not already indexed? I understand the client/wallet only keeps record of its own addresses and linked transactions, but... really? I should think that firstbits (or first ~48 bits) would make an excellent Primary key (with a highly unlikely collision list). How much extra data would such an address index require? Wouldn't that greatly simplifying and modularize the design?

[blueadept]

But how does the local blockchain work if the addresses are not already indexed? I understand the client/wallet only keeps record of its own addresses and linked transactions, but... really? I should think that firstbits (or first ~48 bits) would make an excellent Primary key (with a highly unlikely collision list). How much extra data would such an address index require? Wouldn't that greatly simplifying and modularize the design?

The local blockchain indexes transaction hashes.  Transaction inputs reference those transaction hashes and then the matching outputs are checked.

Eventually, if the idea of splitting the wallet part from the peer-to-peer portion that communicates with other nodes and keeps track of the blockchain becomes reality, addresses will need to be indexed for fast searching anyway.  Implementing that now would speed up key import, though.