Bitcoin Bifurcation Main Cause: Extending Attacks Caused by ECDSA Algorithm Vulnerabilities

A loophole in the elliptic curve signature algorithm is that it does not invalidate the original transaction immediately after changing the transaction signature.

If you've been "stuck" for years in the encryption industry, you've certainly heard about "transaction malleability" and know that it's not a good thing. But what exactly is "transactional scalability" and why is it not good?

Let's take a look at the PascalCoin Foundation founder and CEO, PascalCoin core developer, and RandomHash inventor Herman Schoenfeld to explain the problem.

• Iran mining, a thrilling "money game"
• White hat hackers are quietly emerging: repairing 20 cryptocurrency vulnerabilities in a month and winning $23,675
• People's Daily issued a message: Blockchain allows data "who owns, who benefits"

In cryptocurrencies such as Bitcoin, "transaction" is actually an atomic operation that transfers value between users. After the user creates the transaction, they will post it on the network. These transactions will be broadcast on the network and finally connected to the blockchain after confirmation by the “miner mining”. The person receiving the transaction will also use the blockchain to judge the transaction. Has it been confirmed?

But the problem is that there are more and more Bitcoin transactions today, and millions of transactions are flying around every minute in the blockchain. How do users quickly identify and differentiate these transactions? Not only that, but for those users across the globe, how can they quickly and accurately identify transactions in the same way without using the slow global registry system? The answer is actually very simple, you can use the transaction cryptographic hash as an identifier.

Transaction cryptographic hashing is a method of creating small digital "fingerprints" from arbitrary files. Like fingerprints, transaction cryptographic hashing is a type of identification that guarantees the uniqueness of a document with shorter information. Every byte in (or file) is relevant and it is difficult to find the inverse law. Therefore, when the original transaction (or file) changes, its flag value will also change, thus telling the file user that the current file is not the file you need.

Transaction cryptographic hashing allows the use of the data itself to obtain a "fingerprint" of any data (sounds a bit around), this "fingerprint" is unique and does not change every time it is calculated. However, if there is even a "1 bit" change in the transaction data, the transaction hash will change completely, which in turn will ensure the uniqueness of the transaction.

In Bitcoin, the transaction hash is called "TXID" and is used as the unique universal identifier for the transaction.

Well, when it comes to this, you may have a question. Since every bitcoin transaction is uniquely identified, how can there be a so-called "extensibility" problem?

First, let's take a look at what is the "extensibility" problem with bitcoin transactions.

Bitcoin transaction scalability refers to the change of the unique transaction identifier (TXID) of a bitcoin transaction, but does not invalidate the original transaction. In fact, depending on the cryptocurrency, there are many ways to do this. The most common one is "signature malleability," which is what this article focuses on:

The Bitcoin protocol uses the Elliptic Curve Signature Algorithm (ECDSA), which became the ANSI standard in 1999 and became the IEEE and NIST standards in 2000. Unlike the ordinary discrete logarithm problem (DLP) and the integer factorization problem (IFP), the elliptic curve discrete logarithm problem (ECDLP) has no sub-exponential time solution, so the ellipse The unit bit strength of the curve cipher is higher than other public key systems, and the calculation parameters are smaller, the key is shorter, the operation speed is faster, and the signature is shorter.

However, there is a loophole in the elliptic curve signature algorithm that does not immediately invalidate the original transaction after changing the transaction signature. Although the algorithm can ensure that the signature cannot be forged, it allows the attacker to change the transaction TXID containing the associated signature, which can have very serious consequences.

Bitcoin extended attack

To better explain the bitcoin malleable attack, we introduce two fictitious traders "Bob" and "Alice".

Suppose Bob is prepared to pay Alice some bitcoin through a transaction with the identifier "X". Before the bitcoin is mined, the identifier is controlled by the hacker and changed to a new identifier "Y". In the future, when Alice receives the bitcoin payment, Bob will not know that the payment transaction he has issued has been completed. If Alice is a "bad guy" and she knows that Bob doesn't know that her bitcoin has been accepted by her, then Alice can send Bob a remittance transaction again, asking Bob to pay again, and can repeat Do this many times until Bob finally realizes the problem, but it may be too late.

