The attack can be performed by either side of the closure, as the HTLCs (Hash Time Locked Contracts) are now only signed with SIGHASH_SINGLE|ANYONECANPAY, allowing for more inputs to be added and the attack to be carried out even by the broadcaster.

The author acknowledges that it may not be feasible to revert this change to address the issue, as it has fixed other problems with channel usability and important edge cases. Instead, they argue that the responsibility for fixing this issue lies with Bitcoin Core or other parts of the mining stack, as it involves transaction broadcast ordering and miners not including the optimal set of transactions for fee revenue.

Fixing this in the Bitcoin Core stack would be challenging, as it would require unbounded memory to keep enough history. However, the author proposes the possibility of using external software to monitor the mempool for replaced transactions that may re-enter the mempool later with other replacements. This software could optimize block template selection revenue while unintentionally resolving this issue.

Overall, the email raises concerns about the vulnerability of anchor channels to this attack and suggests that the solution should ultimately come from the Bitcoin Core or mining stack, rather than attempting to fix it solely on the Lightning Network end.