You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The BTCRelay incorrectly sets the main chain as the longest fork instead of that which has the most work. This means that an attacker with significant mining power could mine a chain with an invalid timestamp to lower the difficulty after each readjustment period. It is currently not economically feasible to exploit due to the required mining requirements.
Expected behavior
We should only reorg when the fork has more work than the current main chain, see how electrum does that here.
Additional context
The summa relay here only checks the chain work when reorging but it does not support reorgs over 2017 blocks.
The text was updated successfully, but these errors were encountered:
Yes we need to extend that condition and we should also update ensure_no_ongoing_fork. I can't see which target type you are linking to in electrum, but I am assuming it is the same.
Describe the bug
The BTCRelay incorrectly sets the main chain as the longest fork instead of that which has the most work. This means that an attacker with significant mining power could mine a chain with an invalid timestamp to lower the difficulty after each readjustment period. It is currently not economically feasible to exploit due to the required mining requirements.
Expected behavior
We should only reorg when the fork has more work than the current main chain, see how electrum does that here.
Additional context
The summa relay here only checks the chain work when reorging but it does not support reorgs over 2017 blocks.
The text was updated successfully, but these errors were encountered: