Quote from: nc50lc on October 14, 2024, 08:35:30 AM

Quote from: gigi0ne on October 13, 2024, 10:58:43 PM

I already have the addresses related to the various private keys and blockchain.com tells me they are P2WPKH how do I convert them to P2PKH?

Don't mind the displayed address in Bitcoin Core, it's an issue in the legacy version, the output is actually Pay-to-Pub-Key (P2PK) which has no address format.
I've checked the raw transaction "hex" in your screenshot and the result of decoderawtransaction command shows that the output script is P2PK:

Code:

"vout": [
   {
   "value": 50.00000000,
   "n": 0,
   "scriptPubKey": {
   "asm": "0353534d9d8cdd7255dc4eeac1a2e68004c75520917b775b0655f15cf073703be8 OP_CHECKSIG",
   "desc": "pk(0353534d9d8cdd7255dc4eeac1a2e68004c75520917b775b0655f15cf073703be8)#8plzldln",
   "hex": "210353534d9d8cdd7255dc4eeac1a2e68004c75520917b775b0655f15cf073703be8ac",
   "type": "pubkey"
   }
   }
  ]

Since those are all generated at the same timeframe, it's safe to assume that the others are P2PK as well.

At least you could tell that your brother must have used "generate" toggle option in the old Bitcoin client since it does that by default.
Problem is, he must had been mining a fork probably by being isolated to at least one peer that's also not connected to the rest of the bitcoin nodes who are mining/verifying the early blocks of the blockchain we have now.

Quote from: gigi0ne on October 13, 2024, 08:57:44 PM

done everything, is it normal that importdescriptors doesn't return anything? a true a false something....

You have an intact legacy wallet.dat containing the private keys, you don't need to import your key to a new wallet as pk descriptors.
A non-descriptor's default behavior is to search of outputs spendable by the private key(s) it holds, not by a specific script like a descriptor wallet.
Syncing the wallet using a legacy wallet-compatible version just 'till your transactions' block height should be enough to verify them, no extra steps.
If it verifies, good; if not, then the block where it's a reward of isn't included in the blockchain of every bitcoin node.

Quote from: gigi0ne on October 13, 2024, 03:23:45 PM

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?

Bitcoin isn't a single entity, it works by consensus.
When it comes to block; it means that all nodes in the network must have the exact copy of the block for it to be part of the Bitcoin blockchain.
You brother's wallet contains "coinbase transactions" (reward) from blocks that only his node knows since it's generated there,
but it's different from all of the other nodes' copy so it's not part of the Bitcoin blockchain.
In other words: it's "accepted" by his node in 2009 but not by the rest of the Bitcoin nodes.

This is really strange. The result of decoderawtransaction is "pk(0353534d9d8cdd7255dc4eeac1a2e68004c75520917b775b0655f15cf073703be8)#8plzldln", which is a compressed public key. How could compressed public keys exist in 2009? As far as I know, compressed public keys only began to be widely used around 2012.

The compressed public key 0353534d9d8cdd7255dc4eeac1a2e68004c75520917b775b0655f15cf073703be8 corresponds to the compressed P2PKH address 12bp69KNGPv3o5R8q1wbZBqAxtrv3GFS5P. The question is, how could compressed P2PKH addresses exist in 2009?