The issue involved the way bitcoind selects peers for relaying compact blocks, whereby an attacker could manipulate a victim's peer selection by providing blocks faster than honest nodes through a function named PeerManagerImpl::MaybeSetPeerAsAnnouncingHeaderAndIDs. The mapBlocksInFlight mechanism within bitcoind, which allows a node around 10 minutes to respond with a requested block, was integral to this exploit. The potential for an attacker to add numerous connections during the setup phase could also undermine the peer eviction process through AttemptToEvictConnection.

The attack methodology included several steps, starting with the attacker replacing the victim's compact block connections and establishing numerous additional connections to the victim node. By ensuring these malicious connections were sequential in the connection manager's vector, the attacker could delay block relay by competing with legitimate announcements and strategically disconnecting or sending invalid blocks just before timeouts were reached. This would systematically trigger the next controlled connection to be chosen to relay the block, thereby causing substantial delays.

These delays could have serious implications for the Lightning Network (LN), particularly when considering channels with specified CLTV delta times for Hash Time-Locked Contracts (HTLCs). The described attack could allow malicious LN nodes to force close transactions and claim HTLCs by delaying block delivery to intermediate nodes, potentially leading to the theft of the value of an HTLC.

The issue has since been addressed with two pull requests that were integrated into the Bitcoin Core v22.0 release. One of the patches PR#22144 introduced randomization to message processing order, ensuring that at least one honest peer remains between malicious ones. Another patch PR#22147 prevented the demotion of the last outbound high-bandwidth compact-block relaying peer by an inbound attacker. These improvements are significant for enhancing the robustness of the network against such attacks, although it remains crucial for node operators, especially those running lightning nodes, to update to more secure versions of the software to mitigate risks.