This can be accomplished by opting out of the option_anchors feature, which is associated with the previous script format. A significant topic of conversation has been the deployment strategy, which presents a timeline challenge that involves two critical steps. Firstly, updates are required for mempool/relay to facilitate the safe transition to version 3 (V3) style transactions, enabling LN implementations to adopt these changes. Secondly, before the deployment of the cluster mempool upgrade, LN implementations need to update since the current CPFP (Child Pays For Parent) carveout would not apply to cluster mempool.

To address this, a proposed strategy on the call considered implicitly transitioning commitment transactions reliant on CPFP carveout to a new system independent of the carveout. This shift prompts a potential revision in the project roadmap, starting with V3 deployment and two-cluster package RBF (Replace-By-Fee), followed by a 1p1c (one-parent-one-child) relay with some protection against orphan transactions. The next phase would involve "implicit signaling" of V3 by LN commitment transactions, specifically identifying those with two 330-sat outputs and considering additional specific criteria.

Further, there was a suggestion to allow a variation of the CPFP carveout, termed "1p2c cpfp carveout," whereby an additional child transaction with size limitations akin to normal V3 transactions could be permitted. This adjustment, along with two-cluster package RBF, would enhance the efficiency of package RBF against remote transactions while preventing the counter-party from pinning local commit transactions, provided the remote anchor is not spent.

Subsequent rollouts discussed include integrating the cluster mempool without inter-dependencies, improving orphan transaction handling, introducing ephemeral anchors, and updating the LN specification for zero-fee commit transactions. Ultimately, the plan also includes eliminating the 1p2c CPFP carveout, which is deemed non-disruptive to ongoing work and beneficial for removing critical paths from deployment. This elimination would further enable implementations to enhance their security through limited package RBF and allow spec updates to proceed independently for additional improvements.

Feedback is currently being solicited regarding the maximum size of V3 child transactions, as it involves balancing practical CPFP transaction sizes with the risk of potential pin vectors. Input from any wallet project on their expectations concerning this tradeoff would be highly valuable for determining the optimal child transaction size within the context of V3 rules.