Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 41966C0032 for ; Tue, 3 Oct 2023 11:24:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0BBEE61039 for ; Tue, 3 Oct 2023 11:24:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0BBEE61039 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=GgNdcLgU X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F79MlZVCiQEm for ; Tue, 3 Oct 2023 11:24:33 +0000 (UTC) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by smtp3.osuosl.org (Postfix) with ESMTPS id A375460C06 for ; Tue, 3 Oct 2023 11:24:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A375460C06 Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-d86a0c97ae6so877531276.2 for ; Tue, 03 Oct 2023 04:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696332272; x=1696937072; darn=lists.linuxfoundation.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2CZwaxS/jqQRKIglzF97AMF+2t9bR7pDXAkgBqw8fIg=; b=GgNdcLgUAyLxfDCsBswe3mgrtZe/LPFG0p8lrvSZ0CRiRauPa2ZVwUZ3VyzwGwfxCp 2rjpMWmr8B02A4HQWmMly7gwNYf9/9DCdI43Peq3qWoccvQM+OhLzZxbS1oRiJgD68ME kLgmBLbL/KNFBJAZnX1wMNfvb2ggUvOJhZjwYeQB6hka0QVu9sbyQcFf86kNvueTcHkb +4kB8lc0ZxW9aiERrzDV8qVnt7ylMdnEixpkqUgJkyiRUBLJIohIiTlb+oQovCJSiJru vEedaiyKb9Y0Gp3O+pXfLbDlEk25Jgl1uOeiNiSR0vwHPRleHETsGbu/r3N7Uqj0dTBV rXyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696332272; x=1696937072; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2CZwaxS/jqQRKIglzF97AMF+2t9bR7pDXAkgBqw8fIg=; b=itQsiCAjeazH2f/fmmwDeFzEbTsbITEwkQuw3TG9ihaetj5YrZ1ZMow43JNDfYlY03 oRpO8gJuCcflUoKIrjF78v/Ia937Dq1eq4UtaG858jAagxjJQ6RInrw31DNadOXHlMSq LytqUIh+6mJnQQYvEJ0emCxBawq+eK5bvgcap9lXzZRyRXmVbpXbyZ08NZcvxU6ptMuZ Uv10jEORhQ+VWcERE1BvWNOuTH+YAIrnHNgeU9yfYKO1mPVWsedYEJD+LtTgfi+yMFVO jWvJ49Ax3niHnxQtyXHZCcrSmzQH4vi7uAkIIQcID1qx9EY1T/KZnOYlXElBhzaZ+MLE Lx7g== X-Gm-Message-State: AOJu0YxWe7eLjZIrfN4hwaV6zJ2CIOSegoQROIgosZNjO4r1fXJd8Xyp KdoCmEZib0mUF9byPalVvoCJkyeEPdrPDUoPgxQ= X-Google-Smtp-Source: AGHT+IE53E4hK0lxFdFdvT2LywjYFVKaWtbxp/4d9gQy3IJ0OuXQlHIXb4LJronkH0u2hTFaqszeQ4lVh5XcZZb2OEA= X-Received: by 2002:a25:cc8c:0:b0:d81:cdda:729c with SMTP id l134-20020a25cc8c000000b00d81cdda729cmr14066077ybf.23.1696332272259; Tue, 03 Oct 2023 04:24:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= Date: Tue, 3 Oct 2023 13:24:20 +0200 Message-ID: To: Antoine Riard , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 03 Oct 2023 23:32:14 +0000 Subject: Re: [bitcoin-dev] Solving CoinPool high-interactivity issue with cut-through update of Taproot leaves X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2023 11:24:35 -0000 Hi, Antoine. It sounds like perhaps OP_CHECKCONTRACTVERIFY can achieve what you are looking for: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-M= ay/021719.html By committing the participants' pubkeys and balances in the dynamic data instead of the taptree one can imagine a subset of online users agreeing to pool their aggregated balances in a new output, while the offline users' funds would remain inaccessible by them in a second output. The way this would work is by spending the coinpool utxo with a transaction having two outputs: one output that is the "remainder" of the previous coinpool (the offline users), and the second output the new coinpool among the online users*. When the offline users are back online, they could all agree to continue using the original coinpool utxo. * assuming Eltoo in case an offline user comes back online and double spends the UTXO. - Johan On Wed, Sep 27, 2023 at 12:08=E2=80=AFPM Antoine Riard via bitcoin-dev wrote: > > Hi Zeeman, > > See my comments at the time of OP_EVICT original publication. > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019= 939.html > > "I think in the context of (off-chain) payment pool, OP_EVICT requires > participant cooperation *after* the state update to allow a single > participant to withdraw her funds. > > I believe this is unsafe if we retain as an off-chain construction securi= ty > requirement that a participant should have the unilateral means to enforc= e > the latest agreed upon state at any time during the construction lifetime= ". > > I think this level of covenant flexibility is still wished for CoinPool a= s a fundamental property, and this is offered by TLUV or MERKLESUB. > On the other hand, I think OP_EVICT introduces this idea of *subgroup nov= ation* (i.e `K-of-N`) of a PT2R scriptpubkey. > > To the best of my understanding, I think there is not yet any sound coven= ant proposal aiming to combine TLUV and EVICT-like semantics in a consisten= t set of Script primitives to enable "cut-through" updates, while still ret= aining the key property of unilateral withdraw of promised balances in any-= order. > > I might go to work on crafting one, though for now I'm still interested t= o understand better if on-chain "cut-through" is the best direction to solv= e the fundamental high interactivity issue of channel factory and payment p= ool over punishment-based ideas. > > Best, > Antoine > > Le mar. 26 sept. 2023 =C3=A0 07:51, ZmnSCPxj a = =C3=A9crit : >> >> Good morning Antoine, >> >> Does `OP_EVICT` not fit? >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/01= 9926.html >> >> Regards, >> ZmnSCPxj >> >> >> Sent with Proton Mail secure email. >> >> ------- Original Message ------- >> On Monday, September 25th, 2023 at 6:18 PM, Antoine Riard via bitcoin-de= v wrote: >> >> >> > Payment pools and channel factories are afflicted by severe interactiv= ity constraints worsening with the number of users owning an off-chain bala= nce in the construction. The security of user funds is paramount on the abi= lity to withdraw unilaterally from the off-chain construction. As such any = update applied to the off-chain balances requires a signature contribution = from the unanimity of the construction users to ensure this ability is cons= erved along updates. >> > As soon as one user starts to be offline or irresponsive, the updates = of the off-chain balances must have to be halted and payments progress are = limited among subsets of 2 users sharing a channel. Different people have p= roposed solutions to this issue: introducing a coordinator, partitioning or= layering balances in off-chain users subsets. I think all those solutions = have circled around a novel issue introduced, namely equivocation of off-ch= ain balances at the harm of construction counterparties [0]. >> > >> > As ZmnSCPxj pointed out recently, one way to mitigate this equivocatio= n consists in punishing the cheating pre-nominated coordinator on an extern= al fidelity bond. One can even imagine more trust-mimized and decentralized= fraud proofs to implement this mitigation, removing the need of a coordina= tor [1]. >> > >> > However, I believe punishment equivocation to be game-theory sound sho= uld compensate a defrauded counterparty of the integrity of its lost off-ch= ain balance. As one cheating counterparty can equivocate in the worst-case = against all the other counterparties in the construction, one fidelity bond= should be equal to ( C - 1 ) * B satoshi amount, where C is the number of = construction counterparty and B the initial off-chain balance of the cheati= ng counterparty. >> > >> > Moreover, I guess it is impossible to know ahead of a partition or tra= nsition who will be the "honest" counterparties from the "dishonest" ones, = therefore this ( C - 1 ) * B-sized fidelity bond must be maintained by ever= y counterparty in the pool or factory. On this ground, I think this mitigat= ion and other corrective ones are not economically practical for large-scal= e pools among a set of anonymous users. >> > >> > I think the best solution to solve the interactivity issue which is re= alistic to design is one ruling out off-chain group equivocation in a proph= ylactic fashion. The pool or factory funding utxo should be edited in an ef= ficient way to register new off-chain subgroups, as lack of interactivity f= rom a subset of counterparties demands it. >> > >> > With CoinPool, there is already this idea of including a user pubkey a= nd balance amount to each leaf composing the Taproot tree while preserving = the key-path spend in case of unanimity in the user group. Taproot leaves c= an be effectively regarded as off-chain user accounts available to realize = privacy-preserving payments and contracts. >> > >> > I think one (new ?) idea can be to introduce taproot leaves "cut-throu= gh" spends where multiple leaves are updated with a single witness, interac= tively composed by the owners of the spent leaves. This spend sends back th= e leaves amount to a new single leaf, aggregating the amounts and user pubk= eys. The user leaves not participating in this "cut-through" are inherited = with full integrity in the new version of the Taproot tree, at the gain of = no interactivity from their side. >> > >> > Let's say you have a CoinPool funded and initially set with Alice, Bob= , Caroll, Dave and Eve. Each pool participant has a leaf L.x committing to = an amount A.x and user pubkey P.x, where x is the user name owning a leaf. >> > >> > Bob and Eve are deemed to be offline by the Alice, Caroll and Dave sub= set (the ACD group). >> > >> > The ACD group composes a cut-through spend of L.a + L.c + L.d. This sp= ends generates a new leaf L.(acd) leaf committing to amount A.(acd) and P.(= acd). >> > >> > Amount A.(acd) =3D A.a + A.c + A.d and pubkey P.(acd) =3D P.a + P.c + = P.d. >> > >> > Bob's leaf L.b and Eve's leaf L.e are left unmodified. >> > >> > The ACD group generates a new Taproot tree T' =3D L.(acd) + L.b + L.e,= where the key-path K spend including the original unanimity of pool counte= rparties is left unmodified. >> > >> > The ACD group can confirm a transaction spending the pool funding utxo= to a new single output committing to the scriptpubkey K + T'. >> > >> > From then, the ACD group can pursue off-chain balance updates among th= e subgroup thanks to the new P.(acd) and relying on the known Eltoo mechani= sm. There is no possibility for any member of the ACD group to equivocate w= ith Bob or Eve in a non-observable fashion. >> > >> > Once Bob and Eve are online and ready to negotiate an on-chain pool "r= efresh" transaction, the conserved key-path spend can be used to re-equilib= rate the Taproot tree, prune out old subgroups unlikely to be used and prov= ision future subgroups, all with a compact spend based on signature aggrega= tion. >> > >> > Few new Taproot tree update script primitives have been proposed, e.g = [2]. Though I think none with the level of flexibility offered to generate = leaves cut-through spends, or even batch of "cut-through" where M subgroups= are willing to spend N leaves to compose P new subgroups fan-out in Q new = outputs, with showing a single on-chain witness. I believe such a hypotheti= cal primitive can also reduce the chain space consumed in the occurrence of= naive mass pool withdraws at the same time. >> > >> > I think this solution to the high-interactivity issue of payment pools= and factories shifts the burden on each individual user to pre-commit fast= Taproot tree traversals, allowing them to compose new pool subgroups as fl= uctuations in pool users' level of liveliness demand it. Pool efficiency be= comes the sum of the quality of user prediction on its counterparties' live= liness during the construction lifetime. Recursive taproot tree spends or m= ore efficient accumulator than merkle tree sounds ideas to lower the on-cha= in witness space consumed by every pool in the average non-interactive case= . >> > >> > Cheers, >> > Antoine >> > >> > [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April= /020370.html >> > [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-Aug= ust/004043.html >> > [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Septe= mber/019420.html > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev