<p>My experiences messing around with all this tells me that the fault <em>probably</em> falls with my particular version of pywallet.  Specifically, it is simply reporting the private keys inappropriately.  The primary reason I think this is that the addresses in the pywallet dump corresponding to addresses that can both send <em>and</em> receive coins using the Bitcoin-qt client.  Additionally, the pywallet utility can <em>add</em> its legitimate private keys to the wallet, and there's no problems -- the address and associated private key in the 'keys' entry match up.  Hence, it's just a problem of <em>reporting</em> the correct results.</p>

<p>What I still don't get is why how the keys pywallet spits out are still legitimate.  It's almost as if instead of using the private keys actually associated with each address through the client, it's generating its own.  But I'm not terribly well versed in cryptography yet, and that's just the thoughts of a mind desperate for an explanation!</p>

<p>I'm still unsure of how to fully resolve this matter.  I'd hate to ``downgrade'' my version of pywallet, so to speak, but it may be worthwhile to see if an older version behaves as expected.</p>

CC BY-SA 3.0
2012-08-25T02:27:53.743Z
2012-08-25T02:27:53.743Z
AFineTransform
<p>Perhaps pywallet is misreporting the bitcoin address?</p>

<p>Does your wallet actually show a 1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT bitcoin address?</p>

<p>Here's a method to manually determine the public address for the private key.</p>

<ul>
<li><a href="http://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses" rel="nofollow">http://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses</a></li>
</ul>

CC BY-SA 3.0
2012-08-15T02:54:15.990Z
Thanks for the response.  The default address the wallet displays is 19x2Ma982vmtk5uJX7cb2WkEMcvYgCEAmz.  Excluding this, the first address in the key pool according the pywallet data dump ("n": 2) is 1Hc7xyoBUBpvjtcr6LTmpQSssvPWGbtt8u; after firing up the Bitcoin-qt client and "making" a new address, these are indeed the addresses it displays.  I'm inclined to say that the addresses in the key pool are the real deal, but it's still strange how the private keys listed in the dump don't match them.
AFineTransform
CC BY-SA 3.0
2012-08-15T02:56:53.023Z
And for the record, when I get time tomorrow, I may swallow my pride and get a pittance of BTC tomorrow from those advertising sites, as per Daniel's recommendation.  Then I can try sending them to the various addresses and see if I can recover them in any way.
AFineTransform
CC BY-SA 3.0
2012-08-16T01:54:15.337Z
This escaped my notice initially, but my the 1NpYUP... address does actually appear in the key pool, at n=5!  Indeed, some coins I sent there were received successfully and shortly thereafter began acquiring confirmations, as is typical!  I've since realized that all of the addresses listed under the 'key' category also appear in the key pool, but with an order that seems random.  **BUT**, this still doesn't explain why the pool addresses the private key associates with under 'addr' don't match up with the addresses generated by the private keys!
AFineTransform
CC BY-SA 3.0
2012-08-16T01:57:54.550Z
I should also add that BTC sent to 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 never were received, despite that the private key from which it originated is in the wallet, according to the dump.  I don't know what exactly this incriminates.  Also, apologies for the quadruple comment!
AFineTransform
CC BY-SA 3.0
2012-08-17T16:04:39.493Z
Well, somebody received those coins and spent them, probably because you posted the private key here. If you decide to use bitcoin for values of more than a few mBTC, you should probably generate an entirely new wallet separate from those here, or at least ensure you NEVER use these addresses again.

http://blockchain.info/address/1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8
Daniel H
CC BY-SA 3.0
2012-08-14T22:04:20.200Z
2012-08-14T22:04:20.200Z
Stephen Gornick
<p>I've been messing around with an empty wallet file using the 'pywallet' utility, and have come across something I can't understand.</p>

<p>A dump of the unencrypted wallet readily reveals a list containing entries such as:</p>

<pre><code>        "addr": "1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT", 
        "hexsec": "d38c1f602bc0bc90a54c5d743b3b75460c4aeeb1dc6ad62d3c6758c3714998a0", 
        "reserve": 1, 
        "sec": "5KRTGtTczAwef7vdDfm9knDyKMoaa8XHJURnMZnQFd5qkWVJtsB"
