We present a strategy for a single quantum miner with relatively low hashing power, with the same ramifications as a 51% attack. Bitcoin nodes consider the chain with the highest cumulative proof-of-work to be the valid chain. A quantum miner can manipulate the block timestamps to multiply the difficulty by $c$. The fork-choice rule counts every block with increased difficulty with weight $c$. By using Grover’s algorithm, it is only $\sqrt{c}$ harder for the quantum miner to mine such blocks. By picking a high enough $c$, the single quantum miner can create a competing chain with fewer blocks, but more cumulative proof-of-work. The time required is $O\left(\frac{1}{r^2}\right)$ epochs, where $r$ is the fraction of the speed at which the quantum miner can produce blocks with Grover’s algorithm, compared to the honest network.
Most proof-of-work cryptocurrencies, including Bitcoin, are vulnerable to our attack. However, it will likely be impossible to execute in forthcoming years, as it requires an extremely fast and fault-tolerant quantum computer.
1 Introduction
In Proof-of-Work (PoW) [DN92], a prover can prove to other parties that a predefined computational effort has been spent. Is PoW “compatible” with quantum computing? More specifically, can the prover get more than a quadratic advantage due to Grover’s algorithm [Gro96]? Here, we study this question in the context of cryptocurrencies. It is often stated that a single quantum miner does not pose a security risk to Bitcoin’s security. This position is supported by the formal analysis made in [CGK\textsuperscript{+}23], which shows some desired properties (namely, common prefix and chain quality) are satisfied in a simplified model called the Bitcoin backbone protocol in a network consisting of a single quantum miner and additional (honest) classical miners.
This work shows that the contrary is true by exploiting an aspect that Ref. \cite{CGK+23} does not account for.
A single quantum miner, with relatively little hash power, can execute an attack in the presence of honest classical miners with the same ramifications as a 51% attack. Specifically, the attacker can double-spend transactions and censor others, thus breaking Bitcoin’s security, and can receive $1 – \epsilon$ of the block rewards for any $\epsilon > 0$.
The attack relies on the “chain work” consensus mechanism in Bitcoin and many other PoW based cryptocurrencies: In case of competing forks, Bitcoin nodes follow the branch which has the most accumulated PoW, see \cite[Nak08, Section 4]{Nak08} and \cite[Ant17, pp. 239–240]{Ant17}. In short forks, where different branches have the same difficulty, this coincides with the longest chain rule; but this may not be so in long forks, which span over more than one epoch and can have different difficulty adjustments: the sum of difficulties in the shorter chain may be higher than that in the longer chain. This consensus mechanism thwarts certain classical attacks (we discuss one such attack in more detail in Appendix B), but it leaves the protocol vulnerable to quantum attacks.
Remark 1. Our results do not contradict those in \cite{CGK+23}: as mentioned, their results hold in a simplified model. In their model, there are no difficulty adjustments; therefore, the longest chain rule and the chain with the most cumulative PoW coincide. In practice, a difficulty adjustment mechanism must be introduced; otherwise, due to fluctuations in the miners’ hash power, the rate at which blocks are created can be either higher or slower than desired. An earlier version of their work lists difficulty adjustments as an important future direction: “The first generalization to consider is the Bitcoin backbone protocol with variable difficulty” \cite[Section 6]{CGK+19}. As they point out, such a generalization was considered in the classical setting \cite{GKL17}; our work shows that the quantum generalization does not apply.
Remark 2. This work studies a setting with a single quantum miner. The fully quantum setting, where all miners use quantum hardware, is mostly uncharted territory. Ref. \cite{Sat20} shows that Bitcoin’s tie-breaking rule needs to be adapted. Ref. \cite{LRS19} analyzes the equilibria strategies for quantum miners in a simplified model.
The main advantage quantum miners have over classical miners is that they can use Grover’s algorithm. We now explain the essential properties of Grover’s algorithm for this work at a high level.
Let $f : {1, \ldots, n} \rightarrow {0, 1}$. We call $x$ a marked item if and only if ( f(x) = 1 ), and denote by ( k ) is the number of the marked items in ( f ). We assume that the function ( f ) is modeled as a black box, and every query made to the function is counted. Classically, it can easily be shown that one needs ( \Theta\left(\frac{n}{k}\right) ) queries to the function to find a marked item with constant probability. Grover’s algorithm gives a quadratic speed-up. That is, the quantum algorithm finds a marked item with high probability using only ( \Theta\left(\sqrt{\frac{n}{k}}\right) ) quantum queries to the function. Throughout this work, for the sake of simplicity, we ignore the constant factor in the ( \Theta(\cdot) ) notation and the probabilistic nature of Grover’s algorithm and treat it as if its running time is ( \sqrt{\frac{n}{k}} ) and success probability is 1. In the case of mining, the function ( f ) is defined as the function that returns 1 if the hash of a block with a nonce ( x ) is below the difficulty, and furthermore, we model the hash function as in the random oracle model. No further understanding of quantum computing or Grover’s algorithm will be needed. The interested reader is referred to Ref. [NC00] for an in-depth introduction to quantum computing.
The most important insight for the attack is the following: A difficulty increase by a factor of ( c ) makes it ( c ) times harder for classical miners to find a block, but only ( \sqrt{c} ) harder for quantum miners using Grover’s algorithm to do so. A block with such increased difficulty is accounted as ( c ) blocks with the original difficulty for the accumulated PoW, but is only ( \sqrt{c} ) harder for the quantum miner to find. By increasing the difficulty by a factor of ( c ), a quantum miner can increase the rate at which they add cumulative work to a chain by a factor of ( \sqrt{c} ).
We will describe the main difficulty increase attack in this section and three more variants in Section 2, each improving or addressing a problem in the previous variant. The only downside of these improved variants is that they take longer to execute.
For concreteness, we use a running example with the same parameters as in Bitcoin: the expected time to create a block by the classical miners is 10 minutes, and difficulty adjustments are made every epoch, which lasts 2016 blocks. Creating an epoch worth of blocks takes two weeks if a block is created every 10 minutes, and we refer to this period as epoch-time. We further assume that the quantum miner can mine a block every 40 minutes. In other words, by running Grover’s algorithm, the miner can create a block at ( r = \frac{1}{4} ) of the speed relative to the classical miners.
Remark 3. Note that a quantum miner that can generate a block at a speed ratio ( r ) compared to the classical miners might generate less than ( r ) of the total revenue from these blocks if they were to mine on top of the honest chaintip, due to stale blocks. Stale blocks are blocks that the quantum miner generates but would eventually not be part of the longest chain due to other
1Note that it may take much longer than one epoch-time for the quantum miner to mine one epoch of blocks, especially as the difficulty in that epoch increases.
2In our running example, we label numbers derived from this choice of ( r ) in blue. blocks being mined simultaneously. This phenomenon has some surprising consequences observed and analyzed by Nerem and Gaur [NG23], but will not be relevant to our work: Since the attacker mines a chain independent of the honest network, they are not constrained by the possibility that some of their blocks will be made stale.
Main attack. The attacker’s first task is to increase the difficulty by a factor of ( \frac{4}{r^2} = 64 ), where ( r = \frac{1}{4} ) mentioned above. To achieve this first task, the attacker starts to mine an entire epoch with fake timestamps such that the blocks seem to be created ( \frac{4}{r^2} = 64 ) times more often than they should be. Recall that difficulty adjustments aim to ensure blocks are created at a designated rate: one block is expected every 10 minutes in Bitcoin. At the end of the epoch, since the timestamps in these blocks appeared to occur every ( \frac{10}{64} ) minutes, the difficulty in the attacker’s chain is increased by a factor of ( 64 = \frac{4}{r^2} ), as desired.(^3)
The miner’s second task is to create another epoch of blocks at the new difficulty. In more detail, the miner creates one epoch worth of blocks—that is 2016 blocks—with the new difficulty (which is 64 times harder than the original one), by spacing the timestamps at the usual 10 minutes. The miner publishes these blocks, while ignoring blocks created by the classical miners.
We claim that after the first epoch with the increased difficulty is published, the quantum miner has a chain with more accumulated PoW than the classical miners. To see this, let us first calculate how long it takes for the quantum miner to achieve the first goal. Recall that it takes ( \frac{10}{r} = 40 ) minutes to mine a single block with the original difficulty by the quantum miner, which is 4 times as much the classical miners take in expectation. So, it will take ( \frac{1}{r} = 4 ) epoch-times (8 weeks) to achieve the first goal by the quantum miner.
The difficulty of the second epoch is ( \frac{4}{r^2} = 64 ) times higher, so mining it would take the attacker ( \sqrt{\frac{4}{r^2}} = \frac{2}{r} = 8 ) times more than the first epoch; in other words, quantum mining an epoch with the new difficulty will take ( \frac{2}{r} \cdot \frac{1}{r} = \frac{2}{r^2} = 32 ) epoch-times.
The quantum miner accumulated ( 65 = 1 + \frac{4}{r^2} \geq \frac{4}{r^2} ) epochs worth of PoW measured in the original difficulty. The time it took is ( 36 = \frac{1}{r} + \frac{2}{r^2} \leq \frac{3}{r^2} ) epochs. So, we see that it took the quantum miner at most ( \frac{3}{r^2} ) epoch-times, to generate at least ( \frac{4}{r^2} ) epochs worth of PoW. Therefore, the quantum miner’s chain has at least ( \frac{1}{r^2} ) more cumulative PoW than the expected cumulative PoW by the classical miners, so with high probability, the quantum miner’s chain will be the chain with the most accumulated PoW.
This variant allows the quantum miner to double spend a transaction: the quantum miner can mine his chain privately and, while mining, spend
(^3)This is not entirely accurate, see p. 9, and Variant 4 which resolves this issue.
| n | difficulty | CPoW | timeToCreate | realTimeWhenCreated | timestamp |
|---|---|---|---|---|---|
| 1 | 1 | 1 | 4 | 4 | 1.56 · 10^{-2} |
| 2 | 64 | 65 | 32 | 36 | 1.02 |
Table 1: The main attack. The column headers represent the following: ( n ) is the epoch number, \textit{difficulty} is the difficulty of that epoch relative to the original difficulty, \textit{CPoW} is the cumulative Proof-of-Work of the quantum miner, \textit{timeToCreate} is the time the quantum miner invested in creating this epoch, measured in epoch-time (for example, 1 represents 2 weeks for Bitcoin), \textit{realTimeWhenCreated} is the real time, measured in epoch-times, when that epoch was created, and \textit{timestamp} represents the timestamps that appear in the last block in that epoch of the quantum miner, measured in epoch-time. All the other tables have the same format.
A transaction on the classical miners’ chain, and post a conflicting transaction on his chain. After this transaction is confirmed (since the quantum miner is mining in private, the transaction will have many confirmations), and the goods are received, the miner can publish his private chain, which will eventually have more PoW, hence causing a long-term reorganization, causing the original transfer to get canceled. The details of the Variant 1 attack are depicted in Table 1.
The quantum miner can keep mining at the new difficulty, while ignoring the blocks generated by the classical miners, and produce 100% of the blocks in the chain with the most cumulative PoW.
This strategy has several issues that are discussed and addressed in several variants in Section 2. The first issue is that the time-stamps are lagging: the timestamps in the blocks generated by the quantum miner lag behind real time; This issue is addressed in Variant 2. The next issue is related to the incentives. The quantum miner that uses the strategy above creates only 2 epochs worth of blocks, even though the total time of the attack is 36 epochs. In Variant 3, we show an attack where the quantum miner’s revenue gets arbitrarily close to the maximal revenue, namely, the revenue generated by an honest classical miner with 100% of the hashing power. In the variants above, we apply sharp changes to the mining difficulty. Bitcoin limits the increase and decrease factor of the difficulty by a factor of four. This can be easily addressed, by making smaller changes to the difficulty, as demonstrated in Variant 4. The main drawback of these variants compared to the attack above, is that they take longer to perform, though, asymptotically, they all take ( O \left( \frac{1}{r^2} \right) ) epoch-times to implement.
2 Variants
2.1 The Lagging Issue
Even though the quantum miner can create a chain with higher cumulative PoW, the timestamps in the chain in the variant above are lagging behind the real time. More specifically, in the example above, one can notice that the timestamp in the second row is 1.02 epoch-times, whereas the real time is 36 epoch-times. Therefore, the attack can easily be noticed. Furthermore, an attempt to rule out the attack can be made, by changing the fork choice rule: blocks that have timestamps that substantially lag behind the real time can be ignored or alerted by honest nodes. This is the case for the Bitcoin Core client, which will remain in “initial block download” state if its chain tip is over 24 hours old, and will alert the user.
In the 2nd variant, when the quantum attacker’s chain is published, the final time-stamp does not lag behind the real time. The modified fork-choice rule would permit the fork of the quantum miner and, therefore, is ineffective for the second variant.
Variant 2. The goal of this variant is to resolve the lag that is created in the first variant. Table 2 shows the details of the attack. The attack proceeds in three phases: After the difficulty is increased in the first phase, as in Variant 1, there is a second phase in which the quantum miner reduces the difficulty, to a lower level than the original difficulty, which allows the quantum miner to generate blocks much faster in the third phase. Specifically, the difficulty is ultimately reduced to $r^6 = \frac{1}{4}$. This is done by reducing the current difficulty (which is $\frac{4}{r^2}$) by a factor of 8 for $\log_8(\frac{4}{r^8}) = 6$ epochs.
The time that it takes to mine the hardest epoch is $\frac{2}{r^2} = 32$ epoch-times, and every consecutive epoch has an easier difficulty by a factor 8, so each consecutive block takes only a fraction of $\frac{1}{\sqrt{8}}$ the time compared to the previous epoch. Overall, it takes
$$\frac{2}{r^2} \sum_{i=0}^{\log_8(\frac{4}{r^8})-1} \left(\frac{1}{\sqrt{8}}\right)^i \leq \frac{2}{r^2} \sum_{i=0}^{\infty} \left(\frac{1}{\sqrt{8}}\right)^i = \frac{2}{r^2(1 – \frac{1}{\sqrt{8}})}$$
4While it is technically only necessary to reduce the difficulty to below $r^2$ to make up ground on the timestamp gap, our choice of $r^6$ makes the analysis more clean.
5Note that the alternative in which the difficulty is decreased in 1 epoch by this factor would take much longer: It would require making an average timestamp increase of $\frac{4}{r^8}$ block times, leading to a timestamp in the future. This solves the issue at hand, where the timestamps in the attacker’s blocks are noticeably behind the real time, but introduces the opposite problem.
The way to reduce the difficulty by a factor $d$ (up to rounding errors) while inducing the least change in timestamp is to reduce the difficulty for $\ln(d)$ epochs, where the difficulty decreases by a factor $e$ between every two epochs.
epoch-times for the quantum miner to reduce the difficulty to the easy level.
Recall that the quantum miner can generate each block at the original difficulty every ( \frac{1}{r} = 4 ) blocks. Due to the decreased difficulty, and Grover’s algorithm running time, mining a block at that reduced difficulty takes only ( \sqrt{\frac{1}{r}} = r^2 = \frac{1}{16} ) epoch-times. The timestamps are kept at the normal pace (i.e., a block every 10 minutes), so the lag is getting shorter. The quantum miner keeps mining until there is no significant gap between the timestamp and when the block is created. In this example, as seen in Table 2, the lag is shortened by mining 5 additional blocks at the easy difficulty level. As can be seen, there is no significant lag between the timestamp and the time the blocks are published: 53.72 vs 53.02 epoch-times (and can be made arbitrarily small easily).
Recall that the goal of the last phase is to make sure that there is no lag between the timestamp and the real-time in the last epoch of the attack. The time it takes for the quantum miner to mine each epoch at the easy difficulty is ( \sqrt{\frac{1}{r}} \cdot \frac{1}{r} = r^2 ) epoch-times, whereas the timestamp grows by exactly 1 epoch-time each epoch, so the gap between the timestamp and the real time shrinks by ( 1 – r^2 ) epoch-times each mined epoch. The total time that needs to be gapped is at most the total time of the attack in the first two phases, which is upper-bounded by ( \left( \frac{1}{r} + \frac{2}{r^2(1 – \frac{1}{\sqrt{8}})} \right) ). So, the total time devoted by the quantum miner to mine at the easy difficulty is at most ( \left( \frac{1}{r} + \frac{2}{r^2(1 – \frac{1}{\sqrt{8}})} \right) \cdot \frac{r^2}{1 – r^2} ) epoch-times. The overall epoch-time of the attack (that is, by adding the time for the previous phase) is
[ \left( \frac{1}{r} + \frac{2}{r^2(1 – \frac{1}{\sqrt{8}})} \right) \cdot \left( 1 + \frac{r^2}{1 – r^2} \right) \leq \frac{3.57}{r^2}, ]
where we used ( r \leq \frac{1}{4} ) in the last inequality.
Remark 4. Notice that for attackers with a value of ( r ) close to 1, the attack as laid out takes a long time, because we do not reduce the difficulty to a very small value. For this reason it is convenient to assume that an attacker with ( r > \frac{1}{4} ) simply carries out the attack as if ( r = \frac{1}{4} ), so that they decrease the difficulty sufficiently in the latter stage. This preserves the ( O(\frac{1}{r^2}) ) asymptotics.
So, the expected cumulative PoW that the honest network can generate is at most as above. The quantum miner generates ( \frac{4}{r^2} ) PoW in the second epoch of the attack alone, so the accumulated PoW on the quantum attacker’s chain is greater than the expected accumulated PoW of the classical miners.
| n | difficulty | CPoW | timeToCreate | realTimeWhenCreated | timestamp |
|---|---|---|---|---|---|
| 1 | 1 | 1 | 4 | 4 | 1.56 \cdot 10^{-2} |
| 2 | 64 | 65 | 32 | 36 | 8.02 |
| 3 | 8 | 73 | 11.31 | 47.31 | 16.02 |
| 4 | 1 | 74 | 4 | 51.31 | 24.02 |
| 5 | 0.13 | 74.13 | 1.41 | 52.73 | 32.02 |
| 6 | 1.56 \cdot 10^{-2} | 74.14 | 0.5 | 53.23 | 40.02 |
| 7 | 1.95 \cdot 10^{-3} | 74.14 | 0.18 | 53.4 | 48.02 |
| 8 | 2.44 \cdot 10^{-4} | 74.14 | 6.25 \cdot 10^{-2} | 53.47 | 49.02 |
| 9 | 2.44 \cdot 10^{-4} | 74.14 | 6.25 \cdot 10^{-2} | 53.53 | 50.02 |
| 10 | 2.44 \cdot 10^{-4} | 74.14 | 6.25 \cdot 10^{-2} | 53.59 | 51.02 |
| 11 | 2.44 \cdot 10^{-4} | 74.14 | 6.25 \cdot 10^{-2} | 53.65 | 52.02 |
| 12 | 2.44 \cdot 10^{-4} | 74.14 | 6.25 \cdot 10^{-2} | 53.72 | 53.02 |
Table 2: The table shows the details of Variant 2. Note that in the strategy, the timestamp in epoch 12 is 53.02 epoch-times, while the real time lags only slightly behind it 53.72. This should be compared vis-a-vis the first variant, where the lag was substantially higher. Note that during that 53 epoch-times, the miner has mined only 12 epochs worth of blocks. Therefore, the block subsidy from the quantum mining relative to a miner that mines all the blocks with the original difficulty is only 23%; this will be improved in the third variant.
2.2 The Revenue Issue
In Variant 2, the attacker creates only 12 epochs worth of blocks, even though in real time, the attack takes about 53 epoch-times. This means that the revenue during the attack from the block subsidy is only ( \approx 23% ) of the total revenue that can be generated from mining at the original speed. Typically, a 51% attacker would accumulate 100% of the expected block subsidy for the time period they carry out the attack.
Next, we show a variant in which the revenue from the block subsidy can get arbitrarily close to the total revenue that can be extracted by a classical miner with 100% of the hashing power.
Variant 3. Increasing the block subsidy revenue is done by adding several epochs in the increased difficulty, and additional epochs in the decreased difficulty, until the timestamp and the time in which the quantum miner’s chain is published are close enough. In the example shown in Table 3, three epochs are mined at the increased difficulty (compared to one epoch in Variant 2), and 72 epochs with the decreased difficulty (compared to five epochs in Variant 2). The total time in this variant is 121.84 epochs. During it, the quantum miner generates 80 epochs worth of blocks, yielding approximately 66% of the block subsidy revenue that the entire network,
| n | difficulty | CPoW | timeToCreate | realTimeWhenCreated | timestamp |
|---|---|---|---|---|---|
| 1 | 1 | 1 | 4 | 4 | 1.56 · 10^{-2} |
| 2 | 64 | 65 | 32 | 36 | 1.02 |
| 3 | 64 | 129 | 32 | 68 | 2.02 |
| 4 | 64 | 193 | 32 | 100 | 10.02 |
| 5 | 8 | 201 | 11.31 | 111.31 | 18.02 |
| 6 | 1 | 202 | 4 | 115.31 | 26.02 |
| 7 | 0.13 | 202.13 | 1.41 | 116.73 | 34.02 |
| 8 | 1.56 · 10^{-2} | 202.14 | 0.5 | 117.23 | 42.02 |
| 9 | 1.95 · 10^{-3} | 202.14 | 0.18 | 117.4 | 50.02 |
| 10 | 2.44 · 10^{-4} | 202.14 | 6.25 · 10^{-2} | 117.47 | 51.02 |
| 11 | 2.44 · 10^{-4} | 202.14 | 6.25 · 10^{-2} | 117.53 | 52.02 |
| 12 | 2.44 · 10^{-4} | 202.14 | 6.25 · 10^{-2} | 117.59 | 53.02 |
| 13 | 2.44 · 10^{-4} | 202.14 | 6.25 · 10^{-2} | 117.65 | 54.02 |
| 14 | 2.44 · 10^{-4} | 202.14 | 6.25 · 10^{-2} | 117.72 | 55.02 |
| … | |||||
| 78 | 2.44 · 10^{-4} | 202.16 | 6.25 · 10^{-2} | 121.72 | 119.02 |
| 79 | 2.44 · 10^{-4} | 202.16 | 6.25 · 10^{-2} | 121.78 | 120.02 |
| 80 | 2.44 · 10^{-4} | 202.16 | 6.25 · 10^{-2} | 121.84 | 121.02 |
Table 3: The table shows the details of Variant 3. Note that epochs 15–77 were omitted; their difficulty is the same as epoch 14, and the effect is similar to the epochs below and above them.
mining at the original speed, would have generated. This improves upon the 23% of the block subsidy revenue generated in Variant 2. In Appendix A we discuss this attack in more generality, where the attack achieves $1 – \epsilon$ fraction of the revenue generated honestly, for an arbitrary small $\epsilon$, and takes $O\left(\frac{1}{\epsilon^2 r^2}\right)$ epochs.
2.3 The Permitted Difficulty Adjustments Issue
In some cryptocurrencies, the shifts in the PoW difficulty adjustments are bounded. For example, in Bitcoin, the difficulty between two consecutive epochs cannot increase or decrease by more than a factor of 4. In all the previous variants, we increased the difficulty dramatically in the first epoch and reduced it by a factor of 8 in several consecutive epochs: all these transitions are incompatible with Bitcoin’s difficulty adjustments. This aspect is addressed in the following variant.
6See https://github.com/bitcoin/bitcoin/blob/4b1196a9855dcd188a24f393aa2fa21e2d61f061/src/pow.cpp#L56.
| n | difficulty | CPoW | timeToCreate | realTimeWhenCreated | timestamp |
|---|---|---|---|---|---|
| 1 | 1 | 1 | 4 | 4 | 0.5 |
| 2 | 2 | 3 | 5.66 | 9.66 | 1 |
| 3 | 4 | 7 | 8 | 17.66 | 1.5 |
| 4 | 8 | 15 | 11.31 | 28.97 | 2 |
| 5 | 16 | 31 | 16 | 44.97 | 2.5 |
| 6 | 32 | 63 | 22.63 | 67.6 | 3 |
| 7 | 64 | 127 | 32 | 99.6 | 3.5 |
| 8 | 128 | 255 | 45.25 | 144.85 | 4 |
| 9 | 256 | 511 | 64 | 208.85 | 5 |
| 10 | 256 | 767 | 64 | 272.85 | 6 |
| 11 | 256 | 1,023 | 64 | 336.85 | 8 |
| 12 | 128 | 1,151 | 45.25 | 382.11 | 10 |
| 13 | 64 | 1,215 | 32 | 414.11 | 12 |
| 14 | 32 | 1,247 | 22.63 | 436.74 | 14 |
| 15 | 16 | 1,263 | 16 | 452.74 | 16 |
| 16 | 8 | 1,271 | 11.31 | 464.05 | 18 |
| 17 | 4 | 1,275 | 8 | 472.05 | 20 |
| 18 | 2 | 1,277 | 5.66 | 477.71 | 22 |
| 19 | 1 | 1,278 | 4 | 481.71 | 24 |
| 20 | 0.5 | 1,278.5 | 2.83 | 484.53 | 26 |
| 21 | 0.25 | 1,278.75 | 2 | 486.53 | 28 |
| 22 | 0.13 | 1,278.88 | 1.41 | 487.95 | 30 |
| 23 | 6.25 · 10^{-2} | 1,278.94 | 1 | 488.95 | 32 |
| 24 | 3.13 · 10^{-2} | 1,278.97 | 0.71 | 489.66 | 34 |
| 25 | 1.56 · 10^{-2} | 1,278.98 | 0.5 | 490.16 | 36 |
| 26 | 7.81 · 10^{-3} | 1,278.99 | 0.35 | 490.51 | 38 |
| 27 | 3.91 · 10^{-3} | 1,279 | 0.25 | 490.76 | 40 |
| 28 | 1.95 · 10^{-3} | 1,279 | 0.18 | 490.94 | 42 |
| 29 | 9.77 · 10^{-4} | 1,279 | 0.13 | 491.06 | 43 |
| 30 | 9.77 · 10^{-4} | 1,279 | 0.13 | 491.19 | 44 |
| 31 | 9.77 · 10^{-4} | 1,279 | 0.13 | 491.31 | 45 |
…
539 9.77 · 10^{-4} 1,279.5 0.13 554.81 553
540 9.77 · 10^{-4} 1,279.5 0.13 554.94 554
541 9.77 · 10^{-4} 1,279.5 0.13 555.06 555
Table 4: The table shows the details of Variant 4. As can be seen, the difficulty adjustments in this variant are at most 2 and at least $\frac{1}{2}$, compared to the previous variants, where the increases in difficulty were much higher, and the decrease in difficulty reached a factor of $\frac{1}{8}$; these sharp changes are not in the valid regime of Bitcoin’s difficulty adjustments, which is $[\frac{1}{4}, 4]$. Note that the relative revenue in this variant increased to $\frac{541}{555.06} \approx 97%$.
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