He explains why this approach is currently not feasible due to a vulnerability it would introduce. Specifically, he outlines a scenario where Alice opens a channel to Bob, who at that point does not have a main output in the commit transaction. As Alice sends HTLCs to Bob, and even after Bob sends back an update_fulfill_htlc and his commit_sig, there remains no main output for Bob in the commit transaction. If Alice then broadcasts her commit transaction without reciprocating with her commit_sig, Bob finds himself in a position where he must ensure the confirmation of Alice's commit transaction to claim the HTLCs before they time out.

Bastien further clarifies that Bob cannot rely on broadcasting his own commit transaction using the local anchor, as the fee rate would be identical to Alice's, rendering it ineffective in overtaking Alice's transaction in the event of a mempool race. The lack of package relay contributes to this issue, as it means that Alice's transaction is more likely to confirm first across all mempools.

The proposed alternative, which would involve reworking HTLCs to serve as anchors, was deemed overly complex and fraught with its own issues. Instead, Bastien expresses a preference to wait for the implementation of v3 transactions and package relay, which promises a resolution by moving to a single ephemeral anchor and thus rectifying the outlined problem. The explanation highlights the complexities involved in transaction handling and the need for further technological advancements to streamline these processes within the network.