Problem recovering transaction from 2009 wallet

[apogio]

Is your node fully synced?

What version of bitcoin core are you running?

Can you try with the version 0.1.0 which can be found here: https://satoshi.nakamotoinstitute.org/code/ ?

[gigi0ne]

i have try 9.0 9.5 11 12 21 27 etc...

i have try the 1.3, But it won't connect to the network

now try the 1.0

[apogio]

I don't think you will manage to connect to the network.

Give me some time to think, because obviously your situation is strange.

Perhaps someone else may join and help meanwhile.

[gigi0ne]

exception: nst8ios_base7failureE
CDataStream::Read() : end of data

but i use the Wine under linux.. now try one windows machine

[gigi0ne]

same error also under windows,
I would like to try 0.1.5 but I can't find it anywhere

Does anyone know where to find it?

if someone helps me solve the problem I'll give him 10 bitcoins

[gigi0ne]

unfortunately I have to wait until tomorrow to send you another private message--I only have 2 a day

it would be better to switch to whatsapp or messenger.
otherwise we take months.

[apogio]

Sorry for that, but I don’t want to communicate with anyone out of the forum!

Feel free to post anything you want here as well!

There are definitely people more capable than me!

[gigi0ne]

this is what they sent me

.To lock a transaction with this Script, do the following:

    Serialize OP_ADD 99 OP_EQUAL:

    * OP_ADD = 0x93 — a simple opcode translation
    * 99 = 0x01, 0x63 — this opcode pushes one byte onto the stack, 99 (hex: 0x63)
        * No worries about endian conversion because it's only one byte
    * OP_EQUAL = 0x87 — a simple opcode translation
    * <serialized99Equal> = "93016387"
$ btcc OP_ADD 99 OP_EQUAL
93016387

    Save <serialized99Equal> for future reference as the redeemScript.

    * <redeemScript> = "93016387"

    SHA-256 and RIPEMD-160 hash the serialized script.

    * <hashed99Equal> = "3f58b4f7b14847a9083694b9b3b52a4cea2569ed"

    Produce a P2SH locking script that includes the <hashed99Equal>.

    * scriptPubKey = "a9143f58b4f7b14847a9083694b9b3b52a4cea2569ed87"
You can then create a transaction using this scriptPubKey, probably via an API.

To unlock this transaction requires that the recipient produce a scriptSig that prepends two constants totalling ninety-nine to the serialized script: 1 98 <serialized99Equal>.

The process of unlocking the P2SH transaction then begins with a first round of validation, which checks that the redeem script matches the hashed value in the locking script.
Concatenate scriptSig and scriptPubKey and execute them, as normal:
Script: 1 98 <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
Stack: []

Script: 98 <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
Stack: [ 1 ]

Script: <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
Stack: [ 1 98 ]

Script: OP_HASH160 <hashed99Equal> OP_EQUAL
Stack: [ 1 98 <serialized99Equal> ]

Script: <hashed99Equal> OP_EQUAL
Running: <serialized99Equal> OP_HASH160
Stack: [ 1 98 <hashed99Equal> ]

Script: OP_EQUAL
Stack: [ 1 98 <hashed99Equal> <hashed99Equal> ]

Script:
Running: <hashed99Equal> <hashed99Equal> OP_EQUAL
Stack: [ 1 98 True ]
The Script ends with a True on top of the stack, and so it succeeds ... even though there's other cruft below it.
However, because this was a P2SH script, the execution isn't done.

For the second round of validation, verify that the values in the unlocking script satisfy the redeemScript: deserialize the redeemScript ("93016387" = "OP_ADD 99 OP_EQUAL"), then execute it using the items in the scriptSig prior to the serialized script:
Script: 1 98 OP_ADD 99 OP_EQUAL
Stack: [ ]

Script: 98 OP_ADD 99 OP_EQUAL
Stack: [ 1 ]

Script: OP_ADD 99 OP_EQUAL
Stack: [ 1 98 ]

Script: 99 OP_EQUAL
Running: 1 98 OP_ADD
Stack: [ 99 ]

Script: OP_EQUAL
Stack: [ 99 99 ]

Script:
Running: 99 99 OP_EQUAL
Stack: [ True ]
With that second validation also true, the UTXO can now be spent

[mcdouglasx]

this is what they sent me

.To lock a transaction with this Script, do the following:

    Serialize OP_ADD 99 OP_EQUAL:

    * OP_ADD = 0x93 — a simple opcode translation
    * 99 = 0x01, 0x63 — this opcode pushes one byte onto the stack, 99 (hex: 0x63)
        * No worries about endian conversion because it's only one byte
    * OP_EQUAL = 0x87 — a simple opcode translation
    * <serialized99Equal> = "93016387"
$ btcc OP_ADD 99 OP_EQUAL
93016387

    Save <serialized99Equal> for future reference as the redeemScript.

    * <redeemScript> = "93016387"

    SHA-256 and RIPEMD-160 hash the serialized script.

    * <hashed99Equal> = "3f58b4f7b14847a9083694b9b3b52a4cea2569ed"

    Produce a P2SH locking script that includes the <hashed99Equal>.

    * scriptPubKey = "a9143f58b4f7b14847a9083694b9b3b52a4cea2569ed87"
