
Blockchain denial of service (BDoS) and selfish mining are the two most crucial attacks on blockchain technology. A classical DoS attack targets the computer network to limit, restrict, or stop accessing the system of authorized users which is ineffective against renowned cryptocurrencies like Bitcoin, Ethereum, etc. Unlike the conventional DoS, the BDoS affects the system’s mechanism design to manipulate the incentive structure to discourage honest miners to participate in the mining process. In contrast, in a selfish mining attack, the adversary miner keeps its discovered block private to fork the chain intentionally that aiming to increase the incentive of the adversary miner. This paper proposed a technique to successfully avoid BDoS and selfish mining attacks. The existing infrastructure of blockchain technology doesn’t need to be changed a lot to incorporate the proposed solution.
Keywords—Blockchain, DoS, BDoS, Selfish mining, PoW
I. INTRODUCTION
Bitcoin is a peer-to-peer electronic cash system introduced by Satoshi Nakamoto in 2008 [1]. It has grown into a popular cryptocurrency and its current market capitalization is more than $400B [2]. The data structure behind Bitcoin technology is blockchain. As Bitcoin is a public blockchain, anyone can join to the system anytime. Participants in the blockchain are called nodes and nodes who collect cryptocurrency transactions between clients are known as miners. Miners have to solve a complex mathematical cryptopuzzle to create a block to the blockchain successfully [3]. Every node in the network adds the new transactions i.e. block to get updated. A miner needs to spend its resources to solve a complicated mathematical cryptopuzzle and generate Proofs of Work (PoW) [4]. This work is known as mining which is very difficult but easily verifiable. A miner who successfully mines a block gets rewarded with cryptocurrency for his effort.
Bitcoin necessitates a majority of the miners to be truthful. This virtual currency can be controlled by a pool of miners if the pool holds the majority of the mining power called 51% attack that goes against the concept of decentralization. For example, such a pool can forbid a selected transaction or more transactions. It is very common that the Bitcoin miners form pools and behave strategically. For a specific pool, all miners use their mining power to solve the cryptopuzzle and if any miner finds it s/he informs the pool manager and all other miners stop mining that block. If the pool successfully creates a block, the rewards are distributed among the miners of the pool proportionally to their contributions. It decreases the variance of their income rate.
Calculating the block header’s hash value is the first step in the Proof of Work (PoW) consensus mechanism. The block header $b_i$ contains a $r_i$ that is continually changed by the node participating in the mining process called miner to obtain…
II. PRELIMINARIES
A. Blockchain
A Blockchain $B$ is a distributed, decentralized, and tamper-proof storage mechanism consisting of a number of $n$ blocks $b_0, b_1, …, b_n$. Each block $b_i$ can contain $m$ transactions $t_{r_0}, t_{r_1}, …, t_{r_m}$ (may vary), a hash of the previous block $h_{i-1}$, a timestamp $TS$, a nonce $r_i$, etc. The hash of the previous block is calculated by $h_{i-1} = hash(h_{i-2})$ and $r_i$ denotes a random number to ensure the validity of the block. The block is formally defined as $b_i = ((t_{r_0}, t_{r_1}, …, t_{r_m}), h_{i-1}, TS, r_i)$. Blockchain $B$ is thought to be valid if each block $b_i$ is valid where the validity of the $b_i$ depends on the validity of each transaction $t_{r_i}$ in that block and the hash of the $b_i$ is to comply with a certain threshold $th$ [5]. A new block $b_{new}$ gets added to the blockchain $B$ only when the majority of nodes ($\geq \frac{2}{3}$) in the blockchain have agreed to it by validating all transactions $t_{r_i}$. The mechanism by which the nodes agreed to add the $b_{new}$ is known as the consensus mechanism. PoW is the most renowned consensus mechanism in this domain is discussed in the following step. As new blocks are added to the blockchain, its size continues to grow. A simple $B$ is illustrated in the following Fig. 1. Each $b_i$ in the blockchain has two parts: a block header $b_{ih}$ and a block body $b_{ib}$. Secure Hashing Algorithm (SHA)-256 is a prominent algorithm for hashing used in this domain.
Fig. 1. Blockchain structure.
different hash values of the $b_{nk}$. As the mechanism needs to be found a hash value ($h_i = SHA256(b_{i})$) to remain within a certain threshold $th$, miners have to solve a complex mathematical crypto puzzle. A miner $m_k$ who solves the crypto puzzle first will add the $b_{new}$ to the $B$. While $m$ append the newly created block $b_{new}$ to the $B$, it broadcasts the $b_{new}$ to the blockchain network. The other nodes of the blockchain network validate all the $tr$ of the $b_{new}$ and update the block to its blockchain [4].
III. DESCRIPTIONS OF ATTACKS
This section demonstrates BDoS and selfish mining attacks in detail.
A. BDoS
A Denial of Service (DoS) attack targets the computer network to limit, restrict, or stop accessing the system of authorized users. There have been no successful DoS attacks to date against prominent cryptocurrencies like Bitcoin, Ethereum, etc. Unlike the classical Denial of Service (DoS), Blockchain Denial of Service (BDoS) targets to manipulate the revenue structure to discourage authentic miners to participate in the process of mining.
Let $B^$ be the current state of the main chain illustrated in Fig. 2(a). An attacker $\tilde{A}$ creates a block $b_i$ and appends it to the $B^$ and the resultant chain is $B_1$ which is shown in Fig. 2(b). Rather than publishing the entire block $b_i$, the $\tilde{A}$ publishes only the block header $b_{ih}$ and withholds the block body $b_{ib}$ that contains mainly the list of transactions $(t_{r0}, t_{r1}, …, t_{rn})$. The reason behind publishing only the block header $b_{ih}$ is to give proof that the $\tilde{A}$ successfully creates the block. At this point, a rational miner $m_i$ can ignore the $b_{ih}$ of the $\tilde{A}$ and create a block $b_i$ following the main chain $B^*$ and creates the resultant chain $B_i$.
Let $\tilde{A}$ creates a block $b_i$ in State0 with its’ mining power, $\alpha$, and appends it and reaches at State1. Rather than publishing the entire block $b_i$, the $\tilde{A}$ publishes only the block header $b_{ih}$. In Fig. 3(a), it is observed that $m_i$ and $m_{rat}$ are still mining in the State1 with mining power $\alpha_{m_i}$ and $\alpha_{m_{rat}}$, respectively. Although they know that the probability of rewarding from this state is low. This is true for all the $m_{rat}$. If the $m$ stops mining in the State1 which is depicted in Fig. 3(b), then it will be beneficial for the $\tilde{A}$. Here, $\beta$ $(\leq 1)$ represents the rushing ability of the block of $\tilde{A}$, i.e. $\beta_{m_{rat}}$.
As there are two different chains e.g. $B_i$ and $B_n$, this situation is known as a fork that is shown in Fig. 2(c). When the $m_i$ publishes the $b_i$ to the blockchain network, the $\tilde{A}$ also immediately publishes the contents of the $b_i$, resulting in a race between $B_i$ and $B_n$ that is depicted in Fig. 2(d). Depending on the parameters of the system, the block $b_i$ of $m_i$ may or may not get added to the $B^*$. Hence, the probability of getting rewards for the successful block creation of the rational miners $m_{rat}$ lessens. Pausing mining turns out to be a better alternative than mining if the incentive is low enough. If the incentive reduces significantly all the miners stop mining and the resultant situation is that the $\tilde{A}$ can also stop mining after taking the incentive of creating block. The blockchain thus grinds to a complete halt. This attack necessitates significantly lower than 50% power of mining.
B. Markov Chain Representation of BDoS
The BDoS problem can be represented in a markov chain model depicted in the Fig. 3. Here, 0, 1, and 2 specify the state number.
State0: specifies initial state of the blockchain (Fig. 2(a)).
State1: denotes the attack on progress and $\tilde{A}$ successfully creates a block and publishes only the $b_{ih}$ to the blockchain network (Fig. 2(b)).
State2: states that the $m_{rat}$ creates a block $b_i$ in State0 with its’ mining power, $\alpha$, and appends it and reaches at State1. Rather than publishing the entire block $b_i$, the $\tilde{A}$ publishes only the block header $b_{ih}$. In Fig. 3(a), it is observed that $m_i$ and $m_{rat}$ are still mining in the State1 with mining power $\alpha_{m_i}$ and $\alpha_{m_{rat}}$, respectively. Although they know that the probability of rewarding from this state is low. This is true for all the $m_{rat}$. If the $m$ stops mining in the State1 which is depicted in Fig. 3(b), then it will be beneficial for the $\tilde{A}$. Here, $\beta$ $(\leq 1)$ represents the rushing ability of the block of $\tilde{A}$, i.e. $\beta_{m_{rat}}$.
miners with ( \beta \cdot \alpha_m ) mining power mining on the top of the block of ( \mathcal{A}i ). In contrast, the rest ((1 – \beta) \cdot \alpha{\text{rat}} ) miners with ((1 – \beta)(1 – \alpha_m) ) mining power mining on the top of the block of ( \mathcal{M}_{\text{rat}} ). The reward is given to the winner of the race. This can be shown using the equation (1).
[ R = \begin{cases} \beta \cdot \alpha_m, & \text{if } \beta \cdot \alpha_m > (1 – \beta)(1 – \alpha_m) \ \alpha_{\text{rat}}, & \text{if } (1 – \beta)(1 – \alpha_m) > \beta \cdot \alpha_m \end{cases} ]
(1)
In case of Fig. 3(b), the ( m ) stops mining in State 1 and it is logical as the block is already created by ( \mathcal{A}_i ). The reward is given to the winner of the race shown in the following equation (2).
[ R = \begin{cases} \beta \cdot \alpha_{\text{auth}}, & \text{if } \beta \cdot \alpha_{\text{auth}} > (1 – \beta)(1 – \alpha_{\text{auth}}) \ \alpha_{\text{rat}}, & \text{if } (1 – \beta)(1 – \alpha_{\text{auth}}) > \beta \cdot \alpha_{\text{auth}} \end{cases} ]
(2)
C. Selfish Mining
Selfish mining is a situation when a pool of selfish miners ( m_{\text{self}} ) keeps its discovered blocks ( b_{\text{self}} ) private to fork the chain intentionally. To do it, the selfish mining pool ( \text{Pool}{\text{self}} ) publishes only selective mined block to invalidate the block ( b{\text{auth}} ) of the authentic miners ( m_{\text{auth}} ). The ( \text{Pool}{\text{self}} ) retains ( b{\text{self}} ) private, secretly forking the blockchain that creates a private branch ( b_{\text{pri}} ). For the time being, the ( m_{\text{auth}} ) continue mining on the smaller public branch ( b_{\text{pub}} ). As the ( m_{\text{self}} ) hold a comparatively small fraction of the total mining power, the ( b_{\text{pri}} ) will not lead of the ( b_{\text{pub}} ) indefinitely. Thus, the ( m_{\text{self}} ) selectively divuges blocks ( b_{\text{self}} ) from the ( b_{\text{pri}} ) to the public, such that the ( m_{\text{auth}} ) will switch to the recently published blocks, leaving the shorter ( b_{\text{pub}} ). This makes the block creation labor spent on the shorter ( b_{\text{pub}} ) wasted, and enables the selfish pool ( \text{Pool}_{\text{self}} ) to collect the greater revenues.
The selfish mining is shown in the following Fig 4. The current state of the main chain is illustrated in Fig 4(a). The strategy is determined by the ( \text{Pool}{\text{self}} ) or by the other ( m{\text{pub}} ). The results depend on the relative lengths the ( b_{\text{pub}} ) and the ( b_{\text{pri}} ).
They are as follows:
(a) When the ( b_{\text{pub}} ) is longer than the ( b_{\text{pri}} ), then the ( \text{Pool}{\text{self}} ) is behind the ( b{\text{pub}} ). As the ( m_{\text{self}} ) holds less mining power compared to the ( m_{\text{auth}} ), the chances of the ( m_{\text{self}} ) mining on the ( b_{\text{pri}} ) and lead the main branch are low. Therefore, the ( \text{Pool}{\text{self}} ) must update with the main branch each time its ( b{\text{pri}} ) falls behind which is depicted in Fig. 4(c). There may arise two possible outcomes:
i. Firstly, the ( m_{\text{auth}} ) discover a ( b_{\text{auth}} ) on the ( b_{\text{pri}} ) that cancel out the ( \text{Pool}{\text{self}} )’s lead. In this case, while the ( m{\text{auth}} ) publishes the ( b_{\text{auth}} ) to the network, the ( \text{Pool}{\text{self}} ) immediately publishes its ( b{\text{pri}} ) containing ( b_{\text{self}} ), resulting in a race between ( b_{\text{pub}} ) and ( b_{\text{pri}} ) which is illustrated in Fig. 4(d) similar to BDoS (Fig. 2(d)). At this point, if the ( m_{\text{self}} ) manage to create a ( b_{\text{self}} ), it immediately publishes the ( b_{\text{self}} ) to win the reward of two blocks which is shown in Fig. 4(e). If the ( m_{\text{auth}} ) creates a ( b_{\text{auth}} ) over the mined block of ( \text{Pool}{\text{self}} ), then the pool wins the reward of its block and the ( m{\text{auth}} ) get the profits of its block that is depicted in Fig. 4(f).
ii. The ( \text{Pool}{\text{self}} ) mines another ( b{\text{self}} ) and extends its lead two block on the ( b_{\text{pub}} ) illustrated in Fig. 4(g). At this stage, if the ( m_{\text{auth}} ) creates a ( b_{\text{auth}} ), the pool publishes one block from its ( b_{\text{pri}} ). This process will be continued if the pool has two block or more lead. As
Fig. 4. Selfish Mining.
the mining power of ( m_{\text{self}} ) is relatively small compared to other, eventually it turns out to a single block lead. At this point, the pool publishes the ( b_{\text{pri}} ). As the ( b_{\text{pri}} ) is longer than ( b_{\text{pub}} ), all miner adopts it as a main branch. Hence, the pool enjoys all blocks’ reward.
D. Markov Chain Representation of Selfish Mining
The selfish mining problem can be exemplified in a markov chain model depicted in the Fig. 5. Here, 0, 1, 2 and 3 specify the state number of selfish mining.
State0: specifies initial state of the blockchain (Fig. 4(a)).
State1: states that Pool({self}) successfully creates a block (b{self}) and keeps it secret (Fig. 4(c)). In this case, pool is on lead.
State2: denotes that the (m_{auth}) creates a block (b_{auth}) and cancel out the Pool({self})’s lead. Now the Pool({self}) immediately publishes (b_{self}), resulting in a race (Fig. 4(d)).
State3: states that the Pool(_{self}) leads on two block (Fig. 4(g)).
Let Pool({self}) is in State0 and creates a blocks (b{self}) and now it is in State1. It keeps (b_{self}) confidential to fork the chain intentionally. If (m_{auth}) discover a (b_{auth}) that cancel out the Pool({self})’s lead resulting in a race in State2 as Pool({self}) immediately publishes (b_{self}) (Fig. 4(d)). The reward is given to the winner of the race. This can be shown using the equation (3).
[ R = \begin{cases} \text{Pool}\text{self}, & \text{if } a{\text{self}} > a_{\text{auth}} \ \text{m}{\text{auth}}, & \text{if } a{\text{auth}} > a_{\text{self}} \end{cases} ]
In this circumstance, if the Pool({self}) manage to create a (b{self}), it immediately publishes the (b_{self}) to win the reward of two blocks in State3 (Fig. 4(e)). Otherwise, in State2 if the (m_{auth}) discover a (b_{auth}) over the block of Pool({self}), then both the Pool({self}) and (m_{auth}) win the reward of their respective block (Fig. 4(f)). As it is a stable situation, the blockchain is in its initial stable state, State0. In contrast, if the Pool({self}) mines another (b{self}) and extends its lead of two block then discovering (b_{auth}) by (m_{auth}) will not work because if the (m_{auth}) creates a (b_{auth}), the pool publishes one block from (b_{pub}). This process will be continued if the Pool({self}) has two block or more lead presented in State3. As the mining power of (m{auth}) is relatively small, eventually the blockchain turns out to the initial stable state.
IV. THE PROPOSED SOLUTION
This section briefly describes the proposed system to avoid BDoS attack and to prevent selfish mining problem.
A. Overview of the proposed solution
The proposed solution mainly works based on adding a dummy block (b_{dummy}) at the end of the main chain at interval of block creation time (r) plus overhead (\bar{e}). Here, (r) denotes the block generation time for the miners in a blockchain network and (\bar{e}) denotes some extra time for block propagation, etc. For example, in Bitcoin blockchain the value of (r) is 10 minutes on average. Block creation will only take into account the entire block not block header. The proposed technique will automatically create a dummy block (b_{dummy}) on the existing public main branch, (b_{pub}) to avoid from the BDoS attack and selfish mining attack. Hence, the blockchain will be more stabilized and all the miners/pools will get equal chance for creating blocks. But in some cases, there may have some loss of the honest miners because of time limit but this is negligible. Although the proposed solution allows BDoS and selfish mining within ((r + \bar{e})) time but the probability of happening this is very low.
B. Avoidance of BDoS
Let, the attacker (\tilde{A}) creates a block (b_{\tilde{A}}) and appends it to the (B^*) and the resultant chain is (B_i). Rather than publishing the entire block (b_{\tilde{A}}), the (\tilde{A}) publishes only the block header(b_{\tilde{A}}) and withholds the block body (b_{\tilde{A}}) that contains mainly the list of transactions ((t_{\tilde{A}0}, t_{\tilde{A}1}, \ldots, t_{\tilde{A}T})). At some point, the system has been passed the ((r + \bar{e})) times, the system automatically generates an dummy block on the public main chain, (br_{pub}). As ((r + \bar{e})) times have been passed, the block header (b_{\tilde{A}h}) and withholds the block body (b_{\tilde{A}is}) are discarded and the (b_{dummy}) is added. The entire process is depicted in the following Fig. 6.
C. Avoidance of selfish mining
Let, the pool Pool({self}) creates a new block (b{self}), it leads a block over the (br_{pub}) on which the (m_{auth}) perform mining. At this point, if (m_{self}) keeps the (b_{self}) secret and update its (br_{pri}) to the Pool({self}) without publishing into the network, it is allowed only within the ((r + \bar{e})). After ending the period ((r + \bar{e})), the system automatically generates a dummy block on the public main chain i.e. the (b{dummy}) is added to (br_{pub}). No new block (b_{self}) is accepted on the previous chain. Fig. 7 depicts the entire process.
V. SOLUTION ANALYSIS
The proposed solution described above successfully avoids the BDoS attack and prevents the selfish mining problem. However, the solution has some limitations also.
The analysis of the proposed solution described in the following.
A. Loss of honest miner
Let, honest miners are trying to create a block with some transactions but within ((r + \varepsilon)) time they don’t manage to append the block to the blockchain. As dummy block (b_{\text{dummy}}) is added to the main chain after ((r + \varepsilon)) time, the effort of the honest miners will be lost fully. Let (\rho) is the probability that the honest miners are not able to mine a block then the amount of loss of honest miners in BDoS attack can be expressed by the following equation (4).
[ \text{Loss}{\text{miners}} = \rho \times a{\text{min}} \tag{4} ]
B. Loss of attacker
Let, the attacker is not able to manage to append the block to the blockchain with probability (\varpi) within ((r + \varepsilon)) time. As dummy block (b_{\text{dummy}}) is added to the main chain, the effort of the attacker will be lost fully. The amount of loss of attacker in BDoS attack can be expressed by the equation (5).
[ \text{Loss}{\text{attacker}} = \varpi \times a{\text{i}} \tag{5} ]
C. BDoS Attack within ((r + \varepsilon)) time
The proposed solution allows BDoS within ((r + \varepsilon)) time but in such scenario is very rare. Let, the attacker (\mathcal{A}), creates a block within ((r + \varepsilon)) time and only publishes the block header to discourage honest miners to participate in the mining process. The honest miners still mining on the top of the main chain knowing that the dummy block may be added after ((r + \varepsilon)) time discarding the block of attacker if it is not fully published. But if the attacker is able to create another block within ((r + \varepsilon)) time and publishes the first block fully then the efforts of honest miners will be totally lost. Now the attacker has another ((r + \varepsilon)) time for creating another block. If it is able to find another block, then it may publish the previous block and gain the rewards. This process may be continuing until the attacker is able to create a block within ((r + \varepsilon)) time. But for creating two blocks within ((r + \varepsilon)) time needs high computation cost which is inefficient to the attacker. In contrast, dummy block adding time ((r + \varepsilon)) needs to adaptive to mitigate this scenario. Thus probability of BDoS attack against the proposed solution is very low.
[ \begin{cases} \text{(t \leq (r + \varepsilon))} & \text{BDoS Attack within ((r + \varepsilon)) time.} \end{cases} ]
D. Selfish mining within ((r + \varepsilon)) time
The proposed solution allows selfish mining within ((r + \varepsilon)) time but in such scenario is very rare. Let, the pool (\text{Pool}{\text{self}}) creates a block within ((r + \varepsilon)) time keeps it secret. Again if the pool (\text{Pool}{\text{self}}) is able to create another block within the ((r + \varepsilon)) time and publishes the first block only then the efforts of honest miners will be totally lost. Now the attacker has ((r + \varepsilon)) time for creating another block. If it is able to find another block, then it may publish the previous block and gain the rewards. This process may be continuing until the attacker is able to create a block within ((r + \varepsilon)) time. But for creating two blocks within ((r + \varepsilon)) time needs high computation cost which is inefficient to the attacker. In contrast, dummy block adding time ((r + \varepsilon)) needs to adaptive to mitigate this scenario. Thus probability of selfish mining against the proposed solution is very low.
[ \begin{cases} \text{(t \leq (r + \varepsilon))} & \text{Selfish mining within ((r + \varepsilon)) time.} \end{cases} ]
E. Race between dummy block and new block
For the usual cases, the dummy block propagation time over the blockchain network is assumed to be (\varepsilon). For some cases, it may be more than the (\varepsilon) due to different constraints. Then there is a possibility of race condition if some of miners manage to create a block before getting the dummy block. This scenario is depicted in the following Fig. 10(a). However, the problem of forking in this case is trouble-free as the ((r + \varepsilon)) time is over, no new block is allowed to the main chain except the dummy block. So, the main chain after ((r + \varepsilon)) time is depicted in the Fig. 10(b).
[ \begin{cases} \text{(a) Race Condition} & \text{(b_{\text{pub}-1} \rightarrow b_{\text{pub}} \rightarrow b_{\text{new}} \rightarrow b_{\text{dummy}})} \ \text{(b) Main chain after ((r + \varepsilon))} & \text{(b_{n-1} \rightarrow b_{n} \rightarrow b_{\text{dummy}})} \end{cases} ]
VI. CONCLUSION
Blockchain denial of service (BDoS) and selfish mining are the two most critical attacks on blockchain technology which may affect incentive structure and increase the incentive of adversary miner, respectively. Unlike the conventional DoS, the BDoS affects the system’s mechanism design to manipulate the incentive structure to discourage honest miners to participate in the mining process. In contrast, in a selfish mining attack, the adversary miner keeps its discovered block private to fork the chain intentionally that aiming to increase the incentive of the adversary miner. This paper proposed a technique to successfully avoid BDoS.
and selfish mining attacks. The existing infrastructure of blockchain technology doesn’t need to be changed a lot to incorporate the proposed solution.
REFERENCES
[1] S. Nakamoto, “Bitcoin: a peer-to-peer electronic cash system, October 2008,” Cited on, 2008.
[2] Coinmarketcap, “Cryptocurrency Market Capitalizations,” 2019. https://coinmarketcap.com/ (accessed Aug. 20, 2022).
[3] I. Eyal and E. G. Sirer, “Majority Is Not Enough: Bitcoin mining is vulnerable,” Commun. ACM, vol. 61, no. 7, pp. 95–102, Jun. 2018, doi: 10.1145/3212998.
[4] S. Sharkey and H. Tewari, “Alt-PoW: An alternative proof-of-work mechanism,” in Proceedings – 2019 IEEE International Conference on Decentralized Applications and Infrastructures, DAPPCON 2019, Apr. 2019, pp. 11–18. doi: 10.1109/DAPPCON.2019.00012.
[5] F. Bravo-Marquez, S. Reeves, and M. Ugarte, “Proof-of-learning: A blockchain consensus mechanism based on machine learning competitions,” in Proceedings – 2019 IEEE International Conference on Decentralized Applications and Infrastructures, DAPPCON 2019, Apr. 2019, pp. 119–124. DOI: 10.1109/DAPPCON.2019.00023.
Useful information for enthusiasts:
- [1]YouTube Channel CryptoDeepTech
- [2]Telegram Channel CryptoDeepTech
- [3]GitHub Repositories CryptoDeepTools
- [4]Telegram: ExploitDarlenePRO
- [5]YouTube Channel ExploitDarlenePRO
- [6]GitHub Repositories Keyhunters
- [7]Telegram: Bitcoin ChatGPT
- [8]YouTube Channel BitcoinChatGPT
- [9] Bitcoin Core Wallet Vulnerability
- [10] BTC PAYS DOCKEYHUNT
- [11] DOCKEYHUNT
- [12]Telegram: DocKeyHunt
- [13]ExploitDarlenePRO.com
- [14]DUST ATTACK
- [15]Vulnerable Bitcoin Wallets
- [16] ATTACKSAFE SOFTWARE
- [17] LATTICE ATTACK
- [18] RangeNonce
- [19] BitcoinWhosWho
- [20] Bitcoin Wallet by Coinbin
- [21] POLYNONCE ATTACK
- [22] Cold Wallet Vulnerability
- [23] Trezor Hardware Wallet Vulnerability
- [24] Exodus Wallet Vulnerability
- [25] BITCOIN DOCKEYHUNT
Contact me via Telegram: @ExploitDarlenePRO