http://cointelegraph.com/news/why-craig-wright-is-not-satoshi-nakamoto
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:
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
The hash of that transaction is
12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S which corresponds to the following public key:
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 - 7. In that transaction we can see that out of the 28btc worth of outputs, 10btc was sent to the following address:
And 18btc worth of change was returned to the 12cb… wallet
In that transaction, we can see the following signature
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...The result:
10.3. Using the raw transactionand 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:
10.4. Then we attach the hashcode (in our case it’s 01000000) to the end of that data
The result:
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:
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:
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...
It’s also worth noting that the following string:
1. Take the 286 block.
2. Take its coinbase transaction
3. That transaction sends the reward to the following address: 1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9.
That address has the following public key:
4. Take all transactions for the following address
5. There is just one transaction which spends money from that address:Hence, that transaction is signed by a private key, corresponding to that same address:
6. Then we extract the raw transaction d71f...The result:
7. Transaction
d71fd2f64c0b34465b7518d240c00e83f6a5b10138a7079d1252858fe7e6b577 spends the output #0 of the coinbase transaction:
8. Let’s take the script of that output:
9. Using the raw transaction and script, we extract the body of the transaction, which will be hashed and signed.
The result:
10. Then we add the hashcode string, which is 01000000.
The result:
11. After that, we apply SHA256 to that data and receive:
12. Now we have:
The data we sign:
13. As a result, the signature was taken out of the script of the transaction output #0, which spends money from the following address:
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?
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
The hash of that transaction is
0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9
3. That transaction was sent to the following address:
12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S which corresponds to the following public key:
0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909
a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
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.a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
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 - 7. In that transaction we can see that out of the 28btc worth of outputs, 10btc was sent to the following address:
And 18btc worth of change was returned to the 12cb… wallet
In that transaction, we can see the following signature
3045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae
0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce01
8. According to the Bitcoin protocol, this signature 3045… is derived from the algorithm specified here.0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce01
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...The result:
0100000001ba91c1d5e55a9e2fab4e41f55b862a73b24719aad13a527d169c1fad3b63b5
120100000049483045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb
6841f55c34220ae0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e97
52585c53e7cce01ffffffff0200ca9a3b00000000434104bed827d37474beffb37efe533701a
c1f7c600957a4487be8b371346f016826ee6f57ba30d88a472a0e4ecd2f07599a795f1f01
de78d791b382e65ee1c58b4508ac00d2496b0000000043410411db93e1dcdb8a016b498
40f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160b
fa9b8b64f9d4c03f999b8643f656b412a3ac00000000
10.2. The transaction 828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe spends the first output of this transaction:Then we take the script for this output: 120100000049483045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb
6841f55c34220ae0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e97
52585c53e7cce01ffffffff0200ca9a3b00000000434104bed827d37474beffb37efe533701a
c1f7c600957a4487be8b371346f016826ee6f57ba30d88a472a0e4ecd2f07599a795f1f01
de78d791b382e65ee1c58b4508ac00d2496b0000000043410411db93e1dcdb8a016b498
40f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160b
fa9b8b64f9d4c03f999b8643f656b412a3ac00000000
0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0ea
ddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
ddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
10.3. Using the raw transactionand 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:
0100000001ba91c1d5e55a9e2fab4e41f55b862a73b24719aad13a527d169c1fad3b63b51201
00000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c
b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9a3
b00000000434104bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f016826e
e6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508ac00d2496b000
0000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb
2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac000000000
00000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c
b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9a3
b00000000434104bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f016826e
e6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508ac00d2496b000
0000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb
2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac000000000
10.4. Then we attach the hashcode (in our case it’s 01000000) to the end of that data
The result:
0100000001ba91c1d5e55a9e2fab4e41f55b862a73b24719aad13a527d169c1fad3b63b51201
00000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5
cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9
a3b00000000434104bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f0168
26ee6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508ac00d249
6b0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6
909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3a
c00000000001000000
That string is the body of our transaction, ready to be signed.00000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5
cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9
a3b00000000434104bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f0168
26ee6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508ac00d249
6b0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6
909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3a
c00000000001000000
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:
MEUCIQDBKn1Uly8m0UyzETObUSL4wYdBfd4ejvtoQfVcNCIK4AI
gZmMsXNQWHvo6KDd2Tu6euEl13VTC3ihl6XUlhcU+fM4=
Is actually another string, encoded via Base64:gZmMsXNQWHvo6KDd2Tu6euEl13VTC3ihl6XUlhcU+fM4=
3045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae0
022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce
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:022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce
1. Take the 286 block.
2. Take its coinbase transaction
3. That transaction sends the reward to the following address: 1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9.
That address has the following public key:
048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3
e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd
Which can be checked here.e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd
4. Take all transactions for the following address
5. There is just one transaction which spends money from that address:Hence, that transaction is signed by a private key, corresponding to that same address:
6. Then we extract the raw transaction d71f...The result:
0100000001ebc18e3ca2d6e33a1ccd46ddde8c64224b2b07042b8c6f3e79e7a2c9649eff0000
00000048473044022038ea59740da72eec2490a0b32fa6004139524fefba7e78c5d0aed40a5
c07f39b02205b1adea529c3cc5cdbb900a8515d778b8e982d63b13386d955962a93f70cd271
01ffffffff0200f9029500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf638
41474712e4cf0459356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530
492dcac00f90295000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b9
4c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667
eea5fdac00000000
00000048473044022038ea59740da72eec2490a0b32fa6004139524fefba7e78c5d0aed40a5
c07f39b02205b1adea529c3cc5cdbb900a8515d778b8e982d63b13386d955962a93f70cd271
01ffffffff0200f9029500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf638
41474712e4cf0459356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530
492dcac00f90295000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b9
4c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667
eea5fdac00000000
7. Transaction
d71fd2f64c0b34465b7518d240c00e83f6a5b10138a7079d1252858fe7e6b577 spends the output #0 of the coinbase transaction:
8. Let’s take the script of that output:
bitcoin-cli getrawtransaction
00ff9e64c9a2e7793e6f8c2b04072b4b22648cdedd46cd1c3ae3d6a23c8ec1eb 0
The result:00ff9e64c9a2e7793e6f8c2b04072b4b22648cdedd46cd1c3ae3d6a23c8ec1eb 0
048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0f
d3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd
d3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd
9. Using the raw transaction and script, we extract the body of the transaction, which will be hashed and signed.
The result:
0100000001ebc18e3ca2d6e33a1ccd46ddde8c64224b2b07042b8c6f3e79e7a2c9649eff0000
00000041048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32
d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdffffffff0200f9029
500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf63841474712e4cf045
9356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530492dcac00f9029
5000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e
24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdac00000000
00000041048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32
d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdffffffff0200f9029
500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf63841474712e4cf045
9356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530492dcac00f9029
5000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e
24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdac00000000
10. Then we add the hashcode string, which is 01000000.
The result:
0100000001ebc18e3ca2d6e33a1ccd46ddde8c64224b2b07042b8c6f3e79e7a2c9649eff0000
00000041048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32
d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdffffffff0200f9029
500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf63841474712e4cf04
59356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530492dcac00f9029
5000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e
24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdac00
00000001000000
00000041048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32
d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdffffffff0200f9029
500000000434104f36c67039006ec4ed2c885d7ab0763feb5deb9633cf63841474712e4cf04
59356750185fc9d962d0f4a1e08e1a84f0c9a9f826ad067675403c19d752530492dcac00f9029
5000000004341048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e
24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fdac00
00000001000000
11. After that, we apply SHA256 to that data and receive:
6b2bbb486994a570c0d3bcde506035a1f858983ac3c89881c6cbc63265ad9b66
12. Now we have:
The data we sign:
6b2bbb486994a570c0d3bcde506035a1f858983ac3c89881c6cbc63265ad9b66
The public key:
048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b
0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd
And the digital signature:0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd
3044022038ea59740da72eec2490a0b32fa6004139524fefba7e78c5d0aed40a5c07f39b02205b1
adea529c3cc5cdbb900a8515d778b8e982d63b13386d955962a93f70cd27101
The same signature encoded via base64:adea529c3cc5cdbb900a8515d778b8e982d63b13386d955962a93f70cd27101
MEQCIDjqWXQNpy7sJJCgsy+mAEE5Uk/vun54xdCu1ApcB/ObAiBbGt6lKcPMXNu5 AKhRXXeLjpgtY7EzhtlVliqT9wzScQE=
13. As a result, the signature was taken out of the script of the transaction output #0, which spends money from the following address:
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?
Last edited:
