Why Craig Wright Is Not Satoshi Nakamoto

Why Craig Wright's PGP signature is worthless and he isn't Satoshi Nakamoto
Why Craig Wright's PGP signature is worthless and he isn't Satoshi Nakamoto

Update: Craig Wright doesn’t claim he’s Satoshi Nakamoto anymore.

The news that Craig Wright has come out as Satoshi Nakamoto is still making waves across the Bitcoin community. But Cointelegraph’s Andrew Quenston doesn’t buy that, and claims to have  evidence to the contrary.

When the community has learned that Craig Wright, an entrepreneur from Australia claims he was Satoshi Nakamoto, the legendary author of Bitcoin’s whitepaper and protocol, people started taking sides on the issue. Many believe the evidence provided by Wright. The claim was made stronger by Gavin Andersen, one of the core Bitcoin developers, who commented:

“I was flown to London to meet Dr. Wright a couple of weeks ago, after an initial email conversation convinced me that there was a very good chance he was the same person I’d communicated with in 2010 and early 2011. After spending time with him I am convinced beyond a reasonable doubt: Craig Wright is Satoshi.”

However, others, Cointelegraph’s Andrew Quenston included, have provided evidence to support the contrary point of view, that Wright is not Satoshi.

Today, Cointelegraph has decided to reduce speculation to the minimum and take a look at hard facts. We have thoroughly analyzed the evidence which, as Wright alleges, proves him to be Satoshi, and here are the results of that analysis:

1. Craig took the number 9 block from Bitcoin blockchain, which was mined on January 9, 2009.

2. Then he took its coinbase transaction, i.e. the mining transaction which created 50 new bitcoins and credited it to the adress

12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S

The hash of that transaction is

0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9

3. That transaction was sent to the following address:

12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S which corresponds to the following public key:

0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3

4. Thus we have the public key starting with 0411.. which has to have a specific corresponding private key. The latter should only be known by the owner of that wallet - namely, Satoshi, because it’s one of the very first wallets in the Bitcoin network.

5. Now let’s find any single case of use of that private key. Obviously, that would be any transaction which spends the outputs of the wallet starting with 12cb… Check the output script here.

We can see every transaction which was sent from that wallet here.

6. Among them, Craig has picked a transaction with the following hash - 

828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe.

7. In that transaction we can see that out of the 28btc worth of outputs, 10btc was sent to the following address:

1ByLSV2gLRcuqUmfdYcpPQH8Npm8cccsFg.

And 18btc worth of change was returned to the 12cb… wallet

In that transaction, we can see the following signature

3045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce01

8. According to the Bitcoin protocol, this signature 3045… is derived from the algorithm specified here.

According to the algorithm, we have to take the transaction , modify it slightly (extracting the transaction body as a result), apply the hashing procedure twice and use the resulting data as an input for the signature algorithm.

