user1724: 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!

user153: 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


user1724: 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.

1724: <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>
 153: <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>
 1724: <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>
