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

The email discusses the issue of interactivity constraints in payment pools and channel factories, particularly in relation to off-chain balances. The security of user funds is crucial, and any updates to off-chain balances require unanimous agreement from all users. If a user becomes offline or unresponsive, the updates must be halted, limiting payments to subsets of two users sharing a channel. Various proposed solutions to this problem include introducing a coordinator, partitioning or layering balances among off-chain users subsets. However, these solutions introduce the issue of equivocation of off-chain balances.To mitigate equivocation, one suggestion is to punish a cheating pre-nominated coordinator through an external fidelity bond. This approach could potentially remove the need for a coordinator by implementing trust-minimized and decentralized fraud proofs. However, the punishment for equivocation should compensate the defrauded counterparty for the loss of its off-chain balance. Since a cheating counterparty can equivocate against all other counterparties, the fidelity bond should be equal to (C - 1) * B satoshi amount, where C is the number of construction counterparties and B is the initial off-chain balance of the cheating counterparty.Additionally, it is challenging to determine ahead of time which counterparties will be "honest" or "dishonest" during a partition or transition. Therefore, every counterparty in the pool or factory must maintain a fidelity bond of size (C - 1) * B. However, this mitigation, along with other corrective measures, may not be economically practical for large-scale pools involving anonymous users.The author suggests that the most realistic solution to address the interactivity issue is to prevent off-chain group equivocation proactively. They propose editing the funding utxo of the pool or factory in an efficient manner to register new off-chain subgroups as needed. One existing idea, called CoinPool, involves including a user pubkey and balance amount to each leaf composing the Taproot tree while preserving the key-path spend in case of unanimity in the user group.The author introduces a new idea, potentially called "cut-through" spends, where multiple leaves are updated with a single witness composed interactively by the owners of the spent leaves. This spend aggregates the amounts and user pubkeys, sending them back to a new single leaf. The user leaves not participating in this "cut-through" maintain their integrity in the new version of the Taproot tree without requiring interactivity from their side.The author provides an example scenario involving a CoinPool funded by Alice, Bob, Caroll, Dave, and Eve. If Bob and Eve are offline, the remaining subset (ACD group) can compose a cut-through spend. This spend generates a new leaf aggregating the amounts and pubkeys of the ACD group. Bob's and Eve's leaves remain unmodified. The ACD group can confirm a transaction spending the pool funding utxo to a new single output committing to the scriptpubkey subgroup. The known Eltoo mechanism ensures no non-observable equivocation is possible within the ACD group.Once Bob and Eve come online, they can negotiate an on-chain pool "refresh" transaction using the conserved key-path spend to re-equilibrate the Taproot tree, prune out old subgroups, and provision future subgroups efficiently through signature aggregation. The author mentions proposed taproot tree update script primitives that offer flexibility for generating cut-through spends or batches of cut-throughs with multiple subgroups and outputs.The author believes that such a hypothetical primitive could also reduce the chain space consumed during mass pool withdrawals. This solution shifts the burden of predicting counterparties' liveliness onto individual users, allowing them to pre-commit fast Taproot tree traversals and compose new pool subgroups based on fluctuations in liveliness. Recursive taproot tree spends or more efficient accumulators than Merkle trees are potential ideas to reduce on-chain witness space consumed by pools in the average non-interactive case.In conclusion, the email presents a solution to the interactivity issue faced by payment pools and factories by preventing off-chain group equivocation. The proposed approach involves editing the funding utxo of the pool or factory efficiently, introducing the concept of cut-through spends to update multiple leaves with a single witness. This solution requires individual users to pre-commit fast Taproot tree traversals and allows them to compose new subgroups based on liveliness predictions.