The sender is exploring the identification process for LN anchor spends and Child Pays for Parent (CPFP) carve-out users, particularly focusing on the potential use of implicit signaling. They debate whether detecting two 330-sat outputs could serve as a reliable indicator for applying V3 rules, suggesting that pattern matching at the moment an anchor output is spent might be more effective than identifying it within the commit transaction alone.

The sender acknowledges the necessity to support CPFP carve-outs as extensively as possible, especially for applications that have not yet explicitly set nVersion=3. They propose that having two anchors should implicitly signal the need for CPFP carve-out, indicating that checking for two instances of 330-sat outputs could offer a cleaner solution. However, they also express concern over the possibility of a significant false positive rate, which would necessitate a more accurate template-matching approach.

Although the main objective is to ensure continuity of support for CPFP carve-outs, the sender seems open to discussing alternative methods of identifying such transactions. It's clear that whichever method is chosen must minimize the chance of mistakenly identifying non-anchor spends or other transactions as requiring CPFP carve-outs.