Received 7 April 2024, accepted 23 May 2024, date of publication 30 May 2024, date of current version 7 June 2024.

Digital Object Identifier 10.1109/ACCESS.2024.3407521

Preventing 51% Attack by Using Consecutive

Block Limits in Bitcoin
SOHAIL MAHMOOD BABUR1 , SHAFIQ UR REHMAN KHAN 2 ,
JING YANG 3 , (Graduate Student Member, IEEE), YEN-LIN CHEN 4, (Senior Member, IEEE),
CHIN SOON KU 5 , AND LIP YEE POR 3 , (Senior Member, IEEE)
1 Department of Information Technology, Government Murray College, Sialkot 51010, Pakistan
2 Department of Computer Science, Capital University of Science and Technology, Islamabad 44730, Pakistan
3 Department of Computer System and Technology, Universiti Malaya, Kuala Lumpur 50603, Malaysia
4 Department of Computer Science and Information Engineering, National Taipei University of Technology, Taipei 106344, Taiwan
5 Department of Computer Science, Universiti Tunku Abdul Rahman, Kampar 31900, Malaysia

Corresponding authors: Yen-Lin Chen ([email protected]), Jing Yang ([email protected]),

Lip Yee Por ([email protected]), Chin Soon Ku ([email protected]), and Shafiq Ur Rehman Khan ([email protected])
This work was supported in part by the National Science and Technology Council in Taiwan under Grant
NSTC-112-2221-E-027-088-MY2 and Grant NSTC-111-2622-8-027-009; in part by the Ministry of Education of Taiwan Entitled ‘‘The
Study of Artificial Intelligence and Advanced Semiconductor Manufacturing for Female STEM Talent Education and Industry-University
Value-Added Cooperation Promotion’’ under Grant 1122302319; and in part by Universiti Tunku Abdul Rahman (UTAR), Malaysia,
Financial Support for Journal Paper Publication Scheme through UTAR.

ABSTRACT In permissionless blockchain systems, Proof of Work (PoW) is utilized to address the issues of
double-spending and transaction starvation. When an attacker acquires more than 50% of the hash power of
the entire network, they gain the ability to engage in double-spending activities, posing a significant threat
to the PoW consensus algorithm. This research focuses on the consensus algorithm employed in the Bitcoin
system, explaining how it operates and the security challenges it faces. The proposed modification to the
PoW algorithm imposes a restriction on miners: they are not allowed to accept consecutive blocks from the
same miner into the final local blockchain to prevent the 51% attack problem. This modification supports
transactions that require six confirmations. In the event an attacker attempts a 51% attack with a private chain
that consists of fewer than 6 blocks, it becomes easier to detect a double-spending attack before accepting
the attacker’s private chain. The modified algorithm introduces a ‘‘Safe Mode Detection Algorithm’’
that scrutinizes incoming blocks for adjustments at the top of the local blockchain. If inconsistencies
are identified, the consensus algorithm proceeds cautiously by comparing the UTXO dictionaries from
the attacker’s chain with those from the miner’s own blockchain. This meticulous comparison aims to
detect instances of double-spending. If such instances are detected, the miner rejects the attacker’s chain,
establishing a double-spend-free environment and thwarting 51% attacks.

INDEX TERMS 51% attack, bitcoin and consensus, blockchain, double spending, proof of work (PoW).

I. INTRODUCTION all network mediums that employ cryptography. Anyone can

The first decentralized public ledger system in blockchain install a Bitcoin application and become part of the Bit-
technology is Bitcoin, which was developed by Satoshi coin peer-to-peer network. There are different versions of
Nakamoto in 2009 [1]. Bitcoin is a payment system where blockchain, but Bitcoin is based on Blockchain 1.0, designed
digital currency (bitcoin) can be sent or received on a dis- specifically for digital cryptocurrencies [2].
tributed peer-to-peer network for trading purposes. To secure The Bitcoin network must adhere to rules of ownership,
the exchange of electronic cash, cryptocurrency is used for with its key elements outlined as follows [3]:
• How can we identify an owner?
The associate editor coordinating the review of this manuscript and • Can we identify digital currency?
approving it for publication was S. K. Hafizul Islam . • How can we map the owner and digital currency?
2024 The Authors. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.
For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
77852 VOLUME 12, 2024
S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

The Bitcoin peer-to-peer network relies on principles of Wallet software generates new transactions that select
public-key cryptography, digital signatures, and blockchain unspent transaction outputs (UTXO) from the UTXO set,
technology to address these key elements. To function referred to as ‘‘Inputs,’’ and constructs new outputs based
effectively in a purely distributed peer-to-peer network envi- on the new owner. These transactions are then sent to neigh-
ronment, the Bitcoin system must perform the following boring nodes and propagate through the network. Invalid
major tasks: transactions are promptly discarded. The sum of all outputs
• How can we describe and protect ownership? must be slightly less than the sum of all validated inputs,
• How can we store transaction data? accounting for an implied transaction fee collected by the
• How can we prepare ledgers and distribute them miner responsible for adding the transaction to the open
throughout the network? ledger. Unlike currency notes, bitcoin chunks in transactions
• How can we add new transactions to the ledgers? cannot be divided and are locked by the owner. Once trans-
• Which ledgers are considered valid? actions are validated, they become part of a transaction pool.
‘‘Blockchain.info’’ is one of the popular blockchain explor- Miner nodes are specialized computer hardware systems
ers. Double spending is a major problem in digital currency connected to full Bitcoin nodes. Their primary responsibility
and can be mitigated by the Bitcoin Payment System through is to receive unconfirmed transactions propagating on the
the use of a public ledger known as the blockchain. network [6]. The transactions that go unselected by a miner
Another critical aspect of a successful network is main- for an extended period are eventually discarded [7]. Miners
taining the data integrity of the system. Blockchain achieves maintain a local copy of the blockchain and are responsible
this goal through the use of the cryptographic hash function for validating transactions, placing them into a block, and
SHA-256 [4]. The blockchain system serves as the lifeblood adding them to a globally distributed ledger. The process of
of the cryptocurrency world, presenting a linked list of blocks adding a new block to the global distributed ledger aver-
containing transactions. Bitcoin transactions are efficiently ages around 10 minutes. Miners can receive two types of
stored in a hash-based Merkle tree. All operations are per- incentives:
formed efficiently on the Merkle tree [5]. Within each block, • Creating new coins as a reward.
the first transaction is coin-based, serving as the reward for • Earning transaction fees.
the winning miner. It’s important to note that coin-based To obtain these incentives, miners employ a consensus
transactions have no inputs. The leaf nodes of the Merkle tree mechanism before adding transactions to the blockchain.
represent transactions that are recursively hashed until the A consensus mechanism is a technique employed to achieve
Merkle root is obtained. Figure 1 illustrates how the Merkle the following goals within the Bitcoin network:
tree is incorporated into the blockchain. • Agreement
• Trust
• Security
TABLE 1. Acronyms used in this paper. The most prevalent consensus mechanisms in the cryptocur-
rency world include Proof of Work (PoW), Proof of Stake
(PoS), and Delegated Proof of Stake (DPoS) [8].
The first challenge is to identify the nodes, how they assert
ownership of their digital money, and how they can trans-
fer this ownership to another node. Asymmetric public-key
cryptography is employed to accomplish this, generating a
pair of keys (public and private). The public key serves for
node identification and is publicly disclosed, while the private
key is utilized for ownership, specifically to produce a digital
signature [6].
Another vital aspect of a successful network is the preser-
vation of data integrity. Blockchain systems achieve this
objective by utilizing cryptographic hash functions such as
SHA-256. These cryptographic hash functions possess essen-
tial properties, including:
• Rapid generation of hash codes and hash values for any
type of data.
• Consistent production of the same hash code for identi-
cal input data.
• Generation of unpredictable results for minor alterations
in input data.
• Prevention of the production or prediction of input data
FIGURE 1. Blockchain with merkle tree. from the output hash code.

