runeks
Legendary
Offline
Activity: 980
Merit: 1008
|
|
November 13, 2011, 02:48:40 PM |
|
Adding the following line to bitcoinrpc.cpp #include <boost/filesystem.hpp> fixes the above issue for me.
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
November 20, 2011, 10:26:21 PM |
|
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.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
December 18, 2011, 04:46:22 AM |
|
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
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
Red Emerald
|
|
December 18, 2011, 07:46:57 AM |
|
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 (OP)
|
|
December 19, 2011, 08:05:21 PM |
|
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.
|
I do Bitcoin stuff.
|
|
|
Pieter Wuille (OP)
|
|
December 19, 2011, 08:09:22 PM |
|
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)
|
I do Bitcoin stuff.
|
|
|
btc_artist
Full Member
Offline
Activity: 154
Merit: 102
Bitcoin!
|
|
December 19, 2011, 08:27:51 PM |
|
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)?
|
BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
December 19, 2011, 08:36:39 PM |
|
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
|
|
December 19, 2011, 09:45:40 PM |
|
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
|
|
December 19, 2011, 10:20:56 PM |
|
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
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
December 20, 2011, 02:37:34 AM |
|
i hope it will work with encrypted wallets too, pywallet cant do this atm so this would be the only alternative.
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
December 20, 2011, 02:46:39 AM |
|
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 (OP)
|
|
December 20, 2011, 07:38:22 AM |
|
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().
|
I do Bitcoin stuff.
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
December 20, 2011, 07:45:02 AM |
|
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
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
December 20, 2011, 07:53:25 AM |
|
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)
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1036
|
|
December 20, 2011, 08:09:37 AM Last edit: December 20, 2011, 08:24:26 AM by 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
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
December 20, 2011, 05:07:07 PM |
|
How is it that there is no index already? I'd like to see an index for native client firstbits support.
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
December 20, 2011, 05:51:16 PM |
|
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
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
December 20, 2011, 06:01:15 PM |
|
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
|
|
December 20, 2011, 06:35:56 PM |
|
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.
|
|
|
|
|