</code></pre>

<p>The second/fourth entries are obviously the private key.  However, if I input this key at (for instance) bitaddress.org, it generates</p>

<pre><code>        1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 (address)
        1HoVqjG35pW3AQ7wtYtA72tSpyLyP4vDLp (compressed address)
</code></pre>

<p>neither of which match ANY of the other addresses listed in the dump.  I can't find an explanation for this anywhere, and I'm wondering what the ramifications of losing, say, the first address in the key entry ('1NpYUP...')  or the addresses in the pool are if they don't actually correspond to the private keys in the file.</p>

<p><em><strong>Just a heads up - do not post your private key in public unless you'll no longer be using that Bitcoin address</em></strong></p>

<p>Thanks in advance!</p>

CC BY-SA 3.0
2012-12-27T23:44:32.903Z
What private key does the dumpprivkey command report (RPC call or console in Bitcoin-Qt)? Does it correspond to what pywallet is saying?
Pieter Wuille
CC BY-SA 3.0
2012-08-14T09:33:04.517Z
Have you tried sending 0.01 BTC to 1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT and to 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8?
Samuel Tardieu
CC BY-SA 3.0
2012-08-14T13:03:22.633Z
I have not, simply because I won't feel comfortable using Bitcoin until I get a really good grasp of how everything -- especially the client, which I would use most frequently -- works.  Because of this, I have only the 5 mBTC I got from the Bitcoin Faucet; not enough to avoid incurring a fee I can't yet afford!
AFineTransform
CC BY-SA 3.0
2012-08-14T16:40:09.187Z
You can get a tiny amount of daily free bitcoins if you can put up with ads. I don't do this much, but it's perfect for seeding addresses. DailyBitcoin and CoinAd are two places that do this.

Note: I have absolutely no interest in these site's success except for the few times I use them.
Daniel H
CC BY-SA 3.0
2012-08-14T21:56:11.660Z
Importing the private key (d38c1f602bc0bc90a54c5d743b3b75460c4aeeb1dc6ad62d3c6758c3714998a0) into Blockchain.info/wallet also yields 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8.
Stephen Gornick
CC BY-SA 3.0
2012-08-15T12:04:18.867Z
I used my GoBit testing suite and it also yields 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 http://gobittest.appspot.com/Address
ThePiachu
CC BY-SA 3.0
2012-08-17T17:02:24.783Z
Doing my own testing with pywallet, I find that 1. the output format is slightly different (no hexsec) and 2. I don't have this problem on a newly-generated wallet.

This makes me think you have a bad pywallet version, or a bad wallet file. Could you please post the pywallet version you're using? Also, could you try sending some of the bitcoins you got at this address to see if you really do have the right private key in the wallet?
Daniel H
CC BY-SA 3.0
2012-08-21T00:07:24.027Z
I believe I'm using the latest version, pywallet.py 1.1.  I've continued to experiment with this, most recently using the utility to add that same private key and the associated address (1EEYqe...) to the key pool.  This did not overwrite the entry containing the same private key but erroneous address (1NpYUP...).  Adding the private key manually a second time does result in an overwrite of the 1EEYqe... entry, but again, the original is untouched.  Very interesting!
AFineTransform
CC BY-SA 3.0
2012-08-22T00:12:29.933Z
Have you had any luck sending bitcoins from your 1NpYUPp... address?
Daniel H
CC BY-SA 3.0
2012-08-22T15:48:40.837Z
Yes, I was able to send some from the 1NpYUPp... address to the default wallet address without problem.  So the correct private key has to be in the wallet _somewhere_, right?
AFineTransform
CC BY-SA 3.0
2012-08-22T19:01:13.383Z
I'd assume so. I'd try importing the wallet into another service and see what happens. Blockchain.info has at least two different ways you can import it, probably more; I'd check what those do.
Daniel H
CC BY-SA 3.0
2012-08-23T15:32:47.560Z
Importing the pywallet dump into MyWallet doesn't seem to do anything.  There will even be 'verified' and 'successful server sync' type notifications, but the BTC balance and transactions will not appear unless I import each private key individually.  Oh, and I haven't mentioned this yet because yet as it seems irrelevant, but I do not have a working 'ecdsa' package installed.  Could it also have a subtle influence on the mismatched key issue I'm experiencing?
AFineTransform
CC BY-SA 3.0
2012-08-25T02:23:35.887Z
Just following up, I did get the 'ecdsa' package installed for Python 2.7.  As expected, it had no impact of any relevance.
AFineTransform
<wallet><address><private-key>
Why don't addresses in an (unencrypted) wallet.dat file seem to match addresses that would be generated by the private keys in the wallet?
AFineTransform
# Why don't addresses in an (unencrypted) wallet.dat file seem to match addresses that would be generated by the private keys in the wallet?