VOLUME 12, 2024 77853

 S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

An attacker with more than 50% of the hash power can

initiate a new parallel chain of blocks alongside the legitimate
chain, effectively isolating the genuine chain and enabling
double-spending. This type of attack is a significant concern
within the Bitcoin network [12]. Notably, in May 2018, Bit-
coin Gold experienced a substantial loss of 18 million dollars
due to such an attack [13].
This attack gives rise to two major problems:
FIGURE 2. Hashing puzzle. • Transaction starvation: This occurs when certain trans-
actions, not selected by the miner holding 51% of the
hash power, are left unprocessed for extended periods.
• Collision resistance ensures that it is difficult to find two One solution to this problem is the adoption of Proof of
different data structures with the same hash code. Stake (PoS) instead of PoW.
• Double-spending: In this scenario, a single digital cur-
Another use of hashing is to create hash puzzles that neces-
rency can be utilized multiple times. A miner possessing
sitate computational resources for resolution. It is impossible
51% or more of the network’s hashing power can
to solve these puzzles based on knowledge or stored data. The
pre-create a chain but refrain from broadcasting it imme-
sole method to tackle these puzzles is through the consump-
diately. Later, the miner decides to release this extended
tion of computational power and effort.
chain in accordance with blockchain policies. If other
In the context of blockchain technology, this computational
miners accept this longer chain, the attacker gains an
work is known as Proof of Work (PoW) and includes elements
advantage [8].
of a hash puzzle, comprising [3]: As the Bitcoin network grows in size and complexity, the
• The given data (which remains unchanged during the threat of a 51% attack has diminished to some extent, making
process). it less of a concern these days [14]. However, it cannot be
• The numeric value that can be freely altered is known as entirely disregarded because the Bitcoin network has indeed
a nonce. fallen victim to such attacks. Therefore, it is imperative that
• The application of a hash function, such as SHA-256 (as we explore ways to enhance our consensus algorithm. The
depicted in Figure 2). 51% attack is fundamentally a double-spending attack [2].
The global difficulty adjusts approximately every two weeks, This study aims to accomplish the following objectives:
or after 2016 blocks, to ensure that the process of adding • To investigate the effectiveness of the PoW consensus
blocks to the blockchain maintains an average duration of algorithm in preventing 51% attacks on the Bitcoin net-
10 minutes [9]. Miners can increase their hashing power work.
either by employing more powerful hardware or by partici- • To examine potential modifications to the PoW consen-
pating in mining pools. sus algorithm.
Mining pools represent a strategy for boosting hashing • To foster a trustworthy environment for society to use the
power where miners collaborate on solving a single hash Bitcoin network, free from the threat of 51% attacks.
puzzle to mine a block. This collaborative effort is referred • To visualize the entire attack process using a simulator
to as a mining pool. If a pool member discovers the solution, and present the results in the form of graphs to enhance
the resulting reward is distributed among all pool members comprehension of the attack.
based on the pool’s policy. It’s worth noting that mining pools An open-source simulator named BlockSim, which emu-
may levy a fee on each member [10]. Figure 3 displays some lates the Bitcoin network, will be employed for this research.
popular mining pools for the year 2021 [11]. It provides a platform to create miners with varying hash-
ing powers functioning within distributed systems. While
all miners initially possess equal hashing power, only the
attacker will gradually increase their hashing power at regular
intervals during the simulation. Different scenarios involving
this simulation will be explored.
The remainder of this paper is structured as follows:
Section II delves into related work; Section III outlines the
proposed methodology; and Section IV presents a detailed
analysis of the experiments. Finally, Section V concludes this
research study and offers insights into future directions.

II. RELATED WORK

This section provides a review of the literature concerning
FIGURE 3. Mining pools in 2021. Bitcoin, the 51% attack, and the theoretical framework of

77854 VOLUME 12, 2024

S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

The ‘‘tragedy of the commons,’’ as discussed by authors

in a paper [16], arises when the block reward becomes zero,
leaving only transaction fees as profits for miners. In such
a scenario, many miners might abandon mining, potentially
leading to a 51% attack due to network consolidation.
Increasing hashing power can only be achieved by enlarg-
ing the pool size, thereby making a 51% attack a possibility
with no effective solution [17]. Quantum devices pose
another challenge by enhancing computational power using
the Proof of Work (PoW) consensus algorithm within the
Bitcoin network [18]. A successful 51% attack by a quantum
device would enable the attacker to halt and confirm new
transactions [19]. Quantum algorithms offer better time and
memory complexity, leading to the possibility of a quantum
51% attack [20].

2) DELEGATED PROOF OF STAKE (DPOS)

FIGURE 4. Proof of work (PoW). In the DPoS algorithm, network users vote to elect dele-
gates, often referred to as witnesses or block producers. Once
this study. When an attacker (miner) acquires more than elected, delegates are granted the authority to validate the
50% of the network’s computational power, they can create blocks added to the blockchain. DPoS randomly selects a set
a new chain. The attacker with the longest chain can then number of delegates (typically 20 to 100) from the network
isolate the genuine chain. The 51% attack stands as a sig- before each new block is incorporated into the blockchain.
nificant contributor to the double spending problem. While Transaction fees from the new block are distributed among
some solutions, such as Delayed Proof of Work (DPoW), all delegates, while rewards are shared among users who have
Historical Weighted Difficulty, and Two Phase Proof of Work staked their tokens in the successful delegate’s pool. Greater
(2P-PoW) in Bitcoin, as well as concepts like PirlGuard and stakes result in a larger share [21].
ChainLocks, manage to address the issue to some extent, the
threat remains. These solutions tend to introduce delays in 3) A NEW PROOF OF WORK (POW) MECHANISM FOR
network processes and also reduce transaction speed. BITCOIN
The theoretical framework of this article introduces and Miners are presented with problems to solve, but if they
elucidates the theory that provides an explanation for the focus on problems with multiple solutions, their efforts can
existence of the research problem. It should be noted that be justified by finding multiple solutions rather than just one.
PoW, PoS, and DPoS do not entirely eliminate the threat of a This approach assigns value to the work of all miners and can
51% attack [8]. be appreciated [22].

A. THEORETICAL FRAMEWORK 4) TWO PHASE PROOF OF WORK (2P-POW) IN BITCOIN

1) PROOF OF WORK (POW) The existence of large public mining pools significantly
PoW involves solving a mathematical problem using a cryp- reduces the reward for individual miners. These pools often
tographic hash algorithm. A nonce is calculated to ensure that require pool operators to hand over private keys or a signifi-
the resulting hash value is less than the target value. The target cant portion of their pools. The 2P-PoW algorithm employs
value is adjusted to modulate the difficulty of the puzzle, continuous-time Markov chains (CTMCs), with the second
making it easier or harder. The winning node adds the block to difficulty (Y) acting as the inverse of the normal difficulty
the final blockchain and broadcasts it on the network. If mul- (X). Pool operators are compelled to cooperate by solving the
tiple nodes discover the solution simultaneously, temporary second difficulty (Y) in order to access the normal difficulty.
forks may occur. However, the protocol eventually ensures Funds from coin-based addresses can only be transferred
that the longest chain (with the maximum PoWs) is selected if they successfully address the second difficulty (Y) [9].
as the final blockchain, while others are excluded to maintain Figure 5 displays the transition graph of 2P-PoW. Extended
consistency [6]. Figure 4 illustrates the flowchart of PoW. 2P-PoW also indicates that this change doesn’t fully mitigate
However, PoW, which forms the backbone of the Bitcoin 51% attacks [23].
network, has some drawbacks [15]:
• It consumes significant extra electricity resources, esti- 5) HISTORY WEIGHTED DIFFICULTY
mated at 24 terawatt-hours per year. Figure 6 illustrates two branches: an honest branch and
• In smaller networks, an attacker may gain 51% of the an attacker’s branch. Incorporating the histories of both
hash power. branches assists in identifying the attacker. In this technique,

VOLUME 12, 2024 77855

 S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 5. Two phase proof of work (2P-PoW).

FIGURE 7. PoW based on block compression (PoW-PC).

FIGURE 8. Hypothesis model.

FIGURE 6. Historical weighted difficulty.

mining pool. To address the challenge of consecutive blocks

history-weighted difficulty is introduced into the difficulty
by the same miner, a proposed PoW protocol restricts the
calculation. While it helps in mitigating 51% attacks to some
acceptance of six consecutive blocks from the same miner
extent, the threat is not entirely eliminated from the net-
in the blockchain. However, if pool members cooperate to
work [24].
create blocks one by one with different miner IDs, they could
still generate six consecutive blocks with different miner IDs,
6) REVISITING DOUBLE SPENDING ATTACKS ON BITCOIN
potentially enabling a 51% attack.
This study introduces a new type of double spending attack This research is premised on the assumption that complete
(DSA) called adaptive DSA within the context of the Bitcoin information about pools is available, including details about
blockchain. It also presents insights related to this attack. pool members and pool creators. According to this premise,
In the analytical model, the double spending attack is trans- individual miners or pool creators are only allowed to create
formed into a Markov decision process. Stochastic dynamic a new block, ensuring that ‘‘only those miners who mine
programming (SDP) is then utilized to derive optimal attack as individuals or act as pool creators can participate in the
strategies for adaptive DSA. Through this model and the consensus.’’
insights into adaptive DSA, the study aims to highlight that Pool members have the flexibility to leave or join other
the threat of double-spending attacks remains significant pools. A heuristic algorithm facilitates the extraction of pay-
within the Bitcoin ecosystem [25]. out flows from mining pools, enabling anyone to gather
information about miners operating as pool members in spe-
7) POW BASED ON BLOCK COMPRESSION (POW-BC) cific pools [27]. Additionally, techniques involving block
PoW-BC aims to reduce block size, improve transmission INV messages can be employed to identify mining nodes in
efficiency, and reduce disk space requirements for storing the Bitcoin network [28]. Another algorithm, Heuristic 1, can
blocks. The block compression ratio is used to adjust mining be utilized to pinpoint mining nodes [29].
difficulty, reduce block intervals, and minimize energy con-
sumption. This reduction in the chances of a 50% attack is III. PROPOSED METHODOLOGY
attributed to variations in the block compression ratio result- This section presents the proposed methodology for
ing from different transaction selections and their orders [26]. addressing the 51% attack on the Bitcoin network. When
Figure 7 illustrates how PoW-BC functions. a node possesses more than 51% computational power,
it becomes capable of introducing deceptive information
B. OPERATIONS AND SERVICES into the blockchain. Therefore, implementing restrictions in
In the present day, most nodes do not engage in mining as Bitcoin is crucial to prevent nodes from frequently adding
individual entities. Instead, nearly every miner is part of a fraudulent blocks to the blockchain.

77856 VOLUME 12, 2024

S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

In the Bitcoin network, transactions are confirmed as

blocks are added to the blockchain. For significant trans-
actions, it is recommended to have six confirmations for
security reasons. Waiting for these confirmations can help
mitigate 51% of attacks [30]. While having more computa-
tional power in the network can be beneficial when miners
are honest, there’s a risk that miners in a pool may misuse this
power for malicious purposes, such as conducting a double-
spending attack.
There are two distinct scenarios in which attackers can
mount an attack:
• Scenario-1: The attacker aims to create a private chain
whose length is greater than or equal to 6, known as the
long private chain (LPC), to execute double spending on
transactions requiring at least 6 confirmations.
• Scenario-2: The attacker aims to create a private chain
whose length is less than 6, known as the short private
chain (SPC), to execute double-spending on transactions
FIGURE 9. Methodology model for long private chain (LPC).
requiring fewer confirmations.
Scenario-1 Solution:
In Scenario-1, the attacker tries to broadcast its private
chain in such a way that the length of the private chain is
greater than or equal to six (6), as well as the length of the
private chain being greater than the length of the bypass chain.
The proposed algorithm, ‘‘Safe Mode Detection,’’ is
designed to handle Scenario-1 effectively. A restriction is
imposed that miners can have at most five consecutive blocks
by the same miner in their local honest blockchain. This
modification in the consensus algorithm ensures the safety
of major transactions. Figure 9 illustrates how the attacker
initiates a private chain after the kth block runs parallel to
the honest chain. The attacker attempts double spending in
the (k+1)th block of the private chain and the bypass chain.
Consequently, this private chain cannot be accepted by the
network due to the presence of six consecutive blocks by the
same miner.
When an attacker broadcasts a block and other nodes
receive it, two cases may occur: FIGURE 10. Methodology model for short private chain (SPC).
Case 1: The receiving block attempts to attach to the local
blockchain. The receiving node first assesses the number of
consecutive blocks by the same miner at the end of the local
blockchain. If the count of consecutive blocks is less than than six (6) and the length of the private chain is greater than
five, the incoming block is safe to be appended to the local the length of the bypass chain.
blockchain; otherwise, it is ignored. The proposed algorithm, ‘‘Safe Mode Detection,’’ also
Case 2: The receiving block requests an update of the local handles Scenario-2 effectively. It requires an assessment of
blockchain. two parts of the chain:
If the receiving block cannot be attached to the top of the • The receiving part of the attacker’s blockchain.
local blockchain and its depth exceeds that of the last block • The bypass is part of the local, honest blockchain.
in the local blockchain, the receiving node asks the miner to Figure 10 illustrates that an attacker’s private chain length is
update its local blockchain. The miner keeps track of changes. less than six (6), so by creating dictionaries A and B, con-
The miner reverts the changes if six consecutive blocks by taining input UTXOs from the receiving part of the attacker’s
the same miner are detected in its local blockchain; otherwise, blockchain and the bypass part of the local honest blockchain,
the changes are accepted. respectively, one can find common keys (input UTXOs) with
Scenario-2 Solution: different values (transaction IDs, tx.id). The presence of such
In Scenario-2, the attacker tries to broadcast its private entries indicates double spending; otherwise, the system will
chain in such a way that the length of the private chain is less be in safe mode (see Algorithm 1).

