{"type":"rich","version":"1.0","title":"Antoine Riard [ARCHIVE] wrote","author_name":"Antoine Riard [ARCHIVE] (npub1vj…4x8dd)","author_url":"https://yabu.me/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-09-25\n🗒️ Summary of this message: Payment pools and channel factories face limitations in interactivity, affecting the security of user funds. Proposed solutions include introducing a coordinator or partitioning balances, but these may not be economically practical. A potential solution is to prevent off-chain group equivocation by editing the funding utxo in a way that allows for the registration of new off-chain subgroups. CoinPool's idea of including user pubkeys and balance amounts in Taproot leaves could be utilized for privacy-preserving payments and contracts.\n📝 Original message:\nPayment pools and channel factories are afflicted by severe interactivity\nconstraints worsening with the number of users owning an off-chain balance\nin the construction. The security of user funds is paramount on the ability\nto withdraw unilaterally from the off-chain construction. As such any\nupdate applied to the off-chain balances requires a signature contribution\nfrom the unanimity of the construction users to ensure this ability is\nconserved along updates.\n\nAs soon as one user starts to be offline or irresponsive, the updates of\nthe off-chain balances must have to be halted and payments progress are\nlimited among subsets of 2 users sharing a channel. Different people have\nproposed solutions to this issue: introducing a coordinator, partitioning\nor layering balances in off-chain users subsets. I think all those\nsolutions have circled around a novel issue introduced, namely equivocation\nof off-chain balances at the harm of construction counterparties [0].\n\nAs ZmnSCPxj pointed out recently, one way to mitigate this equivocation\nconsists in punishing the cheating pre-nominated coordinator on an external\nfidelity bond. One can even imagine more trust-mimized and decentralized\nfraud proofs to implement this mitigation, removing the need of a\ncoordinator [1].\n\nHowever, I believe punishment equivocation to be game-theory sound should\ncompensate a defrauded counterparty of the integrity of its lost off-chain\nbalance. As one cheating counterparty can equivocate in the worst-case\nagainst all the other counterparties in the construction, one fidelity bond\nshould be equal to ( C - 1 ) * B satoshi amount, where C is the number of\nconstruction counterparty and B the initial off-chain balance of the\ncheating counterparty.\n\nMoreover, I guess it is impossible to know ahead of a partition or\ntransition who will be the \"honest\" counterparties from the \"dishonest\"\nones, therefore this ( C - 1 ) * B-sized fidelity bond must be maintained\nby every counterparty in the pool or factory. On this ground, I think this\nmitigation and other corrective ones are not economically practical for\nlarge-scale pools among a set of anonymous users.\n\nI think the best solution to solve the interactivity issue which is\nrealistic to design is one ruling out off-chain group equivocation in a\nprophylactic fashion. The pool or factory funding utxo should be edited in\nan efficient way to register new off-chain subgroups, as lack of\ninteractivity from a subset of counterparties demands it.\n\nWith CoinPool, there is already this idea of including a user pubkey and\nbalance amount to each leaf composing the Taproot tree while preserving the\nkey-path spend in case of unanimity in the user group. Taproot leaves can\nbe effectively regarded as off-chain user accounts available to realize\nprivacy-preserving payments and contracts.\n\nI think one (new ?) idea can be to introduce taproot leaves \"cut-through\"\nspends where multiple leaves are updated with a single witness,\ninteractively composed by the owners of the spent leaves. This spend sends\nback the leaves amount to a new single leaf, aggregating the amounts and\nuser pubkeys. The user leaves not participating in this \"cut-through\" are\ninherited with full integrity in the new version of the Taproot tree, at\nthe gain of no interactivity from their side.\n\nLet's say you have a CoinPool funded and initially set with Alice, Bob,\nCaroll, Dave and Eve. Each pool participant has a leaf L.x committing to an\namount A.x and user pubkey P.x, where x is the user name owning a leaf.\n\nBob and Eve are deemed to be offline by the Alice, Caroll and Dave subset\n(the ACD group).\n\nThe ACD group composes a cut-through spend of L.a + L.c + L.d. This spends\ngenerates a new leaf L.(acd) leaf committing to amount A.(acd) and P.(acd).\n\nAmount A.(acd) = A.a + A.c + A.d and pubkey P.(acd) = P.a + P.c + P.d.\n\nBob's leaf L.b and Eve's leaf L.e are left unmodified.\n\nThe ACD group generates a new Taproot tree T' = L.(acd) + L.b + L.e, where\nthe key-path K spend including the original unanimity of pool\ncounterparties is left unmodified.\n\nThe ACD group can confirm a transaction spending the pool funding utxo to a\nnew single output committing to the scriptpubkey K + T'.\n\n\u003eFrom then, the ACD group can pursue off-chain balance updates among the\nsubgroup thanks to the new P.(acd) and relying on the known Eltoo\nmechanism. There is no possibility for any member of the ACD group to\nequivocate with Bob or Eve in a non-observable fashion.\n\nOnce Bob and Eve are online and ready to negotiate an on-chain pool\n\"refresh\" transaction, the conserved key-path spend can be used to\nre-equilibrate the Taproot tree, prune out old subgroups unlikely to be\nused and provision future subgroups, all with a compact spend based on\nsignature aggregation.\n\nFew new Taproot tree update script primitives have been proposed, e.g [2].\nThough I think none with the level of flexibility offered to generate\nleaves cut-through spends, or even batch of \"cut-through\" where M subgroups\nare willing to spend N leaves to compose P new subgroups fan-out in Q new\noutputs, with showing a single on-chain witness. I believe such a\nhypothetical primitive can also reduce the chain space consumed in the\noccurrence of naive mass pool withdraws at the same time.\n\nI think this solution to the high-interactivity issue of payment pools and\nfactories shifts the burden on each individual user to pre-commit fast\nTaproot tree traversals, allowing them to compose new pool subgroups as\nfluctuations in pool users' level of liveliness demand it. Pool efficiency\nbecomes the sum of the quality of user prediction on its counterparties'\nliveliness during the construction lifetime. Recursive taproot tree spends\nor more efficient accumulator than merkle tree sounds ideas to lower the\non-chain witness space consumed by every pool in the average\nnon-interactive case.\n\nCheers,\nAntoine\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020370.html\n[1]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004043.html\n[2]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019420.html\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230925/77e3936d/attachment.html\u003e"}