BUIP041 (BUIP038 Counter): Prevent Minority Hash Power From Injecting Very Large Blocks into the Blockchain
THE PROBLEM
BUIP038 outlines an attack where a minority of the hash power can, at low probability, temporarily overwhelm the excessive block (EB) parameter of network nodes by temporarily out-producing the mining majority for accept depth (AD) blocks. Once a node’s EB is exceeded, it allows subsequent excessive blocks on that chain without delay for a period of time. This is colloquially called the “sticky gate” feature. So if a minority hash power is able to overwhelm a majority of hash power, that majority no longer limits block size which BUIP038 claims allows the minority to then add blocks of “any size at all” onto the blockchain.
This is an interesting attack vector that is/can be defended against in several ways using the code today:
1. The AD can be increased, since the likelihood of a minority out-producing a majority over N blocks decreases exponentially as N increases
2. The huge block must still be propagated and validated by miners. BU theoretical and empirical studies of block propagation and “spy-mining” suggest that a huge block will either be orphaned or be followed by a sequence of empty blocks such that the average block size meets the network’s transaction throughput capacity.
BUIP038 proposes to revert the sticky gate feature to defeat this attack. However, reverting the feature does not solve the problem. An attacker could produce a huge block *as its first fork block* (and second, third, etc). If the attacker is then able to out-produce the mining majority for AD blocks, the mining majority will switch to the attacker’s chain. In other words, is unnecessary to wait for the “sticky gate” period to produce the huge block. The block can be produced at any time during the attacker’s attempt.
However, BUIP038 may reduce the number of huge blocks that can be produced, because there is no 144 block “sticky gate” period. But this is far from certain if the “majority” miners had different AD settings. In this case, the “majority” miners will not be working on the same fork. Instead they will each be working on a fork that starts at their own AD setting blocks from the tip. This may mean that the attacker’s hash power becomes the effective majority.
BUIP038 has an extremely detrimental effect on chain convergence. The intention of the “emergent consensus” algorithm is to allow nodes and miners to resist undesirable changes to the block size, but to accept the change if the hash power majority is mining it. But by passing BUIP038, a miner will never accept the block size change and converge on the chain tip. It will always attempt to fork to a lower block size, starting AD blocks behind the tip (a huge disadvantage). Simulations of both algorithms (see Appendix 1) with various split sizes show that a BUIP038 has significantly more orphans when blocks are consistently above one group’s EB. For example, 1000 runs of ~1800 blocks with a 66% vs 33% split shows a maximum and average of 13 and 2 orphans using the current algorithm. But if BUIP038 is passed, the maximum and average number of orphans is 642 and 278 over 1800 blocks. The actual number of orphans with BUIP038 is unbounded, since the chain never converges, meaning that 33% of the hash power is producing orphan blocks most of the time.
I do not believe that the BUIP038 behavior is acceptable to miners, since orphans and therefore financial losses are unbounded. Yes, miners could (and should) monitor their networks carefully and move their EB so as to not trail the chain tip if their EB gate is broken. But if this is the desired behavior, it is available today — a miner can set its AD=999999 (to effectively infinity), and remain on his chosen EB until it is manually moved. But if BUIP038 is passed, there is no way to create the opposite behavior — to accept the network’s choice and mine on the tip until the miner manually intervenes. In fact, a good strategy would be exactly this behavior: build smaller blocks from the chain tip. At least in this case, your blocks have a high chance of being part of the blockchain, limiting your financial loss, and your smaller blocks will reduce the network’s average block size (the network produces an average block size which is the hash power weighted average of the block size mined by each miner).
PROPOSED SOLUTION
To solve both the minority attack problem and keep chain’s convergence properties, the algorithm must be modified to increase the AD in proportion to how much a block exceeds the EB, compared to prior excessive blocks. But the initial excessive block should wait at least AD blocks. So a graph of the EAD is different based on whether this is the first excessive block or subsequent ones. If its the first, it looks like a wall with a staircase on top.
2*AD --|
--|
--|
--|
--|
AD |
|
|
|
|
0 EB 2*EB
Subsequent excessive blocks — that is, excessive blocks that are just a bit bigger than the first one — should not have the initial AD “wall”. If the initial “wall” existed every time a block was a bit bigger, a miner could force other miners into the “always trailing” behavior specified in BUIP038 by increasing the block size by 1 byte every time.
Let us define internal parameters, the “effective AD” (EAD), and “effective EB” (EEB).
First, we calculate the EEB:
if none of the last 144 blocks are marked excessive on this chain:
EEB = max(EB, largest block of the last 144 on this chain)
else:
EEB = max(EB, largest block marked excessive of the last 144 on this chain)
Now say that a block is generated of size S. If S <= EEB, this block is not excessive so return.
Otherwise the EAD is calculated as follows:
ADfraction = floor(AD*(S — EEB)/EB) # This calculates the “steps” in the graph. Its basically computing how much bigger the new block is in fractions of EB. And then waiting “accept depth” times that fraction.
if EEB == EB:
EAD = AD + ADfraction # Add the initial wall
else:
EAD = ADfraction
Then final excessive block determination:
if EAD == 0:
this block is not excessive.
if EAD > 0:
mark this block excessive,
and wait for EAD children before accepting it.
For example, in English, if the new block is 2 EB’s bigger than the last large block, then reject the chain until it is longer than 2*AD. This solves the problem of the network allowing huge blocks due to low AD settings. The bigger the block, the longer the node resists the chain.
If an attacker attempts to grow the block size slowly, other miners will periodically hit one of the “risers” in the step graph, and resist the chain for one block. During that period this miner may find a block, creating a competing chain of small blocks.
If there are 24 hours (144 blocks) of blocks smaller size than the last excessive block, none of them will be marked excessive, so the next block would cause a full wait of AD + ADfraction. I do not think it makes sense to “hiccup” every 24 hours, so the “if” statement in the EEB calculation handles this case (unmarked blocks must be smaller than or equal to a prior block that was marked excessive and your node waited for). This also handles the startup case. On startup, I do not think we want the AD to trigger for older blocks, especially since users who don’t care about the EB/AD settings will forget to set them. So on startup the last 144 blocks are examined, and the EEB is set to the largest prior block.
This algorithm is not consensus-critical. Other clients can create different algorithms to penalize very large blocks without breaking consensus.
Examples:
EB = 1MB
Now 2MB block comes in. This is the first excessive block, so EEB=EB. We wait AD blocks + AD*(2–1)/1 blocks. That is: 2*AD blocks. Subsequently EEB will be 2MB.
Now a 10MB block comes after the 2MB (do NOT skip 2*AD blocks when calculating the next "sticky" point). (10–2)/1 = 8, so we are now stuck on the 10MB block for 8*AD blocks. EEB=10MB
After the 10MB block, let’s say we hit an 11MB block. (11–10)/1 = 1, so we are now stuck on the 11MB block for 1*AD blocks. EEB=11MB
Next a 5 MB block comes in. This is less than the EEB so we accept it immediately.
Next, 143 small blocks pass and a 4MB block comes in. EEB is 5MB because there are no excessive-marked blocks, and the 5MB block is the largest. So the 4MB block is accepted immediately. If 145 blocks had passed, then the EEB would be EB and the 4MB block would be excessive.
APPENDIX 1:
(in the first reply)
THE PROBLEM
BUIP038 outlines an attack where a minority of the hash power can, at low probability, temporarily overwhelm the excessive block (EB) parameter of network nodes by temporarily out-producing the mining majority for accept depth (AD) blocks. Once a node’s EB is exceeded, it allows subsequent excessive blocks on that chain without delay for a period of time. This is colloquially called the “sticky gate” feature. So if a minority hash power is able to overwhelm a majority of hash power, that majority no longer limits block size which BUIP038 claims allows the minority to then add blocks of “any size at all” onto the blockchain.
This is an interesting attack vector that is/can be defended against in several ways using the code today:
1. The AD can be increased, since the likelihood of a minority out-producing a majority over N blocks decreases exponentially as N increases
2. The huge block must still be propagated and validated by miners. BU theoretical and empirical studies of block propagation and “spy-mining” suggest that a huge block will either be orphaned or be followed by a sequence of empty blocks such that the average block size meets the network’s transaction throughput capacity.
BUIP038 proposes to revert the sticky gate feature to defeat this attack. However, reverting the feature does not solve the problem. An attacker could produce a huge block *as its first fork block* (and second, third, etc). If the attacker is then able to out-produce the mining majority for AD blocks, the mining majority will switch to the attacker’s chain. In other words, is unnecessary to wait for the “sticky gate” period to produce the huge block. The block can be produced at any time during the attacker’s attempt.
However, BUIP038 may reduce the number of huge blocks that can be produced, because there is no 144 block “sticky gate” period. But this is far from certain if the “majority” miners had different AD settings. In this case, the “majority” miners will not be working on the same fork. Instead they will each be working on a fork that starts at their own AD setting blocks from the tip. This may mean that the attacker’s hash power becomes the effective majority.
BUIP038 has an extremely detrimental effect on chain convergence. The intention of the “emergent consensus” algorithm is to allow nodes and miners to resist undesirable changes to the block size, but to accept the change if the hash power majority is mining it. But by passing BUIP038, a miner will never accept the block size change and converge on the chain tip. It will always attempt to fork to a lower block size, starting AD blocks behind the tip (a huge disadvantage). Simulations of both algorithms (see Appendix 1) with various split sizes show that a BUIP038 has significantly more orphans when blocks are consistently above one group’s EB. For example, 1000 runs of ~1800 blocks with a 66% vs 33% split shows a maximum and average of 13 and 2 orphans using the current algorithm. But if BUIP038 is passed, the maximum and average number of orphans is 642 and 278 over 1800 blocks. The actual number of orphans with BUIP038 is unbounded, since the chain never converges, meaning that 33% of the hash power is producing orphan blocks most of the time.
I do not believe that the BUIP038 behavior is acceptable to miners, since orphans and therefore financial losses are unbounded. Yes, miners could (and should) monitor their networks carefully and move their EB so as to not trail the chain tip if their EB gate is broken. But if this is the desired behavior, it is available today — a miner can set its AD=999999 (to effectively infinity), and remain on his chosen EB until it is manually moved. But if BUIP038 is passed, there is no way to create the opposite behavior — to accept the network’s choice and mine on the tip until the miner manually intervenes. In fact, a good strategy would be exactly this behavior: build smaller blocks from the chain tip. At least in this case, your blocks have a high chance of being part of the blockchain, limiting your financial loss, and your smaller blocks will reduce the network’s average block size (the network produces an average block size which is the hash power weighted average of the block size mined by each miner).
PROPOSED SOLUTION
To solve both the minority attack problem and keep chain’s convergence properties, the algorithm must be modified to increase the AD in proportion to how much a block exceeds the EB, compared to prior excessive blocks. But the initial excessive block should wait at least AD blocks. So a graph of the EAD is different based on whether this is the first excessive block or subsequent ones. If its the first, it looks like a wall with a staircase on top.
2*AD --|
--|
--|
--|
--|
AD |
|
|
|
|
0 EB 2*EB
Subsequent excessive blocks — that is, excessive blocks that are just a bit bigger than the first one — should not have the initial AD “wall”. If the initial “wall” existed every time a block was a bit bigger, a miner could force other miners into the “always trailing” behavior specified in BUIP038 by increasing the block size by 1 byte every time.
Let us define internal parameters, the “effective AD” (EAD), and “effective EB” (EEB).
First, we calculate the EEB:
if none of the last 144 blocks are marked excessive on this chain:
EEB = max(EB, largest block of the last 144 on this chain)
else:
EEB = max(EB, largest block marked excessive of the last 144 on this chain)
Now say that a block is generated of size S. If S <= EEB, this block is not excessive so return.
Otherwise the EAD is calculated as follows:
ADfraction = floor(AD*(S — EEB)/EB) # This calculates the “steps” in the graph. Its basically computing how much bigger the new block is in fractions of EB. And then waiting “accept depth” times that fraction.
if EEB == EB:
EAD = AD + ADfraction # Add the initial wall
else:
EAD = ADfraction
Then final excessive block determination:
if EAD == 0:
this block is not excessive.
if EAD > 0:
mark this block excessive,
and wait for EAD children before accepting it.
For example, in English, if the new block is 2 EB’s bigger than the last large block, then reject the chain until it is longer than 2*AD. This solves the problem of the network allowing huge blocks due to low AD settings. The bigger the block, the longer the node resists the chain.
If an attacker attempts to grow the block size slowly, other miners will periodically hit one of the “risers” in the step graph, and resist the chain for one block. During that period this miner may find a block, creating a competing chain of small blocks.
If there are 24 hours (144 blocks) of blocks smaller size than the last excessive block, none of them will be marked excessive, so the next block would cause a full wait of AD + ADfraction. I do not think it makes sense to “hiccup” every 24 hours, so the “if” statement in the EEB calculation handles this case (unmarked blocks must be smaller than or equal to a prior block that was marked excessive and your node waited for). This also handles the startup case. On startup, I do not think we want the AD to trigger for older blocks, especially since users who don’t care about the EB/AD settings will forget to set them. So on startup the last 144 blocks are examined, and the EEB is set to the largest prior block.
This algorithm is not consensus-critical. Other clients can create different algorithms to penalize very large blocks without breaking consensus.
Examples:
EB = 1MB
Now 2MB block comes in. This is the first excessive block, so EEB=EB. We wait AD blocks + AD*(2–1)/1 blocks. That is: 2*AD blocks. Subsequently EEB will be 2MB.
Now a 10MB block comes after the 2MB (do NOT skip 2*AD blocks when calculating the next "sticky" point). (10–2)/1 = 8, so we are now stuck on the 10MB block for 8*AD blocks. EEB=10MB
After the 10MB block, let’s say we hit an 11MB block. (11–10)/1 = 1, so we are now stuck on the 11MB block for 1*AD blocks. EEB=11MB
Next a 5 MB block comes in. This is less than the EEB so we accept it immediately.
Next, 143 small blocks pass and a 4MB block comes in. EEB is 5MB because there are no excessive-marked blocks, and the 5MB block is the largest. So the 4MB block is accepted immediately. If 145 blocks had passed, then the EEB would be EB and the 4MB block would be excessive.
APPENDIX 1:
(in the first reply)
