Quote from: Borisz on January 07, 2017, 12:30:19 PM

More of a question here for learning purposes

Quote from: shorena

True, this is what a send to two addresses unknown to the wallet (no private key) would look like. Considering the time the transaction took place its likely that the change key was one 100+ ofter the january backup.

I am not getting how the return could go to an address about which your wallet does not know. I only see 2 options:

A: If the client knows that all keys in the old keypool have been used up (sync is recent enough), it will simply re-generate new private-public keys. This happens if you unlock the wallet to make a transaction. Hence return should go to a newly (at the time of transaction) generated address.

The client keeps track of the number of unused keys in the keypool, yes. This has little to do with syncing the blockchain, its entirely local. It requirest blockchain data to determine "used" though.

Quote from: Borisz on January 07, 2017, 12:30:19 PM

B: If the client does not know that all keys have been used up (sync not completed up to the point where the last address has been used), then it will send the return coins to an old address in the old keypool (say 99/100), which has already been used before (!), but for which you also ought to have the private key in the old wallet.dat. In this case the return address would have 2 transactions in it.

We are talking about a restoration from a backup. More below.

Quote from: Borisz on January 07, 2017, 12:30:19 PM

Please correct me if this is wrong, after all, I am here to learn.

Based on this and the transaction ID, the 13 BTC change was the only input to the return address, so I would say it is a new address generated when you sent the transaction. (Had 13 BTC been sent to a return address that was used sometime after your January backup (I do not see how that would be possible), that address would likely have another transaction in it as well. Being also old, it is quite probably that it was already used.)

BitcoinNewsBR
1. The transaction in the UI does look like if it was sent to an unknown address(mentioned by shorena), as generally return addresses are not shown in the UI. Are you perhaps using an extension/script to show these as well?
2. I think a "Private key for address X is unknown" also appears when you try to dumpprivkey with the wallet locked. I assume this is not the case.

No

Code:

dumpprivkey 1HxeCXGT11wVwy78gsVrzFfkfdijQE9rct
Error: Please enter the wallet passphrase with walletpassphrase first. (code -13)

Quote from: Borisz on January 07, 2017, 12:30:19 PM

3. Have you tried to sign a message with the return address? I saw this recommended somewhere as to double-check if you don't have the private key for an address.

It should not make a difference.

Quote from: Borisz on January 07, 2017, 12:30:19 PM

4. If you haven't already, you could look at the commands listaddressgroupings and listreceivedbyaddress, they might tell you some additional info.

-

What I think happend is the following.

OP created a backup in January and kept using the wallet. The wallet kept refilling the keypool whenever needed, but these are not part of the January backup. Sometime in September the 101th key since the backup in Jan was used as a change address. When the wallet was restored from backup. It recognized the transaction because it had one of the keys that controlled the input that was used. Since it did not recognize any of the output addresses it marked them as external and thus is showing them in the overview, whereas it would not show a change output.