VOLUME 12, 2024 77857

 S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

Algorithm 1 The proposed modified consensus algorithm. • Node.py: Defines the basic properties of a node in the
1: A = {} Bitcoin network, such as node ID, local blockchain, and
2: for blk in Receiving_part: transaction pool.
3: for tx in blk.transactions: • Transaction.py: Maintains transaction properties,
4: for in_utxo in tx.in_utxo: including the transaction hash, timestamp, sender,
5: A.update ({in_utxo: tx.id}) recipient, amount, size, and fee.
6: B = {} • Event.py: Manages event properties generated by
7: for blk in Bypass_part: nodes, with two event types: create_block and
8: for tx in blk.transactions: receive_block. It also maintains event queues.
9: for in_utxo in tx.in_utxo: • Scheduler.py: Creates events and manages them,
10 B.update ({in_utxo: tx.id}) including maintaining event queues.
11 intersect = [k for k in A if k in B and A[k] != B[k]] • Consensus.py: Contains protocol and fork_resolution
12 if intersect == [ ]: functions for generating global chains.
13 SafeMode = True • Incentives.py: Calculates and distributes rewards
14 else: among participating nodes.
15 SafeMode = False • Statistics.py: Computes and prints simulation results.
• BlockCommit.py: Handles events during the
simulation.
Taking into account the average number of transactions in
one block and the typical number of input UTXOs [31] in B. EXPERIMENTAL SETUP
a Bitcoin transaction, it becomes feasible to compare dic- 1) SIMULATION LOGIC BEHIND THE SCENE
tionaries A and B to detect double spending. If there are In this simulator, there are 100 nodes in this Bitcoin network
approximately 2000 transactions in one block of the Bitcoin that are working as miners. These miners are designated as
network [31], then there are 10,000 transactions in 5 blocks, M0, M1, M2,. . . , M100. In these miners, M2 is designated as
which will be compared with the bypass chain. It is also a special miner that is increasing hash power gradually such
noted that an average of 2.12 input UTXOs are used in one that the whole hash power of the network is 100%. Each miner
transaction on the Bitcoin network, and most transactions maintains a local blockchain whose first block is called the
use only one input UTXO [32]. So dictionaries A or B may genesis block.
contain a maximum of 20,000 key values of input UTXOs • It increases the hashing power of M2 gradually.
that can easily be compared. • It creates an event by calling a method.
In the BlockSim simulator environment, the Bitcoin net- Scheduler.createblockevent(node, blockTime).
work conducts transactions at regular intervals. Miners select The currentTime is the time when a node starts mining, and
these transactions for validation and group them into a block. the blockTime is the time when the node finds the solution to
After solving the Proof of Work (PoW) algorithm by finding the puzzle in the proof-of-work (PoW) consensus algorithm.
a nonce, the block is added to the blockchain, and the process This newly created event is then added to the queue. It is clear
continues with the next block. The fork resolution process that there will initially be 100 events added to the queue.
helps determine which miner has mined the most blocks in The simulation starts here, as presented in Figure 11. It is
the chain. The analysis also reveals how the Bitcoin network time to handle these events with less time than the simula-
can avoid a miner’s attempt to execute a 51% attack. tion time. A variable simTime holds the simulation time for
12 hours, i.e., 12∗ 60∗ 60 = 43200 seconds. A while loop han-
IV. EXPERIMENTAL SETUP AND RESULTS dles all the events until the queue becomes empty. This queue
The ‘‘Experimental Setup and Results’’ section describes is not a simple queue. It is a priority queue in which events are
the methodology used in the BlockSim simulator to ana- removed with the lowest blockTime. A variable next_event
lyze miner behavior in a dynamic environment. The section holds the time of the event (recently removed from the
explains the simulation of a Bitcoin network with miners, queue) generated. The method BlockCommit.handle_event
including how the simulator handles 51% attacks and how (nextevent) is called in the loop to handle this event.
modifying the consensus algorithm can prevent such attacks. There are two types of events in the queue, as shown in
Figure 12:
A. BLOCKSIM SIMULATOR • create_block event:
BlockSim is an open-source simulator written in Python A method BlockCommit.generate_block(event) is
designed for analyzing and experimenting with blockchain- called to create a block. In this method, the block is first
based systems like Bitcoin. It provides a flexible environment validated and added to its local blockchain. After that,
for studying various blockchain networks and consensus it is propagated to all other nodes in the Bitcoin network.
algorithms. Key files in BlockSim include: • receive_block event:
• InputsConfig.py: Initializes global variables for the A method BlockCommit.receive_block(event) is called
simulation process. to receive a block. In this method, the arriving block is

77858 VOLUME 12, 2024

S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 11. Simulation start-up.

FIGURE 13. The while loop handling events.

and there are no more than six consecutive blocks from

the same miner.
FIGURE 12. Priority queue.
• Case 3: When receiving a block that is not adjusted to the
top of the local blockchain, a request is sent to the block
first validated and adjusted to its local blockchain. This
miner to update its local blockchain. The system remains
adjustment is done using two cases.
in safe mode if there are no more than six consecutive
◦ Case 1: The receiving block is adjusted at the top of
blocks from the same miner.
the local blockchain.
◦ Case 2: A method update_local_blockchain (node, To handle the SPC situation in case 3, this method employs
miner, depth) is called for proper adjustment. two dictionaries, A and B. Dictionary A is created to store the
Figure 13 illustrates that a while loop manages all the events receiving part of the attacker’s private chain blockchain with
in the queue. Suppose the attacker decides to attack based on dictionary items in the format of in_utxo:tx_id. Dictionary B
certain fundamental criteria. A specific method, BlockCom- is used to store the Bypass part of the attacker’s honest local
mit.check_for_broadcast_private_chain(event), is invoked chain with dictionary items in the same format as A. The
when the attacker creates or receives a block. This method intersection of these dictionaries is then calculated as follows:
evaluates two conditions prior to broadcasting the private intersect = [k for k in A if k in B and A[k] != B[k]]
chain. If the network approves the entire private chain, then If there exists an in_utxo in both the private chain and the
51% attacks can take place; conversely, if the network does bypass chain but with different transaction IDs, it signifies
not accept the private chain as a whole, the attacker’s attempt double spending. The system remains in safe mode if the
to execute a 51% attack fails. intersection is empty. Figure 14 provides a pseudo-code rep-
resentation of the safe mode detection process.
2) SYSTEM SAFE MODE DETECTION After processing all the events in the queue, a global
The method Consensus.is_node_in_safe_mode(node, block, blockchain is generated using the method Consensus.fork_
case) is designed to prevent other nodes from accepting the resolution The attacker does not participate in creating the
potentially risky private chain of the attacker, which can have global chain because its local blockchain is inconsistent. The
a length equal to or greater than 6 blocks (referred to as distribution of rewards among the nodes is computed by
LPC) or a length less than 6 blocks (referred to as SPC). This invoking the method Incentives.distribute_rewards Simula-
method determines whether the system is in a safe mode or tion results, including block statistics and miner rewards, are
not and is invoked in three different cases to handle the LPC calculated by calling the method Statistics.calculate
situation initially:
• Case 1: Upon the creation of a new block, the system C. ALL CASES WITHOUT MODIFIED CONSENSUS
enters a safe mode if the newly created block is added ALGORITHM
to the local blockchain and there are no more than six In this Bitcoin network environment created by the Block-
consecutive blocks from the same miner. Sim simulator, there are 100 miners (M1. . . M100), each
• Case 2: When receiving a block adjusted to the top of possessing 1% of the total hashing power of the network,
the local blockchain, the system is in safe mode if the i.e., all miners have the same hash power. The simulation
receiving block is added to the top of its local blockchain time has been set to 12 hours. During this simulation, miner

