Published on: 2023-09-26T15:36:26+00:00
In the email, ZmnSCPxj reaches out to Antoine to inquire about the suitability of using "OP_EVICT" for an unknown purpose. The email lacks contextual information but includes a link to a mailing list archive where Antoine can find more information.The email addresses the issue of interactivity constraints in payment pools and channel factories, specifically in relation to off-chain balances. It emphasizes the importance of ensuring the security of user funds and the need for unanimous agreement from all users when making updates to off-chain balances. In cases where a user becomes offline or unresponsive, updates must be halted, limiting payments to subsets of two users sharing a channel.Various proposed solutions to this problem are discussed, including introducing a coordinator, partitioning or layering balances among off-chain user subsets, and implementing trust-minimized and decentralized fraud proofs. However, these solutions introduce the issue of equivocation of off-chain balances.To mitigate equivocation, the author suggests punishing a cheating pre-nominated coordinator through an external fidelity bond. This approach aims to remove the need for a coordinator by implementing trust-minimized and decentralized fraud proofs. The punishment for equivocation should compensate the defrauded counterparty for the loss of its off-chain balance. 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.Determining ahead of time which counterparties will be "honest" or "dishonest" during a partition or transition is challenging. 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.An example scenario is provided 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. Proposed taproot tree update script primitives are mentioned 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 and introduces 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.
Updated on: 2023-09-28T01:55:10.749065+00:00