historical blk00000 coinbase analysis: multiple coinbase blocks w/ same addr Q

[DougM]

I am trying to gain a better understanding of Bitcoin's blockchain by studying the earliest coinbase transactions from blk00000.dat.  I have encountered a couple of anomalies that I was hoping to have some of the subject matter experts here help me understand.  Here is my first question.  I did attempt to make sure this wasn't explained already and I did find this related thread from Jan 2011:   https://bitcointalk.org/index.php?topic=2924.0

In this thread author observed that same thing I did that I was surprised to find. Namely multiple coinbase blocks with the same output address. In blk00000.dat I counted 85 distinct output addresses that each have two coinbase blocks.  This topic covers this interesting anomaly mostly, but there is one pair of blocks with the same output address that is especially odd that I was hoping to get some more insight:

two confirmed coinbase transactions both going to the same output address: 15w6iQpfmsKwHswaUoWNWhyjAftrU1b3yB (odd/rare), both at almost the same time (2010-07-26 14:11:19 vs. 2010-07-26 14:11:42) (glitch ?)

https://www.blockchain.com/btc/tx/8e23d308dbf39973133184a3261f9b9d0d7fd54c1cfd62407ff3cf7ac9b6b4bc   (@2010-07-26 14:11:42)
https://www.blockchain.com/btc/tx/555948071157710897c957e16c91687d81116d01089a167e2978b86a295df762 (@2010-07-26 14:11:19)

This address isn't dormant/dead address either.  It received and sent bitcoins later in 2010 and even in 2015. However,  the two original coinbase transactions are interesting because one 8e23... mined coins were spent, but the mined coins from 5559... transactions were not.  Are the coins from 5559 actually legit and unspent?

Can someone take a look at these transactions and help me understand what likely happened?

Thanks in advance!

[1714165339]

1714165339

[1714165339]

1714165339

[TheArchaeologist]

Namely multiple coinbase blocks with the same output address. In blk00000.dat I counted 85 distinct output addresses that each have two coinbase blocks.

A miner is the one who sets the address to where the coinbase (newly generated coins) should be paid out to. If a miner wants this to be the same address for every found block that's within the rules of the Bitcoin protocol. In the beginning there was just bitcoin core as software for mining which used a different address for every mined block, that's why you see a lot of different addresses for coinbase payouts in the first year. If you would look at the current blocks payouts to the same address happen a lot.

Two confirmed coinbase transactions both going to the same output address: 15w6iQpfmsKwHswaUoWNWhyjAftrU1b3yB (odd/rare), both at almost the same time (2010-07-26 14:11:19 vs. 2010-07-26 14:11:42) (glitch ?)

https://www.blockchain.com/btc/tx/8e23d308dbf39973133184a3261f9b9d0d7fd54c1cfd62407ff3cf7ac9b6b4bc   (@2010-07-26 14:11:42)
https://www.blockchain.com/btc/tx/555948071157710897c957e16c91687d81116d01089a167e2978b86a295df762 (@2010-07-26 14:11:19)

Both the linked blocks were found in succession (height 70459 and 70460). So what could have happened the later block was found just a few seconds after the first one. The bitcoin protocol has a target to find a block every 10 minutes on average, that doesn't rule a block can't be found just seconds after a previous one.

You also have to realize the miner is also the one who sets the timestamp for the block, so it is even possible the blocks were found further apart in time but the timestamp was just set "incorrectly".

If you continue your study you will also find that there are two coinbase-transactions with the same transaction-id. That's something that was a real glitch and has been fixed in the protocol so it can't happen again.

Hope this was clear, if not please ask more

[achow101]

A scenario where this could happen is that a person is running two instances of the bitcoin software (in 2010, the software had cpu mining capabilities) on different machines with the same wallet file. Under this scenario, it is likely that he had copied the data from one machine to the other, which includes the wallet file. Then set both machines to start mining. Because they are using the same wallet, they will use the same pubkeys in their blocks.

So what happened is that this miner got lucky and both machines mined blocks. It is not unusual to see blocks with times very close to each other. It just means that the miner got lucky.

This address isn't dormant/dead address either.  It received and sent bitcoins later in 2010 and even in 2015. However,  the two original coinbase transactions are interesting because one 8e23... mined coins were spent, but the mined coins from 5559... transactions were not. 

