The sender originally misunderstood the situation, thinking that it would be impossible to continue supporting CPFP carve-out alongside new cluster mempool code, leading to an assumption that lightning commitment transactions with two anchor outputs should implicitly enroll in v3 policies as a replacement for the CPFP carve-out.

However, the core concern expressed is not strictly about how to identify a Lightning Network (LN) anchor spend but rather how to enable the identification of CPFP carve-out users effectively. The aim is to keep supporting the CPFP carve-out for applications that do not explicitly set nVersion=3. This suggests that there remains a possibility of supporting both mechanisms concurrently or finding a pathway to transition without disrupting current users heavily reliant on the CPFP carve-out feature, particularly those within the Lightning Network. The conversation indicates a need for a careful evaluation of the technical paths available to ensure sustained functionality for affected applications and users.