(Asked by: username_0 on 2012-08-14)

I've been messing around with an empty wallet file using the 'pywallet' utility, and have come across something I can't understand.

A dump of the unencrypted wallet readily reveals a list containing entries such as:

```
        "addr": "1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT", 
        "hexsec": "d38c1f602bc0bc90a54c5d743b3b75460c4aeeb1dc6ad62d3c6758c3714998a0", 
        "reserve": 1, 
        "sec": "5KRTGtTczAwef7vdDfm9knDyKMoaa8XHJURnMZnQFd5qkWVJtsB"

```

The second/fourth entries are obviously the private key. However, if I input this key at (for instance) bitaddress.org, it generates

```
        1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 (address)
        1HoVqjG35pW3AQ7wtYtA72tSpyLyP4vDLp (compressed address)

```

neither of which match ANY of the other addresses listed in the dump. I can't find an explanation for this anywhere, and I'm wondering what the ramifications of losing, say, the first address in the key entry ('1NpYUP...') or the addresses in the pool are if they don't actually correspond to the private keys in the file.

***Just a heads up - do not post your private key in public unless you'll no longer be using that Bitcoin address***

Thanks in advance!

**Tags:** wallet, address, private-key

> **Comments:**
> **username_2**: Have you tried sending 0.01 BTC to 1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT and to 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8?  
> **username_0**: I have not, simply because I won't feel comfortable using Bitcoin until I get a really good grasp of how everything -- especially the client, which I would use most frequently -- works.  Because of this, I have only the 5 mBTC I got from the Bitcoin Faucet; not enough to avoid incurring a fee I can't yet afford!  
> **username_3**: You can get a tiny amount of daily free bitcoins if you can put up with ads. I don't do this much, but it's perfect for seeding addresses. DailyBitcoin and CoinAd are two places that do this.  Note: I have absolutely no interest in these site's success except for the few times I use them.  
> **username_4**: Importing the private key (d38c1f602bc0bc90a54c5d743b3b75460c4aeeb1dc6ad62d3c6758c3714998a0) into Blockchain.info/wallet also yields 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8.  
> **username_5**: I used my GoBit testing suite and it also yields 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 http://gobittest.appspot.com/Address  
> **username_3**: Doing my own testing with pywallet, I find that 1. the output format is slightly different (no hexsec) and 2. I don't have this problem on a newly-generated wallet.  This makes me think you have a bad pywallet version, or a bad wallet file. Could you please post the pywallet version you're using? Also, could you try sending some of the bitcoins you got at this address to see if you really do have the right private key in the wallet?  
> **username_0**: I believe I'm using the latest version, pywallet.py 1.1.  I've continued to experiment with this, most recently using the utility to add that same private key and the associated address (1EEYqe...) to the key pool.  This did not overwrite the entry containing the same private key but erroneous address (1NpYUP...).  Adding the private key manually a second time does result in an overwrite of the 1EEYqe... entry, but again, the original is untouched.  Very interesting!  
> **username_3**: Have you had any luck sending bitcoins from your 1NpYUPp... address?  
> **username_0**: Yes, I was able to send some from the 1NpYUPp... address to the default wallet address without problem.  So the correct private key has to be in the wallet _somewhere_, right?  
> **username_3**: I'd assume so. I'd try importing the wallet into another service and see what happens. Blockchain.info has at least two different ways you can import it, probably more; I'd check what those do.  
> **username_0**: Importing the pywallet dump into MyWallet doesn't seem to do anything.  There will even be 'verified' and 'successful server sync' type notifications, but the BTC balance and transactions will not appear unless I import each private key individually.  Oh, and I haven't mentioned this yet because yet as it seems irrelevant, but I do not have a working 'ecdsa' package installed.  Could it also have a subtle influence on the mismatched key issue I'm experiencing?  
> **username_0**: Just following up, I did get the 'ecdsa' package installed for Python 2.7.  As expected, it had no impact of any relevance.  
> **username_1**: What private key does the dumpprivkey command report (RPC call or console in Bitcoin-Qt)? Does it correspond to what pywallet is saying?  