VOLUME 12, 2024 77859

 S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 14. Safe mode detection.

FIGURE 16. Case 1 – no attacker.

FIGURE 15. Case 1 – Number of blocks mined and average mining time.

M2 gradually increases its hashing power at regular, equal

intervals of 2 hours over the entire duration. Concurrently,
the remaining miners adjust their hashing power randomly
to ensure that the combined hashing power of all miners
remains at 100%. The objective is to observe how the miners
mine blocks and how the network ultimately accepts the final
global chain.

1) CASE 1: NO ATTACKER
Figure 15 presents two graphs, one depicting miner IDs and
the number of mined blocks, while the other illustrates block
depth and mining time in minutes. In contrast, Figure 16 FIGURE 17. Case 1 – global chain.
displays a graph illustrating the relationship between the top
5 miner IDs, the number of blocks they have mined, simula-
tion time, and corresponding timestamps. Figure 17 provides 2) CASE 2: M2 IS ATTACKER
a detailed representation of the global chain that was accepted In Case 2, where all miners have the same hash power, with
in Case 1. M2 acting as the attacker, an illegal activity is initiated as

77860 VOLUME 12, 2024

S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 18. Case 2, Situation-1 – number of blocks mined and average

mining time. FIGURE 19. Case 2, Situation-1 – fails to broadcast private chain.

M2 attempts a 51% attack. The attacker begins to construct a

private chain, and when its length reaches or exceeds 6 blocks,
surpassing the length of the honest chain, it broadcasts the
last block of the private chain. The attacker’s start time is
set to two hours, denoted as ATTACK_START_TIME =
2∗ 60∗ 60 seconds. Following this, the attacker proceeds to
create a private chain and broadcast it.
There are three situations that may occur:
• Situation-1: Failure to Broadcast a Private Chain
• Situation-2: Failure to Execute a 51% Attack
• Situation-3: Successful 51% Attack
Situation-1: Failure to Broadcast a Private Chain:
Figure 18 illustrates that the attacker fails to meet the basic
criteria for broadcasting the private chain due to simulation
time constraints. Figure 19 provides a graph depicting the
Top 5 Miner IDs, the number of blocks they have mined, sim-
ulation time, and corresponding timestamps. Additionally,
Figure 20 presents details regarding the global chain accepted
in Case 2, Situation-1.
Situation-2: Failure to Execute a 51% Attack: FIGURE 20. Case 2, Situation-1 – global chain.
The simulation suggests that this scenario may occur under
rare conditions. If the attacker constructs a private chain and that in real-time scenarios, this situation is unlikely to occur.
satisfies the basic criteria just before concluding the simu- Thus, it can be concluded that if an attacker successfully
lation and broadcasting it, it’s possible that the final global broadcasts the private chain, the network would typically
chain won’t accept the private chain because the simulation accept it, resulting in a 51% attack.
time limit is exceeded. In Case 2, Situation-2, if a 51% Situation-3: Successful 51% Attack:
attack fails to occur, the figure will display TF. The first Figure 21 illustrates the graph for Case 2, Situation-3.
T indicates that the attacker broadcasted the private chain, In the event that the attacker constructs a private chain and
while the second F indicates that the final global chain did not meets the basic criteria for broadcasting it, it’s possible for
accept the entire private chain. However, it’s important to note the final global chain to accept the private chain. Consider the

VOLUME 12, 2024 77861

 S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 21. Case 2, Situation-3 – no of blocks mined and average mining

time.

FIGURE 23. Case 2, Situation-3 – global chain.

1) CASE 1: NO ATTACKER
Figure 24 presents two graphs illustrating the Miner IDs and
the number of blocks they have mined, as well as block depth
FIGURE 22. Case 2, Situation-3 – 51% attack. and mining time in minutes. Additionally, Figure 25 displays
a graph representing the Top 5 Miner IDs, the quantity of
TT in Figure 22, where the first T indicates that the attacker blocks they have mined, simulation time, and corresponding
broadcasted the private chain, and the second T signifies timestamps. Furthermore, Figure 26 provides an in-depth
that the final global chain accepted the entire private chain. analysis of the global chain’s acceptance in Case 1.
Figure 22 displays the graph featuring the Top 5 Miner IDs,
the number of blocks they have mined, simulation time, and 2) CASE 2: M2 IS ATTACKER
corresponding timestamps. Furthermore, Figure 23 provides In this scenario, once more, Miner M2 assumes the role of
details about the global chain accepted in Case 2, Situation-3. the attacker attempting a 51% attack. However, this time, the
modified algorithm monitors the system’s state to ensure it
D. ALL CASES WITH MODIFIED CONSENSUS ALGORITHM remains in a secure and consistent condition. Two distinct
In the preceding section, all scenarios were examined without situations may now arise.
the implementation of a modified algorithm. In this section, • Situation-1: Failure to Broadcast a Private Chain
we will utilize an adjusted version of the consensus algorithm • Situation-2: Inability to Execute a 51% Attack
and reevaluate all the cases. Situation-1: Failure to Broadcast a Private Chain:

77862 VOLUME 12, 2024

S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 24. Modified algorithm case 1 no of blocks mined and average

mining time.
FIGURE 26. Modified Algorithm Case 1 – no attacker.

FIGURE 27. Modified Algorithm Case 2, Situation-1 – number of blocks

mined and average mining time.
FIGURE 25. Modified Algorithm Case 1 – no attacker.

Figure 27 illustrates that if the attacker fails to meet the Additionally, Figure 29 presents details regarding the global
basic criteria for broadcasting the private chain and the simu- chain accepted in Case 2, Situation-1.
lation time exceeds the threshold, then the attacker is unable Situation-2: Inability to Execute a 51% Attack:
to broadcast the private chain. Meanwhile, Figure 28 displays The modified algorithm guarantees that once a block is
the graph depicting the Top 5 Miner IDs, the number of created or received into the local blockchain, the system
blocks mined, and the simulation time along with timestamps. remains in a safe mode.

VOLUME 12, 2024 77863

 S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 28. Modified Algorithm Case 2, Situation-1 – fails to broadcast FIGURE 30. Modified Algorithm Case 2 – Situation-2 – no of blocks
private chain. mined & avg mining time.

FIGURE 29. Modified Algorithm Case 2, Situation-1 – global chain.

If the system attempts to deviate from this safe mode,

it simply disregards the block and refrains from adding
it to the local blockchain. The modified algorithm consis-
tently ignores the private chain when the attacker attempts
to broadcast it. Figure 30 illustrates the graph for Case 2, FIGURE 31. Modified Algorithm Case 2 – Situation-2 – fails to make 51%
Situation-2, where a 51% attack fails to materialize. Addi- attack.

