More on the Security Against Fee Sniping in RSK
In a previous article we discussed different fee sniping attacks and we analyzed how they could impact RSK. In this article we dig deeper into the simplest form of fee sniping attack and we present the results of the simulation of different fee sniping strategies. We show how the two mechanisms RSK has to protect against fee sniping (fee smoothing and reward sharing) work very well in tandem to make the known attacks currently impractical. Our simulations also show that the impact of the fee sniping attack to the honest users of the network is minimal: Because of RSK short block interval, the average time the network is in a fee sniping contention state is 1 minute (2 mining events), and 97% of the fee sniping contentions are resolved in less than 3 minutes.
We center our analysis on a blockchain state where one user has broadcast a transaction T paying very high fees. This transaction could have a malicious intent (disrupt the network) or may have been generated by a human error. We don’t stop to analyze the motive, but this transaction will be considered a bribe, because it incentivizes miners to deviate from the honest protocol by mining an alternate fork also containing the bribe, and leading to a chain reorg. Then we analyze several potential deviations from the honest protocol that can be executed by a malicious miner (that we call attacker) to potentially increase his profit. Because these deviations can be applied each time such a bribe transaction is found, we call them strategies.
All examples and simulations are valid under the following assumptions: A bribe transaction T is included in a block at height N paying a high value in fees. Without loss of generality, we assume there is a single malicious miner (the attacker), and the remaining miners are honest (if there were more malicious miners, we can group them into a single malicious coalition). We assume our attacker is very powerful, having from 40% to 50% of the total hashrate. In all our scenarios, the attacker engages in a race against the honest chain, and he wins if he can recover from a K block deficit, where K varies depending on the strategy analyzed.
We characterize the bribe in T as the ratio between the bribe amount and the average block reward (which in RSK matches the average fees collected per block). Since there are no constants involved in fee distribution formulas, what matters for our analysis is this ratio. We analyze 3 ratios: 10X, 100X and 1000X. We believe that a bribe higher than 100X is unrealistic, and a bribe higher than 1000X is prohibitive. To justify this, we can compare RSK block rewards with Bitcoin and with Ethereum. If the average block rewards in RSK reached parity with Bitcoin fees over the same period of time, then each RSK block would pay 0.0031 BTC in fees, or 126.7 USD @ 40K USD/BTC rate. A 1000X bribe means the attacker spends 126.7K USD just to momentarily disrupt the network for approximately 1 minute. If the average block rewards in RSK reached parity with Ethereum, then each RSK block would pay 1.08 ETH in fees, or 2700 USD @ 2500 USD/ETH. A 1000X bribe means the attacker spends 2.5M USD for the same short network disruption. We believe that RSK fees will behave similarly to Ethereum in the future, as the use cases of both platforms are similar, and that attack costs are prohibitive for higher bribes.
Limitations
While we think bribes higher than 1000X need not be considered, we should note that, if higher bribes are expected, a new variable needs to be taken into account in the model: The attacker may be willing to gamble all rewards to create 10 consecutive blocks (at a probability lower than 1/1000 for a 50% hashrate) in order to censor uncle blocks and avoid losing 5% of the bribe in uncle rewards. The opposed event (honest miners mining 10 consecutive blocks) does not cancel out the censorship advantage because the attacker can release the first block in his fork to receive an uncle reward.
Our simulations do not consider network packet delays, block template switching delays in mining pools, reduced transaction throughput due to the fork, nor mempool congestion. The mempool could become congested by a chain fork when both sides of the fork have almost equal hashrate. For example, in case of a 50/50 split, the transaction processing volume of the network would be halved. Congestion incentivizes users to increase their transaction fees, and the congestion period will extend beyond the fork contention period. Increased fees could in fact compensate for the revenue loss during the fork, or even provide a positive net revenue for miners as fee estimators in wallets can overshot. However, this is a minor effect as our simulations are mostly affected by the high value of the bribe compared to normal transaction fees.
We do not attempt to analyze the miner atomization attack described in our previous article. That attack assumes multiple independent parties which are all rational, and that deviate from the honest protocol simultaneously. Therefore, simulating such an attack requires testing many potential attack strategies and combining them in different proportions, which is much more computationally demanding. In our analysis, the honest miners can be simulated easily because they follow the protocol, and only 4 malicious strategies and a single malicious party is simulated against the honest miners. We do not mix different malicious strategies. While we do not prove that RSK is protected from all kinds of fee sniping strategies, we believe that we’ve covered the intuitive strategies, and some more advanced ones, so that we can state that RSK is protected from fee sniping with high confidence
Best Chain Selection
A first strategy available to the attacker is to try to mine a competing block at height N containing T before the honest chain mines a block at height N+1. We define K as the number of blocks the attacker has to mine to overtake the honest chain. Depending on how a certain blockchain handles forks of similar length, K can be 1, 2 or some probabilistic value in-between. In the case of Bitcoin, the protocol uses the “first-seen” rule, and difficulty adjustments are rare, so given equal fork lengths, the attacker who starts 1 block behind the honest chain will hardly ever win a tie. Therefore to overtake the honest chain in Bitcoin we need K=2 (the attacker fork is longer than the honest fork). In the case of a blockchain with uniform random tie-breaking (also called UDTB), which is a rule that has been proposed to improve selfish mining, we get K=1 with 0.5 probability, and K=2 otherwise. In the case of RSK, there is a complex tie-breaking rule which involves the per-block difficulty adjustment, the fees paid and the block hash. You can read about this rule in RSKIP15. Many times the blockchain fields that govern tie-breaking can be controlled by the attacker with little downside, so the attacker could potentially win all tie-breaks with K=1. For example, if the attacker needs to mine a single block to match the honest fork length, the attacker has a 50% chance that his block hash is lower than the honest block hash, because by a consensus rule nodes pick the block with lower hash. When the attacker needs to mine two blocks to match the honest chain length, he can tweak the timestamp of the first block so that difficulty in the following block increases 1/400, making his fork slightly more heavy than the honest chain of similar length.
To achieve a conservative bound on the security of RSK, we assume the worst case where the attacker can win all ties. In practice, this is unrealistic because RSK mining pools either only update their block template regularly once every ~30 seconds (and when a bitcoin block is received) or they avoid updating their block templates if the last update was closer than ~30 seconds. If they use this last strategy, then if two competing blocks are received in a short time, then the first one received will be chosen as parent for mining, even if the consensus rules command that the best parent is the second. Therefore, while in theory the RSK protocol gives an advantage to the attacker to win tie-breaks, in practice the RSK blockchain can behave as the first-seen rule. Because of this, the attacker profits computed by simulations presented here are overvalued. Detecting what is the most used strategy to update block templates in mining pools is an interesting further research.
Strategies
Now we present four potential fee-sniping strategies. Examples are analyzed with a limited 2-events simulation window and the maximum reward on a successful attacks is computed. In the following section, we’ll show the actual results of simulated executions for tens of thousands of attack attempts.
Honest Mining
First, we consider that our attacker does not misbehave. This will give us a reference revenue to compare the different attacks too. For all our graphical examples, we’ll consider an average fee per block of 10 BTC, and a bribe transaction that pays 200 BTC in fees (these amounts do not reflect actual block rewards). The attacker hashrate ratio is a=0.5 (50%). The following diagram depicts the rewards paid in each block after a bribe transaction is included in block N:
Because a bribe transaction affects an infinite number of following blocks (assuming infinite value precision), we should also simulate an infinite number of blocks. Since this is not possible for an event-driven simulator, we restrict our simulation to 100 mining events.
In our diagrams and examples, we compute rewards over only the first 2 mining events for our different strategies. While this is inexact, it gives a good approximation of the attacker’s revenue on success, since after the contention is over the attacker collects the same rewards for all strategies. The following diagram shows that the attacker behaving honestly will collect (on average) 50% of the rewards of the two blocks following block N. The average reward is 27.1 BTC.
Considering infinite mining events, we know that the 50%-attacker will get 50% of the bribe minus the 20 BTC already paid, so the real average extra reward is 180/2 = 90 BTC.
One Selfish Block (OSB)
The attacker tries to re-mine the block at height N, and we assume the network chooses the attacker’s fork. Since the attacker’s block has a sibling block, he receives only half of the reward (15 BTC instead of 30 BTC).
While the potential revenue collected in 2 mining events is 1.9 BTC higher than the revenue received in honest behavior (29 BTC instead of 27.1), the chance he succeeds is only 50%, losing 14 BTC if he does not, which makes this strategy non-profitable.
Two Selfish Blocks (TSB)
This strategy considers mining an additional selfish block, at the expense of lower success probability.
While the potential revenue is 15.9 BTC higher, the chances that the attacker mines two consecutive blocks are lower. The average reward would be 10.75, which is lower than the expected 27.1 from honest behavior. However, if the attacker mines one block, but loses the race to the honest miners, he still gets 50% of the block N reward for his uncle block.
The simulation also considers a longer race where the attacker creates one block, then the honest miner creates another, continuing alternating roles until the attacker finally mines two blocks in a row. In real life, if this attack is profitable, so is performing selfish mining even if the attacker was the first to mine the bribe transaction, but selfish mining is also not profitable in that scenario.
Delay Bribe (DB)
In this strategy, the attacker tries to avoid sharing the bribe. To do so, he creates a dummy block at height N without the bribe and keeps mining selfishly the next block with the bribe.
The revenue on success is 35 BTC, which is lower than the previous strategy. In this case, even if the attacker mines one block but loses the race, he gets 50% of the block N reward, which is 15 BTC. At first sight, it seems that this strategy is always worse than Two Selfish Blocks. However, only if we analyze infinite events can we find that it can be better. When the attacker wins the race, he shares only 5 BTC with the honest miners, instead of 15 BTC as is the case of the Two Selfish Blocks strategy. This means that in all future blocks, the difference (10 BTC) will be shared between all miners, including the attacker. Therefore he gets an additional 5 BTC of future rewards. But also if the attacker wins the race mining just 2 blocks, all future rewards are 1.8 BTC higher and the attacker will also get a share of that future pot. While for our 20X bribe example the Delay Bribe strategy looks inferior, for a 100x bribe it is clearly superior.
One could compare this strategy with a strategy where the attacker starts creating the dummy block when the attacker sees the bribe in the memory pool, and before the honest miners mine the bribe transaction. We simulated this strategy and it is much worse than honest mining because the attacker loses the high chance to collect the full bribe reward. Note that the Delay Bribe strategy improves if on average the honest miners create several uncles per block, as when the attacker mines the bribe, the honest miners may keep mining the block at height N, which does not contain any portion of the bribe. Honest miners will never mine siblings of the attacker’s block containing the bribe.
Advance Bribe (AB)
In this strategy, which is the opposite of Delay Bribe, the attacker creates a child of the grandparent block where the bribe is, so the first block he mines it at height N-1. The attacker begins from a 2-block deficit, so to overtake the honest chain he must mine two blocks before the honest chain mines one more. In case the attacker mines a single block, he gets 50% for the uncle reward, but the reward he gets is only 5 BTC (not 15 BTC).
This strategy seems to be inferior to Two Selfish Blocks, with lower revenue in theory but also with lower success probability if we consider that RSK behaves in practice as having a first-seen rule.
Simulations
Here we show the expected percentage revenue increase for the described strategies, for a 10X bribe (a bribe that is 10 times higher than the average revenue/block), 100X and 1000X bribes, considering attackers having 40%, 45% and 50% of the hashrate.
In the following table we present the profit/loss of each strategy as a percent of the honest strategy profit.
We highlight in green the scenarios which the attacker profits from his fee sniping strategy.
Protocol Improvements
While the current protocol RSK does not have any problem, we can still think of potential changes that improve its resilience against fee sniping.
Grandparent Difficulty Adjustment
One of the methods the attacker has to force nodes to choose his fork when two competing forks are the same length (with at least two blocks each) is to slightly increase the difficulty of the second block by decreasing the timestamp of his first block. This causes the second block to adjust its difficulty upward. To prevent this from happening, the difficulty adjustment algorithm can be modified so that the difficulty change affects the grandchildren block, and not the child block. The only downside is that this delay might introduce slight high- frequency difficulty oscillations, which are negligible.
Increase the Uncle Reference Interval
Currently, uncle blocks can be referenced for 10 blocks. This means that an attacker with a high hashrate (>45%) could try to censor sharing a high bribe (>1000X) with a probability whose inverse is close to the potential reward. Although such a bribe is impractical. we can still reduce any potential impact by increasing the reference interval to 20 blocks.
Per-transaction Fee Sharing
One potential additional deterrent that RSK could use is to split a transaction reward between uncles that also included that particular transaction. For example, in the case of the Delay Bribe strategy, the attacker will be forced to share the bribe he included in block (N+1) with the honest block that also includes the bribe at block N.
This change forces the attacker to fork the honest chain at block (N-2) to avoid the honest block at height N to be referenced. The attacker would need to recover from a 3-block deficit, having a much lower probability of success. The following diagram depicts the adapted strategy:
However, technically this requires changes in the uncle block format: either uncle blocks include the full list of transaction ids in it, or miners need to include Merkle paths of certain transactions they want fees to be shared. In both cases, the uncle block reference size will be increased considerably.
The same effect on fees is obtained if we let not only uncles but also cousins (stale grandchildren) to be referenced like uncle blocks. However, the benefit is low and the side-effects of this consensus change are numerous.
Legalize Uncle-mining
We can redefine what miner good behavior is, and code rules that force miners to mine uncle blocks when there is a high fee pot to share. Miners would stop extending the best chain, and start mining uncle blocks until there is no more revenue to be made. What is important is that miners won’t try to replace the honest block, but only to get a share of its reward.
With this change, the attacker would need to mine 10 consecutive blocks to prevent the inclusion of honest miners’ uncle blocks. We can see that while this rule may reduce the impact of fee sniping, it enables the miner atomization attack. The following diagram depicts an uncle mining situation:
However, since we showed that there are almost no incentives to mine uncle blocks to grab a bribe, this protocol change will not provide any benefit for RSK.
Better Smoothing of Fee Payments
We could change the fee smoothing function so that the miner gets more fees from the fee pot, but fewer fees from the last block reward (for example, 15% from the pot, and 5% from the last block, instead of 10% from both). To counteract this change, the attacker could modify the strategy and try to mine an extra selfish block and collect the high fee from the pot anyway. We could generalize this rule, and establish that the fees collected by a block N are distributed in equal shares in the next Q blocks (for example Q=10). However, if block N contains a high bribe, there will be an abrupt reduction of fees at block (N+Q) that may incentivize uncle mining of block (N+Q-1).
Outlaw High Gas price transactions
The simplest consensus change to prevent fee sniping is to prevent transactions with very high fees to be included in blocks. Such a rule is specified in RSKIP252. This RSKIP proposes that transactions with gas prices that are 100 higher than the minimum gas price are forbidden. Let’s first assume that an average RSK block contains 300 simple RBTC transfer transactions and the attacker’s transaction is also a simple transfer. Then the rule proposed limits transaction bribes to only 1/3rd of the average block reward, which prevents fee sniping. A better strategy for the attacker is to create a transaction that consumes 100% of the block gas limit. In this case he can create a transaction with a bribe that is at most 100 times higher than the average block reward. Still, as we showed previously, RSK is currently protected from such bribes.
Summary
We presented four different strategies to do fee sniping in RSK: One Selfish Block (OSB), Two Selfish Blocks (TSB), Delay Bribe (DB) and Advance Bribe (AB). We showed that the Delay Bribe strategy is the best, even if this is counter-intuitive. We proved with simulations that none of them yields an increase in profit under realistic scenarios, which implies that RSK is secure from fee sniping.
Finally, we presented six changes to the RSK protocol that can provide even stronger security against fee sniping. Of all changes, only two of them are simple, provide other benefits and they have no apparent downsides. The first is the grandparent difficulty adjustment, which prevents manipulating the timestamp in short selfish forks. The second is the outlaw of high gas price transactions, which also prevents painful consequences when users set unnecessary high gas prices in a transaction by mistake.
The simulator code is available here.
