The proposal questions the current approach of pattern matching to detect v3 rules when a commit transaction is seen. It suggests an alternative where the rules would apply upon the spending of an anchor output identified by a unique script matching a 330 sat output. This method benefits from precise pattern matching at the point of spending but raises concerns regarding current LN implementations that batch multiple anchor outputs in one transaction. Such batching might be rejected by updated nodes following new rules, thus requiring these implementations to disable batching to avoid negative repercussions.

The practice of batching itself is considered risky, and while some implementations like eclair have avoided it due to security concerns, others like lnd may face issues if this change is implemented. Further input on this matter would be beneficial, especially from those involved with lnd, such as @roasbeef.

Additionally, there's an open question about determining the maximal child size for V3 transactions. This is closely tied to the maximum size of commitment transactions allowed. For example, large commitment transactions could necessitate substantial fees, leading to the need for larger or multiple wallet inputs. Conversely, limiting the size of commitment transactions, as done by eclair which limits them to 30 HTLCs in both directions, reduces the necessary amounts and simplifies UTXO management. Ultimately, lightning nodes are expected to maintain a well-managed UTXO pool to minimize costs, so defining a "reasonable" maximum child size is suggested, leaving it to individual LN implementations to ensure their wallets can accommodate the parameters. The current values under consideration are seen as reasonable starting points.