tionally, Figure 31 presents the graph that showcases the

Top 5 Miner IDs, the number of blocks mined, the simulation E. SHORT PRIVATE CHAIN (SPC) DOUBLE SPENDING
time, and the associated timestamps. Additionally, Figure 32 CASE (WITHOUT MODIFIED CONSENSUS ALGORITHM)
presents details regarding the global chain accepted in Case 2, In the preceding section, it was established that the system
Situation-2. would not accept a longest private chain (LPC) with a length

77864 VOLUME 12, 2024

S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 33. Without modified algorithm (SPC) – number of blocks mined

and average mining time.

FIGURE 32. Modified Algorithm Case 2 – Situation-2 – global chain.

greater than or equal to six blocks from the same miner. How-
ever, the attacker retains the option to broadcast a short private
chain (SPC), which may consist of fewer than 6 blocks,
typically around 4 or 5 blocks, all from the same miner. This
scenario opens the possibility of engaging in double-spending
activities.
Figure 33 visually presents two graphs: one detailing miner
IDs and the number of mined blocks, and the other depict-
ing block depth and mining time in minutes. Concurrently,
Figure 34 displays a graph illustrating the Top 5 Miner IDs,
the number of blocks mined, and their correlation with simu- FIGURE 34. Without modified algorithm (SPC) – 51% attack.

lation time and timestamps.

Figure 35 further illustrates instances of double spend- recipient IDs. The intricate details regarding the global
ing added to both the private chain and bypass chain. For chain’s acceptance in the context of a short private chain
example, the figure showcases the initial transaction within (SPC), double spending, and potential 51% attacks are out-
the first block of the private chain, featuring input UTXO lined in Figure 36.
3978543203 and transaction ID 83869265366. Notably,
this same input UTXO is observed within the first block F. SHORT PRIVATE CHAIN (SPC) DOUBLE SPENDING CASE
transactions of the bypass chain, albeit bearing a distinct (WITH MODIFIED CONSENSUS ALGORITHM)
transaction ID of 729729714. This specific double-spending The shortest private chain (SPC), comprising fewer than or
scenario involves the transfer of 0.72 bitcoins to different up to six blocks—typically around 4 or 5 blocks—from the

VOLUME 12, 2024 77865

 S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

FIGURE 37. With modified algorithm (SPC) – number of blocks mined and
average mining time.

FIGURE 35. Without modified algorithm (SPC) – double spending added.

FIGURE 38. With modified algorithm (SPC) – no 51% attack.

occurrence of a 51% attack is prevented. Figure 37 visually

presents two graphs: one detailing miner IDs and the number
of mined blocks, and the other depicting block depth and min-
ing time in minutes. In addition, Figure 38 provides a graph
FIGURE 36. Without modified algorithm (SPC) – global chain with double
illustrating the Top 5 Miner IDs, the number of blocks mined,
spending. and their correlation with simulation time and timestamps.
Figure 39 offers a detailed view of double spending
within both the private chain and bypass chain. Specif-
same miner, can be accepted by the system. In such cases, ically, the figure highlights the initial transaction within
the potential for double-spending activities exists. However, the first block of the private chain, featuring input UTXO
when implementing the proposed modified algorithm, the 86424129216 and transaction ID 81373710733. Notably, this

77866 VOLUME 12, 2024

S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

V. DISCUSSION
The discussion, articulated by crypto expert Jameson Lopp
(Crypto Expert), meticulously delineates the risk landscape
inherent in Bitcoin transactions contingent upon confirma-
tion levels. Lopp underscores the hazards of zero-confirm
(0-conf) transactions, illuminating vulnerabilities to race
attacks, Finney attacks, and 51% attacks. Through a prag-
matic lens, he proposes a graduated framework for confirma-
tion thresholds based on transaction values: 1 confirmation
for modest transactions under $1,000, 3 confirmations for
mid-range payments spanning $1,000 to $10,000, 6 con-
firmations for larger transactions ranging from $10,000 to
$1,000,000, and finally, a recommended 10 confirmations for
substantial payments surpassing $1,000,000. Lopp’s exper-
tise shapes a nuanced understanding of transaction security,
encapsulating both theoretical vulnerabilities and practical
FIGURE 39. With modified algorithm (SPC) – double spending added.
strategies for risk mitigation within the Bitcoin ecosys-
tem. (https://blog.lopp.net/how-many-bitcoin-confirmations-
is-enough/)
The proposed methodology for mitigating 51% attacks on
the Bitcoin network stands out in comparison to existing
literature due to its innovative approach and comprehen-
sive solution. Former approaches, as outlined in works such
as [33], focus on analyzing the rational behavior of the
miner and exploring game-theoretic models to understand
the miner’s strategic decisions. However, in comparison, this
paper introduces a consensus algorithm and a safe mode
detection mechanism, which are more practical and can be
implemented in existing block chain technologies. In [34],
the random mining group selection approach focuses on mit-
igating the risks associated with concentrated mining power
by advocating for a more decentralized distribution of miners
across mining pools. In contrast, the proposed methodology
emphasizes algorithmic modifications and detection mech-
anisms within the existing Bitcoin network framework to
detect and prevent 51% attacks in real-time. Finally, [8]
provides a comprehensive assessment of various consen-
sus mechanisms, including Proof of Work (PoW), Proof of
Stake (PoS), and Delegated Proof of Stake (DPoS), among
others. It evaluates these mechanisms based on their sus-
ceptibility to 51% attacks and other security vulnerabilities.
Conversely, the proposed methodology in the present study
focuses specifically on the Bitcoin network and introduces
algorithmic modifications to the existing PoW consensus
FIGURE 40. Without modified algorithm (SPC) – global chain with no mechanism to prevent 51% attacks. The proposed algorithm,
double spending. ‘‘Safe Mode Detection,’’ operates independently of hash
power constraints. In scenarios where a mining pool pos-
sesses over 51% of the hash power, the algorithm rejects
same input UTXO is observed within the first block transac- any attempt to accept a private chain with a length equal to
tions of the bypass chain, albeit bearing a distinct transaction or greater than six blocks. Conversely, private chains with
ID of 42263748996. In this particular double-spending sce- lengths less than six blocks undergo a comparison process
nario, 1.33 bitcoins are directed to different recipient IDs. with the honest blockchain (referred to as the Bypass chain).
Lastly, Figure 40 outlines the intricate details regarding the Despite the potential time complexity overhead incurred by
global chain’s acceptance in the context of a short private this comparison due to shorter chain lengths, the algorithm
chain (SPC), where no instances of double spending are effectively identifies instances of double spending within the
observed and the potential for a 51% attack is mitigated. private chain. Detected instances result in the rejection of the

VOLUME 12, 2024 77867

 S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

