Description

The btclightclient module in Babylon nodes relies on external reporters to update the latest Bitcoin block headers. If the Babylon network halts due to a panic or other critical issue, it will temporarily stop receiving updates from the Bitcoin network. When the network is restarted, the btclightclient module may still recognize the last Bitcoin block height from before the halt as the latest block.

Below is an example scenario.

1. Assume that before the Babylon network halts, the btclightclient module has recorded the latest Bitcoin block height as 1,000. Due to an unexpected issue, a panic occurs, causing all Babylon nodes to shut down.

2. While the Babylon network is halted, the Bitcoin network continues to grow, reaching block height 1,040. The Babylon team fixes the issue, releases a new node binary, and validators restart their nodes. However, upon restarting, the btclightclient module still considers 1,000 as the latest known Bitcoin block height, as it has not yet received updates from a trusted reporter.

3. A malicious mining pool that has mined a separate fork chain branch (e.g., 1,000 → 1,001 → 1,002 → ... → 1,020) submits its headers before an honest relayer provides the actual Bitcoin main chain headers. If the malicious reporter submits these forked headers first, the btclightclient module could temporarily recognize this separate branch as the main chain. If this malicious fork includes a staking transaction at an early block (e.g., at block 1,001), the inclusion proof verification might pass incorrectly, as the btclightclient module is temporarily working under the assumption that the malicious fork is the correct chain.

Impact

If Babylon nodes temporarily accept a malicious Bitcoin fork as the main chain, incorrect staking transactions could be processed, leading to unintended consequences in the Babylon staking system.

The attack does not require the malicious fork to outcompete the canonical Bitcoin chain in total difficulty — it only needs to be reported first after a Babylon chain restart.

Although the issue could be corrected once an honest reporter submits the actual Bitcoin main chain headers, any incorrect state updates made during this period could require manual intervention and social consensus to reverse.

Recommendations

If the Babylon chain remains halted while 10 blocks have passed on the Bitcoin network, implement a special upgrade handler that ensures Babylon nodes receive the latest Bitcoin headers before resuming normal operations after a chain halt. This handler should be applied in all cases where the Babylon chain has been halted beyond a minimal threshold, rather than only in prolonged halts.

Remediation

Babylon will implement an upgrade handler to insert missing headers in case of liveness loss. Also, on mainnet confirmation depth k will be set to 30 to tolerate larger liveness loss periods.