Qtum developers reveal a DoS attack vector for the classic PoS protocol

Editor's note: This article was written by Qtum co-founder and core developer Jordan Earlz. Jordan Earlz started learning programming at the age of 13 and has 18 years of development experience. As a Coin Reviewer, he has reviewed the designs of more than 100 virtual currencies in the community. He is also a security expert and one of the most famous developers in the North American Bitcoin community. The following opinions only represent the personal opinions of Qtum Qtum Jordan Earlz.

Recently, during the development of Qtum Quantum Chain, I found that the identifier field in SCRIPT_VERIFY_ALLOW_EMPTY_SIG is not a required option, and this vulnerability may lead to a Denial of Service (DoS) attack. Since this field is not a required field, a user can create an invalid transaction without triggering a DoS ban. Exploiting this vulnerability, an attacker can create an expensive transaction and submit it for verification, and then submit an empty push and checksigverify operation to verify an empty signature. In this way, the system returns an error message, and the transaction is also considered an invalid transaction, and the block is also an invalid block. In addition, the code structure causes expensive transactions to be evaluated and verified twice.

method:

Create a non-standard transaction without vout

[pubkey]

DUP

TOALTSTACK

OVER

TOALTSTACK

CHECKSIG -should be valid and return true

DROP –drop result

FROMALTSTACK

FROMALTSTACK

SWAP

— Repeat this process indefinitely until the upper limit of sigop is reached

[empty push]

[pubkey]

CHECKSIG

1- Push 1 onto the stack, making the transaction output spendable

Mine into a block (non-standard so you would have to do it yourself probably)

Change the source code so that CHECKSIG returns true but does not perform encoding verification, etc.

Finally, mine/stake a block which spends the previous vout (vin should be valid signature for pubkey)

Finally, the current block uses the output value of the previous block (vin should be a valid signature of the pubkey)

Due to the final empty push signature, the block will be considered an invalid block, which will trigger the code in main.cpp:1328

// Verify signature

if (!VerifySignature(txPrev, *this, i, flags, 0))

{

if (flags & STANDARD_NOT_MANDATORY_VERIFY_FLAGS) {

// Check whether the failure was caused by a

// non-mandatory script verification check, such as

// non-null dummy arguments;

// if so, don't trigger DoS protection to

// avoid splitting the network between upgraded and

// non-upgraded nodes.

if (VerifySignature(txPrev, *this, i, flags & ~STANDARD_NOT_MANDATORY_VERIFY_FLAGS, 0))

return error(“ConnectInputs() : %s non-mandatory VerifySignature failed”, GetHash().ToString());

}

I think script.cpp should return different operation results:

case OP_CHECKSIG:

case OP_CHECKSIGVERIFY:

{

// (sig pubkey — bool)

if (stack.size() < 2)

return false;

valtype& vchSig = stacktop(-2);

valtype& vchPubKey = stacktop(-1);

// Subset of script starting at the most recent codeseparator

CScript scriptCode(pbegincodehash, pend);

// Drop the signature, since there's no way for a signature to sign itself

scriptCode.FindAndDelete(CScript(vchSig));

if ((flags & SCRIPT_VERIFY_STRICTENC) && (!CheckSignatureEncoding(vchSig, flags) || !CheckPubKeyEncoding(vchPubKey)))

return false; //HERE, it fails the script in the first execution, but not in the second

bool fSuccess = CheckSignatureEncoding(vchSig, flags) && CheckPubKeyEncoding(vchPubKey) &&

CheckSig(vchSig, vchPubKey, scriptCode, txTo, nIn, nHashType, flags); Common attack vectors against consensus mechanisms:

In this section, we summarize the various attack vectors that the consensus mechanism may face. Generally speaking, common attacks on the network layer and consensus protocol layer include denial of service attacks ( DoS ) and Sybil attacks . Denial of service attacks cause nodes to be unable to process normal data by sending a large amount of data to the node (for example, sending a large number of small transaction requests so that the system cannot process normal transactions). Sybil attacks weaken the role of correct data redundancy backup by controlling most of the nodes in the network.

In the PoW consensus mechanism, miners will immediately broadcast newly discovered blocks to the entire network. In the Selfish Mining attack , misbehaving miners waste computing resources in the following ways: when they find a new valid block, they do not immediately broadcast it to the entire network, but continue mining and try to mine more blocks before other miners mine new blocks; when other miners mine valid blocks, the attacker immediately broadcasts the valid blocks they held before to the entire network. However, some researchers believe that it is not easy to implement this attack in practice.

In a short-range attack , the attacker controls a certain proportion of various resources that ensure system security (such as computing resources, cryptocurrency resources, etc.) to roll back a transaction after it is executed (such as spending tokens or executing smart contracts) (thus performing a double-spending attack, that is, spending a cryptocurrency multiple times). When the attacker launches a short-range attack, he first submits a transaction to be rolled back to the entire network, and continues mining on the fork of the previous block (the fork that does not contain the transaction to be rolled back) until the transaction receives n block confirmation information. If the number of blocks on the fork is more than n, the attacker publishes the block containing the transaction to be rolled back. In this way, since the length of the forked chain is greater than the original main chain, all network nodes will regard the forked chain as the main chain. At this point, the transaction is rolled back.

In a long-range attack , the attacker controls a certain percentage of system resources and forks the blockchain main chain on historical blocks or even the genesis block, aiming to obtain more block rewards and/or roll back transactions. This attack is more targeted at systems based on the proof-of-stake consensus mechanism. Even though the attacker may only hold a small portion of tokens when the fork occurs, he can freely trade tokens on the fork, making it easier for the attacker to mint coins and quickly form a longer blockchain.

In contrast, in a system based on the PoS consensus mechanism, an attacker can use the coin age to calculate the node equity and determine the valid blockchain by the total consumed coin age. The coin age of an unspent transaction output (UTXO) is calculated by multiplying the coin age by the number of historical blocks before the block (such as the Peercoin introduced in the following chapters). In a coin age accumulation attack , the attacker disperses the tokens he holds into different UTXOs and waits until his equity is much greater than the node average. In this way, the attacker has a great chance of continuously minting coins, thereby achieving the purpose of forking the main chain or rolling back transactions (such as implementing a double-spending attack).

In the PoS consensus mechanism, the solution to the current block depends on the hash value of the previous block. An attacker with sufficient computing power and equity can interfere with the hash value of the hth block through random trial and error during the virtual mining process of the hth block until the attacker can mine the h+1th block. This is the so-called pre-computation attack . Using this method, the attacker can continuously mint coins and obtain corresponding block rewards or launch a double-spending attack.