Bitcoin Forum
December 05, 2016, 06:48:26 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 [8] 9 10 »  All
  Print  
Author Topic: [PULL] private key and wallet export/import  (Read 35840 times)
runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
November 13, 2011, 11:02:23 AM
 #141

I get the following error when I try to build the showwallet branch with gcc 4.6:

Code:
g++ -c -pthread -Wno-invalid-offsetof -Wformat -g -DNOPCH  -DUSE_SSL -fno-stack-protector -fstack-protector-all -Wstack-protector -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -O2 -MMD -o obj/nogui/bitcoinrpc.o bitcoinrpc.cpp
bitcoinrpc.cpp: In function 'void ThreadRPCServer2(void*)':
bitcoinrpc.cpp:2213:9: error: 'filesystem' has not been declared
bitcoinrpc.cpp:2213:26: error: expected ';' before 'certfile'
bitcoinrpc.cpp:2214:14: error: 'certfile' was not declared in this scope
bitcoinrpc.cpp:2214:49: error: 'filesystem' has not been declared
bitcoinrpc.cpp:2215:13: error: 'filesystem' has not been declared
bitcoinrpc.cpp:2215:32: error: 'certfile' was not declared in this scope
bitcoinrpc.cpp:2217:9: error: 'filesystem' has not been declared
bitcoinrpc.cpp:2217:26: error: expected ';' before 'pkfile'
bitcoinrpc.cpp:2218:14: error: 'pkfile' was not declared in this scope
bitcoinrpc.cpp:2218:45: error: 'filesystem' has not been declared
bitcoinrpc.cpp:2219:13: error: 'filesystem' has not been declared
bitcoinrpc.cpp:2219:32: error: 'pkfile' was not declared in this scope
make: *** [obj/nogui/bitcoinrpc.o] Error 1

I'm using gcc 4.6.1, libc6 2.13 and libboost 1.46 from Debian sid (the Linuxcoin distribution).
The regular bitcoin branch builds without issues.

EDIT: I just tried with gcc 4.5.2 in Ubuntu Natty as well, gives me the same error.
1480963706
Hero Member
*
Offline Offline

Posts: 1480963706

View Profile Personal Message (Offline)

Ignore
1480963706
Reply with quote  #2

1480963706
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480963706
Hero Member
*
Offline Offline

Posts: 1480963706

View Profile Personal Message (Offline)

Ignore
1480963706
Reply with quote  #2

1480963706
Report to moderator
1480963706
Hero Member
*
Offline Offline

Posts: 1480963706

View Profile Personal Message (Offline)

Ignore
1480963706
Reply with quote  #2

1480963706
Report to moderator
1480963706
Hero Member
*
Offline Offline

Posts: 1480963706

View Profile Personal Message (Offline)

Ignore
1480963706
Reply with quote  #2

1480963706
Report to moderator
runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
November 13, 2011, 02:48:40 PM
 #142

Adding the following line to bitcoinrpc.cpp

Code:
#include <boost/filesystem.hpp>

fixes the above issue for me.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
November 20, 2011, 10:26:21 PM
 #143

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 wallets instead.
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
December 18, 2011, 04:46:22 AM
 #144

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? Smiley

greetings

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 18, 2011, 07:46:57 AM
 #145

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
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
December 19, 2011, 08:05:21 PM
 #146

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
December 19, 2011, 08:09:22 PM
 #147

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? Smiley

greetings

Did you unlock your wallet? (walletpassphrase RPC command)

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
btc_artist
Full Member
***
Offline Offline

Activity: 154


Bitcoin!


View Profile WWW
December 19, 2011, 08:27:51 PM
 #148

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 Offline

Activity: 1218


Gerald Davis


View Profile
December 19, 2011, 08:36:39 PM
 #149

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 19, 2011, 09:45:40 PM
 #150

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
Full Member
***
Offline Offline

Activity: 225


View Profile
December 19, 2011, 10:20:56 PM
 #151

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!

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
December 20, 2011, 02:37:34 AM
 #152

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

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
December 20, 2011, 02:46:39 AM
 #153

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
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
December 20, 2011, 07:38:22 AM
 #154

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

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
December 20, 2011, 07:45:02 AM
 #155

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 Smiley finally a solution Tongue

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
December 20, 2011, 07:53:25 AM
 #156

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 wallets instead.
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
December 20, 2011, 08:09:37 AM
 #157

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 Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 20, 2011, 05:07:07 PM
 #158

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

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
December 20, 2011, 05:51:16 PM
 #159

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 Offline

Activity: 322


FirstBits: 168Bc


View Profile
December 20, 2011, 06:01:15 PM
 #160

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?

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
Pages: « 1 2 3 4 5 6 7 [8] 9 10 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!