This change appears to potentially conflict with common usage scenarios anticipated for version 3, particularly in the context of Lightning Network (LN) channels. These scenarios include the need for fast confirmation of commitment transactions to settle pending Hash Time-Locked Contracts (HTLCs) swiftly and the scenario where eventual confirmation suffices, such as when a commitment transaction lacks pending HTLCs due to a counterparty's prolonged absence.

A key concern raised involves the flexibility to adjust confirmation urgency based on the transaction's context at the time of broadcast. The latter situation highlights the utility of package relay and Child Pays for Parent (CPFP) strategies to achieve an appropriate confirmation speed without overpaying fees, especially when the future mempool minimum fee is uncertain at the time a commitment transaction is signed. The requirement for V3 transactions to aim for a "top block" confirmation could force users into opting for faster, potentially more expensive confirmations even when they would prefer, or could afford, a slower confirmation pace. This could introduce inefficiencies and additional costs for users who do not require immediate block inclusion.