Doubts on the attribution of two blocks to miner Patoshi

[cricktor]

I have some doubts that the blocks 35573 and 35599 should belong to the list of Patoshi blocks. Why?

Well, there's the transaction ID 907bc01510f15727d4db00a188309c0bb7cf47dd76dac1b2f8624eb2ef4f7d75 in block 492919 which spends 3000.0026BTC from 86 inputs (60 first spends of coinbase UTXOs mined from around block heights of 35xxx, ie. 7 year dormant block rewards) to two outputs which get spent further on and on. Two of those 86 inputs are first spends of two Patoshi P2PK coinbase outputs and two P2PKH outputs of 10000sat each sent to the P2PKH addresses of those two Patoshi blocks 35573 and 35599.

When we assume that all inputs of a transaction are owned or in control by one entity, this means that the owner of the 58 other non-Patoshi coinbase UTXOs controlled also the two mentioned coinbase UTXOs of blocks 35573 and 35599.

Regardless if you believe that the miner Patoshi is Satoshi or not, to me there's evidence with above mentioned transaction that those two blocks shouldn't be attributed to the miner Patoshi. It doesn't make sense to me: if those two blocks belong to Patoshi, then Patoshi had control of at least 58 other blocks that weren't attributed to Patoshi. Or some entity not being Patoshi got somehow the private keys to spend the two Patoshi block coinbase UTXOs? That's sounds even more crazy.

What do you think? Did I miss something?

(As I don't use Twitter, I didn't contact Sergio Demian Lerner of http://satoshiblocks.info via his Twitter account to ask him about my finding and what he thinks of it. I'm not even sure if this here is the right place to discuss this, but I didn't want to open an issue without prior public talk about it.)

[pointbiz]

https://bitslog.com/2013/04/17/the-well-deserved-fortune-of-satoshi-nakamoto/

https://bitslog.files.wordpress.com/2013/04/upto36288.xls

Blocks 35573 and 35599 appear in the Patoshi set defined above by SDL.

Tx ID
907bc01510f15727d4db00a188309c0bb7cf47dd76dac1b2f8624eb2ef4f7d75

Spends the two Patoshi coinbases from the specified blocks on 2017-11-03.

Are you the only one who has noticed?

[SergioDemianLerner]

They could be false positives of the slope finding algorithm, and by chance they happen to have the nonce LSB in Patoshi's range.
The fact their extra nonce is low indicates that the probability of misattribution is higher. Visually in the graph, there is another line crossing Patoshi slope at point 35599.

[SergioDemianLerner]

The Patoshi pattern finding algorithm attributes blocks with different probabilities. Some blocks are unequivocally Patoshi's, some are really hard to tell. In case of doubt, the algorithm checks if the coinbase is unspent, and in that case it considers the block part of Patoshi.

I don't think a block explorer should attribute blocks to Patoshi without a warning that there are false positives and false negatives. The interesting thing is that even if you subtract all disputed blocks from the grand total, it doesn't change much the amount of bitcoins mined by Patoshi.

[pointbiz]

Thank you for these insights (and all you've done for Bitcoin).

The warning of false positives and false negatives is a good idea for this explorer as this project has an educational aspect to it.

Is there anywhere else you know of we can see a list of disputed Patoshi blocks? One's that were spent after your 2013 blog post?

[janoside]

Thanks for the detailed responses.

The Patoshi-tagged blocks have always included a disclaimer, but I'll tweak the UI to raise its visibility.

[cricktor]

I have read almost all blog post by SDL and follow the topic with interest. A prior Google search regarding the transaction ID of the spending transaction didn't reveal any hits despite from the blockchain explorer of blockchain.com, no discussions about it found.

So, maybe I'm the first who noticed this.

Yes, Tx ID
907bc01510f15727d4db00a188309c0bb7cf47dd76dac1b2f8624eb2ef4f7d75 spends those two Patoshi coinbases together (!) with 58 other non-Patoshi coinbases. That caught my attention... If you ask why, see below.

Some time ago I compiled a watch-only Electrum wallet of all P2PKH addresses of Patoshi coinbase outputs. Only to learn that P2PK outputs, basically all Patoshi coinbases, are "invisible" for Electrum servers and clients. But this particular transaction is visible in my watch-only Patoshi wallet (in fact it's the only spending transaction that is visible for Electrum) because of the small "donation" P2PKH transactions on derived legacy Bitcoin addresses of Patoshi coinbase outputs.

I compiled a proper Bitcoin Core descriptor wallet which is capable to track any output type of Patoshi coinbase outputs, but unfortunately syncing (full scan over the whole blockchain) this wallet with 21594 descriptors based on the public keys of the coinbase outputs takes a very very long time (I'm speaking of months for the necessary rescan to capture any involved transaction and I'm somewhere at blockheight around 500000 at the moment; progress crawls slowly forward).

[jlopp]

Chiming in with some of my own research:

As you're probably aware, Patoshi never mined blocks with timestamps less than 300 seconds after the previous block (after the first couple hundred blocks.) As such I pose to you that block 24504, which actually intersects with another miner's extraNonce slope, is not Patoshi because its timestamp is only 65 seconds after the timestamp in the previous block.

[janoside]

Thanks all for the thoughtful additions here. For caution's sake I'll remove all 3 of the mentioned Patoshi-tagged blocks from the list in the explorer. Also, as mentioned above, I'll raise the UI visibility of the disclaimer associated with the Patoshi-tagging.