---

## 2 answers

### Answer by username_0 on 2012-08-25. Score: 1

My experiences messing around with all this tells me that the fault *probably* falls with my particular version of pywallet. Specifically, it is simply reporting the private keys inappropriately. The primary reason I think this is that the addresses in the pywallet dump corresponding to addresses that can both send *and* receive coins using the Bitcoin-qt client. Additionally, the pywallet utility can *add* its legitimate private keys to the wallet, and there's no problems -- the address and associated private key in the 'keys' entry match up. Hence, it's just a problem of *reporting* the correct results.

What I still don't get is why how the keys pywallet spits out are still legitimate. It's almost as if instead of using the private keys actually associated with each address through the client, it's generating its own. But I'm not terribly well versed in cryptography yet, and that's just the thoughts of a mind desperate for an explanation!

I'm still unsure of how to fully resolve this matter. I'd hate to ``downgrade'' my version of pywallet, so to speak, but it may be worthwhile to see if an older version behaves as expected.


---

### Answer by username_4 on 2012-08-14. Score: 1

Perhaps pywallet is misreporting the bitcoin address?

Does your wallet actually show a 1NpYUPpz2E4fhYfoJRfUApa5hSPcrpCGaT bitcoin address?

Here's a method to manually determine the public address for the private key.

* <http://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses>

> **Comments:**
> **username_0**: Thanks for the response.  The default address the wallet displays is 19x2Ma982vmtk5uJX7cb2WkEMcvYgCEAmz.  Excluding this, the first address in the key pool according the pywallet data dump ("n": 2) is 1Hc7xyoBUBpvjtcr6LTmpQSssvPWGbtt8u; after firing up the Bitcoin-qt client and "making" a new address, these are indeed the addresses it displays.  I'm inclined to say that the addresses in the key pool are the real deal, but it's still strange how the private keys listed in the dump don't match them.  
> **username_0**: And for the record, when I get time tomorrow, I may swallow my pride and get a pittance of BTC tomorrow from those advertising sites, as per username_3's recommendation.  Then I can try sending them to the various addresses and see if I can recover them in any way.  
> **username_0**: This escaped my notice initially, but my the 1NpYUP... address does actually appear in the key pool, at n=5!  Indeed, some coins I sent there were received successfully and shortly thereafter began acquiring confirmations, as is typical!  I've since realized that all of the addresses listed under the 'key' category also appear in the key pool, but with an order that seems random.  **BUT**, this still doesn't explain why the pool addresses the private key associates with under 'addr' don't match up with the addresses generated by the private keys!  
> **username_0**: I should also add that BTC sent to 1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8 never were received, despite that the private key from which it originated is in the wallet, according to the dump.  I don't know what exactly this incriminates.  Also, apologies for the quadruple comment!  
> **username_3**: Well, somebody received those coins and spent them, probably because you posted the private key here. If you decide to use bitcoin for values of more than a few mBTC, you should probably generate an entirely new wallet separate from those here, or at least ensure you NEVER use these addresses again.  http://blockchain.info/address/1EEYqeJHkubdhcrHvH7ajpSBEALXMygoD8  

---