private chain, while absence leads to acceptance. The advan- [6] A. M. Antonopoulos and D. A. Harding, Mastering Bitcoin, 3rd ed.
tage of this restriction is paramount; it incentivizes other Sebastopol, CA, USA: O’Reilly Media, Inc., 2023.
[7] M. Saad, J. Spaulding, L. Njilla, C. Kamhoua, S. Shetty, D. Nyang, and
mining pools and miners to persist in their efforts to mine A. Mohaisen, ‘‘Exploring the attack surface of blockchain: A systematic
new blocks concurrently, thus maintaining a decentralized overview,’’ 2019, arXiv:1904.03487.
and competitive mining environment. [8] S. Sayeed and H. Marco-Gisbert, ‘‘Assessing blockchain consensus and
security mechanisms against the 51% attack,’’ Appl. Sci., vol. 9, no. 9,
p. 1788, Apr. 2019.
VI. CONCLUSION AND FUTURE WORK [9] M. Bastiaan, ‘‘Preventing the 51%-attack: A stochastic analysis of two
In conclusion, our research represents a pivotal step in forti- phase proof of work in Bitcoin,’’ in Proc. 22nd student Conf., Jan. 2015,
fying the security and integrity of blockchain networks, with pp. 1–10.
[10] N. Tovanich, N. Soulié, and P. Isenberg, ‘‘Visual analytics of Bitcoin
a specific focus on mitigating the looming threat of 51% mining pool evolution: On the road toward stability?’’ in Proc. 11th IFIP
attacks within the Bitcoin ecosystem. We have proposed and Int. Conf. New Technol., Mobility Secur. (NTMS), Apr. 2021, pp. 1–5, doi:
rigorously tested a modified consensus algorithm that stands 10.1109/NTMS49979.2021.9432675.
[11] (2024). Distribution of Bitcoin’s Network Hashrate in the Last 24 Hours
as a robust bulwark against such malicious endeavors.
Until January 12, 2024. Accessed: Oct. 09, 2021. [Online]. Available:
The significance of our contributions lies in the estab- https://www.statista.com/statistics/731416/market-share-of-mining-pools/
lishment of a defense mechanism that consistently thwarts [12] C. Ye, G. Li, H. Cai, Y. Gu, and A. Fukuda, ‘‘Analysis of security
attackers’ attempts to manipulate the network, thereby safe- in blockchain: Case study in 51%-attack detecting,’’ in Proc. 5th Int.
Conf. Dependable Syst. Their Appl. (DSA), Sep. 2018, pp. 15–24, doi:
guarding major transactions and providing greater peace of 10.1109/DSA.2018.00015.
mind to users [35], [36], [37]. By introducing stringent checks [13] N. Anita. and M. Vijayalakshmi., ‘‘Blockchain security attack: A brief
for double spending prior to accepting broadcasts of small survey,’’ in Proc. 10th Int. Conf. Comput., Commun. Netw. Technol. (ICC-
CNT), Jul. 2019, pp. 1–6, doi: 10.1109/ICCCNT45670.2019.8944615.
private chains, we have raised the level of security for cryp- [14] J. B. Higuera, J. R. B. Higuer, J. A. S. Montalvo, and R. G. Crespo,
tocurrency transactions to new heights. Introduction to Cryptography in Blockchain. Cham, Switzerland: Springer,
Furthermore, as part of our future work, we envision the 2022, pp. 1–34.
development of even more dynamic and adaptive security [15] M. R. Amin, ‘‘51% attacks on blockchain: A solution architecture for
blockchain to secure IoT with proof of work,’’ Bachelor Thesis, Dept.
mechanisms that can respond to emerging threats in real-time. Comput. Sci. Eng., Int. Univ. Bus. Agricult. Technol., Dhaka, Bangladesh,
This proactive approach will ensure that blockchain networks 2020.
remain resilient in the face of evolving challenges. [16] S. M. H. Bamakan, A. Motavali, and A. Babaei Bondarti, ‘‘A sur-
vey of blockchain consensus algorithms performance evaluation cri-
This research not only enhances the resilience of indi- teria,’’ Expert Syst. Appl., vol. 154, Sep. 2020, Art. no. 113385, doi:
vidual miners but also anticipates the evolving landscape of 10.1016/j.eswa.2020.113385.
blockchain mining, where collaborative efforts in pools are [17] F. A. Aponte-Novoa, A. L. S. Orozco, R. Villanueva-Polanco, and
P. Wightman, ‘‘The 51% attack on blockchains: A mining behav-
becoming increasingly prevalent. Our work lays the foun- ior study,’’ IEEE Access, vol. 9, pp. 140549–140564, 2021, doi:
dation for future exploration and adaptation, as it paves the 10.1109/ACCESS.2021.3119291.
way for further efficiency assessments and implementations [18] D. A. Bard, J. J. Kearney, and C. A. Perez-Delgado, ‘‘Quantum advan-
within the expanding realm of blockchain technology. tage on proof of work,’’ Array, vol. 15, Sep. 2022, Art. no. 100225, doi:
10.1016/j.array.2022.100225.
Ultimately, our findings underscore the imperative of [19] K. Jahnavi and G. Swain, ‘‘The blockchain technology and attacks on it,’’
proactive measures to fortify the very foundations of decen- Turkish J. Comput. Math. Educ., vol. 12, no. 13, pp. 571–581, Jun. 2021.
tralized systems, ensuring their robustness and trustworthi- [20] J. J. Kearney and C. A. Perez-Delgado, ‘‘Vulnerability of blockchain tech-
nologies to quantum attacks,’’ Array, vol. 10, Jul. 2021, Art. no. 100065,
ness in the face of potential threats. Through innovative doi: 10.1016/j.array.2021.100065.
research and steadfast dedication, we continue to drive [21] S. M. S. Saad and R. Z. R. M. Radzi, ‘‘Comparative review of the
advancements that bolster the security of blockchain net- blockchain consensus algorithm between proof of stake (POS) and del-
works, making them more resilient and reliable than ever egated proof of stake (DPOS),’’ Int. J. Innov. Comput., vol. 10, no. 2,
pp. 27–32, Nov. 2020.
before. By pursuing the avenues of dynamic security adjust- [22] N. Shi, ‘‘A new proof-of-work mechanism for Bitcoin,’’ Financial Innov.,
ments, quantum-resistant algorithms, and cross-blockchain vol. 2, no. 1, p. 31, Dec. 2016, doi: 10.1186/s40854-016-0045-6.
security, we aim to keep blockchain technology at the fore- [23] K. Chaudhary, V. Chand, and A. Fehnker, ‘‘Double-spending analysis
front of secure and decentralized solutions for the future. of Bitcoin,’’ in Proc. 24th Pacific Asia Conf. Inf. Syst., Inf. Syst., 2020,
pp. 1–15.
[24] X. Yang, Y. Chen, and X. Chen, ‘‘Effective scheme against 51% attack
REFERENCES on proof-of-work blockchain with history weighted information,’’ in Proc.
[1] M. Ahmed and A. K. Pathan, ‘‘Blockchain: Can it be trusted?’’ Computer, IEEE Int. Conf. Blockchain (Blockchain), Jul. 2019, pp. 261–265, doi:
vol. 53, no. 4, pp. 31–35, Apr. 2020, doi: 10.1109/MC.2019.2922950. 10.1109/BLOCKCHAIN.2019.00041.
[2] R. S. Raju, S. Gurung, and P. Rai, ‘‘An overview of 51% attack over Bitcoin [25] J. Zheng, H. Huang, C. Li, Z. Zheng, and S. Guo, ‘‘Revisiting double-
network,’’ in Contemporary Issues in Communication, Cloud and Big Data spending attacks on the Bitcoin blockchain: New findings,’’ in Proc.
Analytics, vol. 281. Cham, Switzerland: Springer, 2022, pp. 39–55, doi: IEEE/ACM 29th Int. Symp. Qual. Service (IWQOS), Jun. 2021, pp. 1–6,
10.1007/978-981-16-4244-9_4. doi: 10.1109/IWQOS52092.2021.9521306.
[3] N. Kube, Daniel Drescher: Blockchain Basics: A Non-Technical Introduc- [26] B. Yu, X. Li, and H. Zhao, ‘‘PoW-BC: A PoW consensus protocol based on
tion in 25 Steps. New York, NY, USA: Apress, 2017. block compression,’’ KSII Trans. Internet Inf. Syst., vol. 15, no. 4, pp. 1–15,
[4] A. Bahalul Haque and M. Rahman, ‘‘Blockchain technology: Methodol- Apr. 2021.
ogy, application and security issues,’’ 2020, arXiv:2012.13366. [27] N. Tovanich, N. Soulié, N. Heulot, and P. Isenberg, ‘‘An empirical analysis
[5] M. Bosamia and D. Patel, ‘‘Current trends and future implementation of pool hopping behavior in the Bitcoin blockchain,’’ in Proc. IEEE
possibilities of the Merkel tree,’’ Int. J. Comput. Sci. Eng., vol. 6, no. 8, Int. Conf. Blockchain Cryptocurrency (ICBC), May 2021, pp. 1–9, doi:
pp. 294–301, Aug. 2018, doi: 10.26438/ijcse/v6i8.294301. 10.1109/ICBC51069.2021.9461118.

