Usage of longest-chain instead of most-work

[gregdhill]

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.

[nakul1010]

@gregdhill Thanks for the references few questions

• I am expected to extend this if condition
  • &&( get_chainwork(current_fork.max_height) >= get_chainwork(prev_chain.max_height))
• Regarding the target var in electrum is same as in bitcoin types here right ?

[gregdhill]

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.