What does Craig Wright need to do to convince everyone that he is Satoshi Nakamoto?

A few hours ago, BBC, GQ and Economist published articles saying that they had found another Satoshi Nakamoto. This Satoshi Nakamoto is the one we found last December. When the news came out, my first reaction was that it was fake news, because Craig Wright has a criminal record. Last year, he forged a PGP (Note: PGP Pretty Good Privacy, an email encryption software based on the RSA public key encryption system) signature and used expired metadata to complete the signature, which was later discovered by everyone. There was even news about fake degrees.

But this time there is a blog by Gavin Anderson, a core developer of Bitcoin. In the blog, Gavin Anderson is convinced that Craig Wright is Satoshi Nakamoto (http://gavinandresen.ninja/satoshi). In the blog, Gavin said: I believe Craig Steven Wright is the person who invented Bitcoin. I believe Craig Steven Wright is the person who invented Bitcoin.

Seeing this, I just want to say: What happened? Could it be that Gavin was also fooled? However, based on the trust of the investor in Gavin, I believe something must have happened.

However, several public media reports did not clearly reveal whether Craig Wright used the private key corresponding to the Bitcoin address he mined earlier to sign effectively? This makes people wonder whether he is really Satoshi Nakamoto? Or whether Gavin's blog was hacked (this will be known later)

It is reported that the signature given by Craig Wright is this: MEUCIQDBKn1Uly8m0UyzETObUSL4wYdBfd4ejvtoQfVcNCIK4AIgZmMsXNQWHvo6KDd2Tu6euEl13VTC3ihl6XUlhcU+fM4=

After converting to hexadecimal, we get:

3045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae0

022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce

We can find this signature message in this transaction:

https://blockchain.info/tx/828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe?format=hex

This transaction occurred in block 248, on January 12, 2009.

This just shows that Craig Wright simply selected a public transaction and claimed that he owned the private key of this public key address. This is very suspicious because such an approach is not convincing.

It is also important to note that the first Bitcoin transaction occurred in the 170th Block. This transaction was sent from Satoshi to Hal Finney. Unless Craig Wright can prove that he owns the private key of the Bitcoin address in the previous 170 Blocks, or signs a message with the private key, we can confirm that Craig Wright is Satoshi Nakamoto.

Transaction occurred in Block 170

https://blockexplorer.com/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee

Let’s explain why it is untrustworthy for Craig Wright to choose a public signature and claim that he is the owner of this signature? Including what Craig Wright needs to do so that we can believe that he is Satoshi?

Let's first look at the basic principles of public keys, private keys, and digital signatures in cryptography:

  A digital signature needs to be analogous to a handwritten signature in the real world. We simulate handwritten signatures to design two properties required for digital signatures. First, as long as you can sign your signature, everyone can verify your signature. Second, we want the signature to be bound to a specific document and cannot be forged to be used to identify places where you did not sign. Because for a handwritten signature, it is like someone cannot cut off your signature separately and paste it onto a new document.

So how do we build these properties through cryptography? First, let's focus a little more on the topic at hand, which will give us a better understanding of digital signature schemes and some related security properties.

We note that generateKeys and   sign   A random algorithm can be used. In fact , generatekeys   It is best to randomize it, because different people need to generate different public and private keys .   The verify function does the opposite.   Functions should preferably be deterministic.

Now let's look at our two requirements for digital signatures in more detail. The first one is relatively straightforward, that is, all signatures must be verifiable. If I sign a message with my private key, and someone needs to verify my signature with my public key, then the verification result should be true. This property is a very fundamental property of digital signatures.

Unforgeability: The second property is that, under normal computing power, others cannot forge your signature. That is, if there is an adversary who knows your public key and some of your signatures on other messages, then this adversary cannot forge your signature on messages that you did not sign. Unforgeability is similar to a classic game that we often encounter in cryptography, and it is also a game that we often use as an example in security proofs in cryptography.

In the unforgeable game, there is a hacker who claims that he can forge signatures, and the challenged wants to test this hacker. The first thing we need to do is to generate a private key and a public key pair through the generatekeys function. We give the private key to the challenged, and we give the public key to both the challenged and the hacker. In this way, the hacker only knows some public information, and his task is to forge some signatures. The challenged knows the private key, so he can sign the message.

Intuitively, this challenge game conforms to some rules of the real world. A real-world attacker will also check the potential victim's real signature on some documents, and the attacker can also manipulate the victim to sign some documents that look harmless but are useful to the attacker in some way.

To model this game, we allow the attacker to have access to some real signed messages, and a significant number of real signed messages. We assume that the attacker can have access to a million real signed messages, but not 280.

Once the attacker has seen enough real signed messages, he will forge a signature for a message M that he has never seen before. The only requirement for message M is that the attacker has never seen this message before. (Because if the attacker has seen this message before, he can easily send this message back). The challenged party runs the verify function to determine whether the attacker's signature on message M is authentic and valid. If the verification is successful, then the attacker wins the game.

Figure 1 Unforgeable game. The hacker attacker and the challenged party play such a game together. If the hacker can sign a message that has not been seen before, then the hacker wins the game. In any case, the challenged party wins the game, which can prove that the digital signature scheme is unforgeable.

When we say that a digital signature scheme is unforgeable, we mean that no matter what algorithm a hacker uses, the probability of him successfully forging a signature is very small, so small that it can be ignored in practical applications.

  The actual problem is that in practical applications, in order to apply an algorithm to the field of digital signatures, many practical problems need to be solved. For example , many signature algorithms are random (such as those used in the Bitcoin network), so we need a very good random source. A good random source is crucial to the security of the algorithm.

  Another issue that needs to be considered in practical applications is the length of the message, because in practical signature applications, you can only sign strings of valid length. But there is an easy solution to this problem: we can sign the hash value of the message instead of signing the message itself. If we use a hash function with a 256-bit output, we can sign messages of any length. As we discussed earlier, we can sign the message by using the hash value of the message as the message digest, because the hash function is collision-proof.

Another interesting application is that you can sign a hash pointer. If you sign a hash pointer, then the signature can protect the entire data structure, not just the hash pointer itself, but the entire data structure pointed to by the hash pointer. For example, if you digitally sign the hash pointer at the beginning of the blockchain, then it is equivalent to signing the blockchain.

Elliptic Curve Digital Signature Algorithm (ECDSA): Now let's explore some of the details. The Bitcoin network uses a special digital signature scheme called the Elliptic Curve Digital Signature Algorithm. The Elliptic Curve Digital Signature Algorithm is a standard of the US government. It is an upgraded version of the earlier DSA signature algorithm and utilizes elliptic curves. These algorithms have been cryptographically analyzed and tested for security for many years and are considered to be secure and reliable.

More specifically, the Bitcoin network uses secp256k1 in the elliptic cryptographic curve to provide 128-bit security protection (that is, the difficulty of cracking this algorithm is very high, roughly similar to doing 2128 random collision tests). Although this protocol is a standard, it is rarely used outside the Bitcoin network. Other elliptic cryptographic curve signature algorithms (such as the secure transmission of values ​​in TLS in web browsers) are more likely to use the "secp256r1" curve. This is because Satoshi Nakamoto, the original developer of Bitcoin, chose such an encryption curve, and it is now difficult to change.

We will not discuss the specific working principle of ECDSA, because there are a lot of complicated mathematical principles, and it is not very relevant to the actual work. If you are interested in learning more, you can read some of our recommended reference books. However, it is still very helpful to understand a basic signing process.

Private key: 256 bits Public key, uncompressed: 512 bits Public key, compressed: 257 bits Message to be signed: 256 bits Signature: 512 bits

It should be noted that ECDSA can only sign 256-bit messages, but this is not a major problem because the message is hashed before signing, which means that messages of any length can be signed.

For the ECDSA signature algorithm , a good random source is very important, because a poor random source can cause your private key to be leaked. An intuitive understanding is that if you use a poor random source to generate a private key, then your private key may be insecure. For ECDSA , if you use a poor random source to sign a message, even if you use your very good private key, it may cause your private key to be leaked. If you leak your private key, hackers can forge your signature. Therefore, we need to be particularly careful to use a good random source to generate public and private keys, because a poor random source can have a great impact on system security.

At this point, we can clearly know that the signature published by Craig Wright is just a trick. He selected a public signature message and claimed it was his own. If he really has the private key of this address (12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S), then he should be Satoshi Nakamoto. 1 He can move the above bitcoins to prove himself 2 He can use the private key of the address to sign a message, such as signing: i am satoshi, and then let everyone verify it. If he can't do these two points, then how can we believe that he is Satoshi Nakamoto?