You can then create a transaction using this scriptPubKey, probably via an API.

To unlock this transaction requires that the recipient produce a scriptSig that prepends two constants totalling ninety-nine to the serialized script: 1 98 <serialized99Equal>.

The process of unlocking the P2SH transaction then begins with a first round of validation, which checks that the redeem script matches the hashed value in the locking script.
Concatenate scriptSig and scriptPubKey and execute them, as normal:
Script: 1 98 <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
Stack: []

Script: 98 <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
Stack: [ 1 ]

Script: <serialized99Equal> OP_HASH160 <hashed99Equal> OP_EQUAL
Stack: [ 1 98 ]

Script: OP_HASH160 <hashed99Equal> OP_EQUAL
Stack: [ 1 98 <serialized99Equal> ]

Script: <hashed99Equal> OP_EQUAL
Running: <serialized99Equal> OP_HASH160
Stack: [ 1 98 <hashed99Equal> ]

Script: OP_EQUAL
Stack: [ 1 98 <hashed99Equal> <hashed99Equal> ]

Script:
Running: <hashed99Equal> <hashed99Equal> OP_EQUAL
Stack: [ 1 98 True ]
The Script ends with a True on top of the stack, and so it succeeds ... even though there's other cruft below it.
However, because this was a P2SH script, the execution isn't done.

For the second round of validation, verify that the values in the unlocking script satisfy the redeemScript: deserialize the redeemScript ("93016387" = "OP_ADD 99 OP_EQUAL"), then execute it using the items in the scriptSig prior to the serialized script:
Script: 1 98 OP_ADD 99 OP_EQUAL
Stack: [ ]

Script: 98 OP_ADD 99 OP_EQUAL
Stack: [ 1 ]

Script: OP_ADD 99 OP_EQUAL
Stack: [ 1 98 ]

Script: 99 OP_EQUAL
Running: 1 98 OP_ADD
Stack: [ 99 ]

Script: OP_EQUAL
Stack: [ 99 99 ]

Script:
Running: 99 99 OP_EQUAL
Stack: [ True ]
With that second validation also true, the UTXO can now be spent

The concept of Pay-to-Script-Hash (P2SH) did not exist in 2009. It was introduced to Bitcoin in 2012 as part of Bitcoin Improvement Proposal 16 (BIP16).

same error also under windows,
I would like to try 0.1.5 but I can't find it anywhere

Does anyone know where to find it?

if someone helps me solve the problem I'll give him 10 bitcoins

Previously, older versions were downloaded via Wayback Machine, but the site was hacked.

[Cricktor]

I've a few thoughts on this, but I'm a bit bad at Bitcoin history and when what was introduced.

Very early coinbase transactions were quite often P2PK type, so paid to public key, not to what we call legacy addresses which are P2PKH (pay to public key hash, encoded with checksum and in base58 form).

Why do I mention this? Well, most Electrum servers won't return a transaction history for a P2PK transaction even when you have imported a private key (you can't import P2PK address type in Electrum for obvious reasons). An imported private key in Electrum would still have zero balance with P2PKH address type when coins are locked in a P2PK transaction (like very early miner's coinbase tx).

You can import combo(...) descriptors in modern Bitcoin Core versions which would show almost any address type coins if there are any.


If OP needs access to older Bitcoin Core version, I'd suggest to have a look at mocacinno's docker images of historical versions of the Bitcoin client software: docker images of most (historical) bitcoin core versions back to v0.2.1 in 2009

If you have a proper wallet.dat and also access to its encryption password/passphrase, then you could gradually update a copy of your wallet.dat file with newer versions of Bitcoin Core. I'm not sure if you can actually feed a wallet.dat from 2009 directly to e.g. Bitcoin Core 28.0.0 (last most recent version). You might need some intermediate Core versions when there were major changes in wallet.dat db things.
(When I wanted to bring a wallet.dat from 2011 to current versions of Core around 2020, I couldn't do it in one step (don't remember what newer Core complained about). It worked for me by gradually stepping up the Core version and have every version update what's necessary to the wallet.dat.


Important notice:
If you do recovery work, never work on the original storage media! Make multiple redundant forensic copies and only work on copies you can safely and reliably re-create if something fails or doesn't succeed.

[CryptoJ0hn]

I have everything, private key and wallet is not encrypted... but they seem to be gone

Why not make a raw dump and look for lost keys there? If the hdd hasn't been used to write data since then, it makes sense.

[Cricktor]

~~~

Why would private keys be lost from a wallet.dat file that doesn't seem to have been corrupted? Nothing hints so far to possible file corruption issues or did I miss something in gigi0ne's posts?

Private keys in wallet.dat files that have a key pool of random non-deterministic keys can be lost if you restore a backup file that has a smaller key pool size. Your original wallet had to extend its key pool because existing keys were exhausted by use, you loose this file for whatever reasons and only have a wallet backup of before the key pool was extended. Then you loose the former newly keys that were created to extend the wallet's key pool.

If the magnetic recording on the HDD's platter surfaces degraded enough to cause data corruption, the user would get read-errors and problably would've had severe issues to get a working wallet.dat from such a situation.

HDD technology and bit density of devices before and around 2009 weren't particularly problematic to assume you can't read the data after about 15 of non-use. (OK, we don't know anything about the drive's storage conditions.) It's not flash memory technology where trapped charges in flash cells can dissipate over time, especially more problematic with multi-bit cells.

Harddrives that aren't used for many years most commonly have other problems, mostly spin-up related and/or lubrication of motor spindle bearings.

[gigi0ne]

Hello,

the wallet is perfectly intact, I extracted all the private keys.


At the start of the program I have all the transactions, both those accepted with the tick and the number of acceptances, and those in the process of being accepted.


The problem is that when the program does reindex, they all become 0/unconfirmed, not in memory pool.

How is it possible that the transactions accepted in 2009 now have different hashes and thus are not recognized?


Shouldn't the hash of a block or transition be immutable?

if there was a way to post screenshots you would understand what I am saying easily

[mcdouglasx]

Hello,

the wallet is perfectly intact, I extracted all the private keys.


At the start of the program I have all the transactions, both those accepted with the tick and the number of acceptances, and those in the process of being accepted.


The problem is that when the program does reindex, they all become 0/unconfirmed, not in memory pool.

How is it possible that the transactions accepted in 2009 now have different hashes and thus are not recognized?


Shouldn't the hash of a block or transition be immutable?

if there was a way to post screenshots you would understand what I am saying easily

I recommend you check the corresponding mined blocks from the blockchain and validate that it was not claimed by another address.

[hosemary]

The problem is that when the program does reindex, they all become 0/unconfirmed, not in memory pool.

The message means that the transaction doesn't exist in the blockchain or the mempool.
The transactions exist only in the wallet file and once you abandon it, you will no longer see that in your wallet.

How is it possible that the transactions accepted in 2009 now have different hashes and thus are not recognized?

Most probably, the transaction wasn't broadcasted to the network successfully at all, let alone being included in the blockchain.

if there was a way to post screenshots you would understand what I am saying easily

Upload your image to talkimg and share the link here.

[apogio]

Most probably, the transaction wasn't broadcasted to the network successfully at all, let alone being included in the blockchain.

That's what I think too.

The thing is, OP said that they have found all the private keys.

If there were non-broadcasted transactions, shouldn't they be able to see the UTXOs inside the wallet? OP claims that the private keys lead to empty addresses.

[hosemary]

If there were non-broadcasted transactions, shouldn't they be able to see the UTXOs inside the wallet? OP claims that the private keys lead to empty addresses.

The transaction in question is coinbase.
I think OP have a fake wallet showing he has mined bitcoin. Once he did reindex, the transaction status changed to "0/unconfirmed, not in memory pool" which means that the transaction was neither found in the blockchain nor in OP's own mempool.

[apogio]

The transaction in question is coinbase.
I think OP have a fake wallet showing he has mined bitcoin. Once he did reindex, the transaction status changed to "0/unconfirmed, not in memory pool" which means that the transaction was neither found in the blockchain nor in OP's own mempool.

To be honest, it looks like one of the million cases where people sell "satoshi era" wallet.dat files. But OP says it was their brother's computer, so I respect their statement.

[gigi0ne]

https://www.talkimg.com/images/2024/10/13/8RFEw.jpeg
https://www.talkimg.com/images/2024/10/13/8Rzw3.jpeg

I don't understand how it can be fake, it was in my brother's pc who didn't understand anything about computers and moreover it's from 2009 also the date of the last modification (of the wallet.dat)

[apogio]

Your coinbase transactions must be P2PK.

Let's try the following. Suppose that you have 1 private key in WIF format:

Step 1: Create a descriptor for the private key:

Code:

bitcoin-cli getdescriptorinfo "pk(<wif>)"

It will produce something like that:

Code:

{                                                                                                                                                                                  
  "descriptor": "pk(<wif>)#vl2598s2",                                                                                 
   "checksum": "0hjwa0sj",
  "isrange": false,                                                                       
  "issolvable": true,                                                                                                                                                              
  "hasprivatekeys": true                                                                                                                                                           
}

Step 2: Create a wallet and import this descriptor:

Code:

 bitcoin-cli createwallet p2pk_recovery false true 

Step 3: Import the descriptor

Code:

 bitcoin-cli -rpcwallet=p2pk_recovery importdescriptors '[{"desc":"pk(<wif>)#<checksum from step 2>","timestamp":"now"}]' 

Step 4: rescan blockchain:

Code:

 bitcoin-cli -rpcwallet=p2pk_recovery rescanblockchain <from> <to>  

from and to are the number of blocks to rescan, I suggest using ~15000 which was the block numbers back then, but check it yourself too.

Step 4: List unspent UTXOs

Code:

  bitcoin-cli -rpcwallet=p2pk_recovery listunspent  

source: https://bitcoin.stackexchange.com/questions/118127/how-to-recover-and-sweep-p2pk-coins