9. Thus, the signature 3045… = ECDSA(sha(sha(transaction body))

It’s important to keep in mind that the transaction body is known by everyone, or, rather, it is derived from public data. Roughly, it contains the address to which sender transfers money to.

10. Then Craig follows the algorithm mentioned in stage 8 (except for the last step when the data is signed) applying it to transaction 828ef... The steps are the following:

10.1. Request the raw transaction 828e...

bitcoin-cli getrawtransaction

828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe

The result:

0100000001ba91c1d5e55a9e2fab4e41f55b862a73b24719aad13a527d169c1fad3b63b5120100000049483045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce01ffffffff0200ca9a3b00000000434104bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f016826ee6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508ac00d2496b0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000

10.2. The transaction 828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe spends the first output of this transaction:

12b5633bad1f9c167d523ad1aa1947b2732a865bf5414eab2f9e5ae5d5c191ba.

Then we take the script for this output: 

0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3

10.3. Using the raw transaction

828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe

and the script we’ve got as the result of the stage #10.2, we derive the data which will then be hashed and signed.

The result:

0100000001ba91c1d5e55a9e2fab4e41f55b862a73b24719aad13a527d169c1fad3b63b5120100000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9a3b00000000434104bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f016826ee6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508ac00d2496b0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac000000000

10.4. Then we attach the hashcode (in our case it’s 01000000) to the end of that data

The result:

0100000001ba91c1d5e55a9e2fab4e41f55b862a73b24719aad13a527d169c1fad3b63b5120100000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9a3b00000000434104bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f016826ee6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508ac00d2496b0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000001000000

That string is the body of our transaction, ready to be signed.

11. After that, Craig took the transaction body we’ve got after the stage #10 and ran it through SHA one time, instead of two. He got this: 

479f9dff0155c045da78402177855fdb4f0f396dc0d2c24f7376dd56e2e68b05

Which he has posted on his website.

After that it’s all smoke and mirrors:

12. Craig has put the body of the transaction derived above into a new file named sn7-message.txt and posted it in his article. Naturally, if we calculate the hashsum of that file, it will be the same:

479f9dff0155c045da78402177855fdb4f0f396dc0d2c24f7376dd56e2e68b05

13. And, seemingly to prove the fact that he owns the private key we’ve mentioned under point #5, he mentions the fact that 3045...

= ECDSA(sha(479f9dff0155c045da78402177855fdb4f0f396dc0d2c24f7376dd56e2e68b05))

Which is indeed the key, at least judging by its structure. However, it has nothing to do with the original 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S address and doesn't prove that Craig owns the private keys of that address.

It’s also worth noting that the following string:

MEUCIQDBKn1Uly8m0UyzETObUSL4wYdBfd4ejvtoQfVcNCIK4AIgZmMsXNQWHvo6KDd2Tu6euEl13VTC3ihl6XUlhcU+fM4=

Is actually another string, encoded via Base64:

3045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce

Thus, even though Craig’s article contained certain technical data, which could mislead the readers, it does not prove that Craig owns Satoshi’s private keys. What’s more, we could apply the very same process to another transaction to generate a similar “proof”. Let’s apply the logic above to a completely different transaction:

1. Take the 286 block.

2. Take its coinbase transaction

00ff9e64c9a2e7793e6f8c2b04072b4b22648cdedd46cd1c3ae3d6a23c8ec1eb.

3. That transaction sends the reward to the following address: 1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9.

That address has the following public key:

048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd

Which can be checked here.

4. Take all transactions for the following address

1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9.

5. There is just one transaction which spends money from that address:

d71fd2f64c0b34465b7518d240c00e83f6a5b10138a7079d1252858fe7e6b577.

Hence, that transaction is signed by a private key, corresponding to that same address:

1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9.

6. Then we extract the raw transaction d71f...

bitcoin-cli getrawtransaction

d71fd2f64c0b34465b7518d240c00e83f6a5b10138a7079d1252858fe7e6b577

The result:

0100000001ebc18e3ca2d6e33a1ccd46ddde8c64224b2b07042b8c6f3e79e7a2c9649eff000000000048473044022038ea59740da72eec2490a0b32fa6004139524fefba7e78c5d0aed40a5c07f39b02205b1adea529c3cc5cdbb900a8515d778b8e982d63b13386d955962a93f70cd27101ffffffff0200f9029500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf63841474712e4cf0459356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530492dcac00f90295000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdac00000000

7. Transaction

d71fd2f64c0b34465b7518d240c00e83f6a5b10138a7079d1252858fe7e6b577 spends the output #0 of the coinbase transaction:

00ff9e64c9a2e7793e6f8c2b04072b4b22648cdedd46cd1c3ae3d6a23c8ec1eb.

8. Let’s take the script of that output:

bitcoin-cli getrawtransaction

00ff9e64c9a2e7793e6f8c2b04072b4b22648cdedd46cd1c3ae3d6a23c8ec1eb 0

The result:

048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd

9. Using the raw transaction and script, we extract the body of the transaction, which will be hashed and signed.

The result:

0100000001ebc18e3ca2d6e33a1ccd46ddde8c64224b2b07042b8c6f3e79e7a2c9649eff000000000041048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdffffffff0200f9029500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf63841474712e4cf0459356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530492dcac00f90295000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdac00000000

10. Then we add the hashcode string, which is 01000000.

The result:

0100000001ebc18e3ca2d6e33a1ccd46ddde8c64224b2b07042b8c6f3e79e7a2c9649eff000000000041048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdffffffff0200f9029500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf63841474712e4cf0459356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530492dcac00f90295000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdac0000000001000000

11. After that, we apply SHA256 to that data and receive:

6b2bbb486994a570c0d3bcde506035a1f858983ac3c89881c6cbc63265ad9b66

12. Now we have:

The data we sign:

6b2bbb486994a570c0d3bcde506035a1f858983ac3c89881c6cbc63265ad9b66

The public key:

048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd

And the digital signature:

3044022038ea59740da72eec2490a0b32fa6004139524fefba7e78c5d0aed40a5c07f39b02205b1adea529c3cc5cdbb900a8515d778b8e982d63b13386d955962a93f70cd27101

The same signature encoded via base64:

MEQCIDjqWXQNpy7sJJCgsy+mAEE5Uk/vun54xdCu1ApcB/ObAiBbGt6lKcPMXNu5AKhRXXeLjpgtY7EzhtlVliqT9wzScQE=

13. As a result, the signature was taken out of the script of the transaction output #0, which spends money from the following address: 

1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9.

Thus, we could claim that we own private key of that address. However, as it was stated above, this would only be a trick to make readers believe we own the key. The proof manipulates  Bitcoin technical notions and some data but is completely invalid. 

After analyzing the above information, it’s pretty safe to say that Craig Wright has not provided any publicly available evidence to support his claim, so the news are most likely fake. Some could say that that was self-evident: after all, many people have claimed to be Satoshi Nakamoto over the last several years, and none have managed to really convince the community.

However, consider this: after being actively involved with Bitcoin network for more than 2 years, Satoshi has decided to disappear from the scene completely, leaving no trace behind. Whatever the reasons, it’s clear that the person (or the group of people) behind that name doen’t want their actual identities to be known.

And what is the best way to stay out of sight, if not to intentionally send the seekers on false leads? Could the invalid proof be posted on purpose to make us believe it is not Satoshi? Could it be that Satoshi is indeed involved with all the false reveals, but as their hidden architect, rather than the actual hero?

Update: Craig Wright doesn’t claim he’s Satoshi Nakamoto anymore.