Solving CoinPool high-interactivity issue with cut-through update of Taproot leaves

Antoine discusses the concept of OP_EVICT in the context of an off-chain payment pool. He mentions that OP_EVICT requires participant cooperation after the state update to allow a single participant to withdraw their funds. However, he believes that this approach is unsafe if they retain the security requirement that a participant should have the unilateral means to enforce the latest agreed-upon state at any time during the construction lifetime.Antoine expresses his wish for CoinPool to have a level of covenant flexibility and mentions TLUV or MERKLESUB as possible solutions. He also highlights that OP_EVICT introduces the idea of subgroup novation (K-of-N) of a PT2R scriptpubkey. However, he points out that there is currently no sound covenant proposal that combines TLUV and EVICT-like semantics in a consistent set of Script primitives to enable "cut-through" updates while still retaining the key property of unilateral withdrawal of promised balances in any order.Antoine expresses his interest in understanding if on-chain "cut-through" is the best direction to solve the fundamental high interactivity issue of channel factory and payment pool over punishment-based ideas. He mentions that he might work on crafting a proposal in the future but for now, he seeks a better understanding of the topic.Overall, Antoine's email discusses the concept of OP_EVICT in the context of an off-chain payment pool, raises concerns about its safety and proposes alternative solutions such as TLUV or MERKLESUB. He also questions the best direction to address the high interactivity issue of channel factory and payment pool.