This "address" (it isn't an address actually. blockchain.info is displaying this incorrectly) has only sent Bitcoin once. This "address" received Bitcoin in 2015 from a low amount spammer. These spammers will just send small amounts of Bitcoin to random addresses, usually for tracking purposes.

Additionally, the particular scriptPubKey used in the coinbases is a P2PK scriptPubKey. This scriptPubKey does not actually have an address. If you look for just this scriptPubKey, you will find it was only used in those 2 coinbase transactions.

It is not unusual for an "address" with multiple UTXOs to create a transaction that leaves out some of its UTXOs. Nothing strange about that.

Are the coins from 5559 actually legit and unspent?

Yes. Just because they haven't moved doesn't mean they aren't.

[DougM]

Thank you achow101. That was a *very* informative response!  I am sorry for the newbie questions, but I won't learn if I don't ask 

[pooya87]

A scenario where this could happen is that a person is running two instances of the bitcoin software (in 2010, the software had cpu mining capabilities) on different machines with the same wallet file. Under this scenario, it is likely that he had copied the data from one machine to the other, which includes the wallet file. Then set both machines to start mining. Because they are using the same wallet, they will use the same pubkeys in their blocks.

but wallet files of early bitcoin core versions (before 0.13/2016 i believe) weren't deterministic and as far as i can tell the miner was getting a new keypair before mining which meant generating a new key would have given it an entirely different pubkey to mine to.

[TheArchaeologist]

A scenario where this could happen is that a person is running two instances of the bitcoin software (in 2010, the software had cpu mining capabilities) on different machines with the same wallet file. Under this scenario, it is likely that he had copied the data from one machine to the other, which includes the wallet file. Then set both machines to start mining. Because they are using the same wallet, they will use the same pubkeys in their blocks.

but wallet files of early bitcoin core versions (before 0.13/2016 i believe) weren't deterministic and as far as i can tell the miner was getting a new keypair before mining which meant generating a new key would have given it an entirely different pubkey to mine to.

Exactly, I would like to see what @achow101 thinks of that.

[ABCbits]

A scenario where this could happen is that a person is running two instances of the bitcoin software (in 2010, the software had cpu mining capabilities) on different machines with the same wallet file. Under this scenario, it is likely that he had copied the data from one machine to the other, which includes the wallet file. Then set both machines to start mining. Because they are using the same wallet, they will use the same pubkeys in their blocks.

but wallet files of early bitcoin core versions (before 0.13/2016 i believe) weren't deterministic and as far as i can tell the miner was getting a new keypair before mining which meant generating a new key would have given it an entirely different pubkey to mine to.

AFAIK bitcoin wallet have key pool feature which generate some private keys in advance, that might be the reason wallet on both PC uses same address.

The only odd thing is earliest thread mentioning key pool that i could find is from October 2010

[achow101]

A scenario where this could happen is that a person is running two instances of the bitcoin software (in 2010, the software had cpu mining capabilities) on different machines with the same wallet file. Under this scenario, it is likely that he had copied the data from one machine to the other, which includes the wallet file. Then set both machines to start mining. Because they are using the same wallet, they will use the same pubkeys in their blocks.

but wallet files of early bitcoin core versions (before 0.13/2016 i believe) weren't deterministic and as far as i can tell the miner was getting a new keypair before mining which meant generating a new key would have given it an entirely different pubkey to mine to.

Exactly, I would like to see what @achow101 thinks of that.

Prior to 0.13, wallets had a keypool of 100 keys. Even with it being non-HD, there was still a lookahead of 100 keys, that's why you didn't have to backup the wallet every transaction. The keys in the keypool were still randomly generated.

However it seems that the keypool feature wasn't introduced until 0.3.14 in October 2010. The latest version available at the time of these blocks being mined appears to be 0.3.2. I had thought that the keypool feature was implemented earlier than it actually was.

The miner in the original software generated a new key every time it started. A new key would also be generated when it had found and submitted a new block so it would be using a new key on the next block it worked on. This new key was randomly generated. So what I described previously was not possible at this point in time.

The only other reasonable explanation I can think of is the miner simply modified his software to use a fixed pubkey.

[pooya87]

The only other reasonable explanation I can think of is the miner simply modified his software to use a fixed pubkey.

this would be my guess too.
in fact recently i read some of the researches done about "Satoshi coins" and reading them, specially their arguments about extra-nonce has me convinced that there were multiple miners in early years that were using modified or alternative code to mine bitcoin.