In fact, this kind of extended attack has already occurred on some cryptocurrency exchanges, as shown in the following figure:

In this case, the attacker can perform the attack by the following steps:

1. Start a batch of Sybil nodes (red nodes in the above figure);

2. Use these nodes to surround the exchange node (the red node in the figure above);

3. Initiating a cash withdrawal transaction from the exchange;

4. Assuming that the cash withdrawal transaction identifier is "X", once the transaction leaves the exchange, the Sybil node will change the transaction identifier to "Y";

5. The cash withdrawal transaction with the transaction identifier "Y" will be broadcast to the rest of the Bitcoin network;

(The planet is o-daily Note: The Sybil node refers to fake account nodes that are maliciously manipulated for coordinated attacks, that is, using a small number of nodes in the network to control multiple false identities, thereby using these identities to control or affect a large number of normal nodes of the network.)

When the cash withdrawal transaction with transaction identifier "Y" is dug to the next block, the attacker has received the cash withdrawal amount, but at this time the exchange has not received the cash withdrawal confirmation. Information, so the exchange has been waiting for a transaction confirmation with a transaction identifier of "X". At this point, the attacker will continue to implement the attack:

6. The attacker will ask the exchange to re-initiate the cash withdrawal transaction because they will falsely claim that the cash withdrawal transaction was "not passed" on the network;

7. Continue to repeat the above attack methods.

Note: In the second step above, the attacker does not need to completely surround the exchange node, they only need a few connections to perform the attack – although the success rate of the attack may be lower. In general, the more Sybil nodes that surround an exchange node, the higher the probability of an attack success.

In addition, the attacker will take two different attack strategies depending on the size of the exchange:

1. The first type of attack is the so-called "parasite strategy". They usually choose some irregular small transactions to carry out the attack, so that they can escape the tracking of some transaction monitoring tools and maximize them. Implement long-term attacks under the conditions of own income;

2. The second type of attack is the so-called "vampire strategy", which extracts the funds of the exchange through high-frequency large-value withdrawal transactions before the system administrator finds the problem.

Regardless of which strategy an attacker implements, it will suffer losses to the exchange, so the encryption industry needs to solve this extended attack problem through some plasticity scheme.

Is it the main cause of the splitting of the Bitcoin community to solve the problem of extended attacks with isolated witnesses?

By introducing a segregated witness (Segwit), Bitcoin hopes to address this type of extended attack.

The quarantine witness can separate the signature transaction from the TXID calculation and replace the TXID with a cryptographic hash that is not extendable for this signed transaction. This cryptographic hash is used as a pointer to the signed transaction only, and the signed transaction is stored in another data structure.

To verify the transaction signature, the Bitcoin verifier uses this cryptographic hash to look up the corresponding signature in another data structure (ie, the data structure in which the signature transaction is stored) and then perform an Elliptic Curve Signature Algorithm (ECDSA) verification. In this way, a ductile attack will not be able to obtain the signature source because the data is not stored in the same place as the transaction, in which case the attacker cannot tamper with the hash pointer to the signature. Of course, since signature data is stored in other data structures, quarantine witnesses increase reliance on other data structures. Bitcoin needs to be weighed in this regard. After all, this is very important.

While the segregation testimony itself was not a bad idea, the implementation of the segregation testimony still caused a rift in the Bitcoin community and led to the division of the community into Bitcoin (BTC) and Bitcoin Cash (BCH). It should be noted, however, that the main problem that led to the division of the community is more about how the segregated testimony is deployed, not the technology itself.

Regardless of whether you like the quarantine testimony, Bitcoin cash has been forked out of the Bitcoin blockchain. From a technical point of view, the issue of ductile attacks still exists in Bitcoin cash.

This article is from Medium, the original author is PascalCoin Foundation founder and CEO, PascalCoin core developer, RandomHash (random hash) inventor Herman Schoenfeld.

Odaily Planet Daily Translator | Moni

This article was translated from https://medium.com/@herman_10687/malleability-attack-why-it-matters-7b5f59fb99a4.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!