77868 VOLUME 12, 2024

S. M. Babur et al.: Preventing 51% Attack by Using Consecutive Block Limits in Bitcoin

[28] M. Apostolaki, A. Zohar, and L. Vanbever, ‘‘Hijacking Bitcoin: Routing JING YANG (Graduate Student Member, IEEE)
attacks on cryptocurrencies,’’ in Proc. IEEE Symp. Secur. Privacy (SP), received the Bachelor of Engineering degree
May 2017, pp. 375–392, doi: 10.1109/SP.2017.29. majoring in navigation technology from Shandong
[29] M. Saad, A. Anwar, S. Ravi, and D. Mohaisen. (2021). Hash- Jiaotong University in 2022, and the master’s
Split: Exploiting Bitcoin Asynchrony to Violate Common Prefix and degree (Hons.) in data science from Universiti
Chain Quality. Accessed: Jan. 27, 2024. [Online]. Available: https:// Malaya, Malaysia, in 2024, where he is currently
eprint.iacr.org/2021/299 pursuing the Ph.D. degree. His primary research
[30] M. Rosenfeld, ‘‘Analysis of hashrate-based double spending,’’ 2014, interests lie in the fields of medical image process-
arXiv:1402.2009.
ing, deep learning, the IoT, and blockchain.
[31] Bitcoin Average Transactions Per Block. Accessed: Feb. 28, 2010.
[Online]. Available: https://ycharts.com/indicators/bitcoin_average_
transactions_per_block
[32] Average Input UTXOs in One Transaction Bitcoin—Google Search.
Accessed: Feb. 28, 2010. [Online]. Available: https://www.google.com/
search?channel=fs&client=ubuntu&q=average+input+UTXOs+in+one+
transaction+bitcoin YEN-LIN CHEN (Senior Member, IEEE) received
[33] C. Badertscher, Y. Lu, and V. Zikas, ‘‘A rational protocol treatment of 51% the B.S. and Ph.D. degrees in electrical and control
attacks,’’ in Proc. 41st Annu. Int. Cryptol. Conf., 2021, pp. 3–32. engineering from National Chiao Tung University,
[34] J. Bae and H. Lim, ‘‘Random mining group selection to prevent 51% Hsinchu, Taiwan, in 2000 and 2006, respectively.
attacks on Bitcoin,’’ in Proc. 48th Annu. IEEE/IFIP Int. Conf. Dependable From February 2007 to July 2009, he was an Assis-
Syst. Netw. Workshops, Jun. 2018, pp. 81–82. tant Professor with the Department of Computer
[35] M. Monem, M. T. Hossain, M. G. R. Alam, M. S. Munir, Science and Information Engineering, Asia Uni-
M. M. Rahman, S. A. AlQahtani, S. Almutlaq, and M. M. Hassan,
versity, Taichung, Taiwan. From August 2009 to
‘‘A sustainable Bitcoin blockchain network through introducing dynamic
January 2012, he was an Assistant Professor with
block size adjustment using predictive analytics,’’ Future Gener. Comput.
Syst., vol. 153, pp. 12–26, Jun. 2024. the Department of Computer Science and Informa-
[36] C. W. Purnadi and S. Yazid, ‘‘Sidechain implementation strategies to tion Engineering, National Taipei University of Technology, Taipei, Taiwan,
improve blockchain scalability,’’ in Proc. AIP Conf., 2024, pp. 1–19. where he was an Associate Professor, from February 2012 to July 2015,
[37] D. Aronoff and I. Ardis, ‘‘ADESS: A proof-of-work protocol to deter and since August 2015, he has been a Full Professor with the National
double-spend attacks,’’ in Proc. Future Inf. Commun. Conf., 2024, Taipei University of Technology. His research interests include artificial
pp. 131–157. intelligence, intelligent image analytics, embedded systems, pattern recogni-
tion, intelligent vehicles, and intelligent transportation systems. His research
results have been published on over 100 journals and conference papers. He is
a fellow of IET and a member of ACM, IAPR, and IEICE.

CHIN SOON KU received the Ph.D. degree from

Universiti Malaya, Malaysia, in 2019. He is cur-
SOHAIL MAHMOOD BABUR received the M.S. rently an Assistant Professor with the Department
degree in computer science from the University of Computer Science, Universiti Tunku Abdul
of Sialkot, Pakistan. He is currently an Assis- Rahman, Malaysia. His research interests include
tant Professor and the Head of the Department, AI techniques (such as genetic algorithm), com-
Government Murray College, Sialkot, Pakistan. puter vision, decision support tools, graphical
His research interests include blockchain tech- authentication (authentication, picture-based pass-
nologies, the Internet of Things (IoT), machine word, and graphical password), machine learning,
learning, and computer vision. deep learning, speech processing, natural language
processing, and unmanned logistics fleets.

LIP YEE POR (Senior Member, IEEE) received

the B.Sc., M.Sc., and Ph.D. degrees from Uni-
versiti Malaya, Malaysia. He currently holds the
position of an Associate Professor with the Faculty
SHAFIQ UR REHMAN KHAN received the Ph.D. of Computer Science and Information Technol-
degree from the Capital University of Science ogy, Universiti Malaya. His research interests
and Technology, Pakistan. He is currently an include various aspects of information security
Assistant Professor with the Capital University of and quality assurance (NEC 2020: 0611), includ-
Science and Technology. He is also a collabora- ing authentication, graphic passwords, PIN-entry,
tor between industry and academia. His research cryptography, data hiding, steganography, and
interests include natural language processing, watermarking. Additionally, he specializes in machine learning (NEC 2020:
machine learning, explainable AI, and blockchain 0613), with expertise in extreme learning machines, support vector machines,
technologies. deep learning, long-short-term memory, computer vision, and AIoT.

VOLUME 12, 2024 77869