Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id BBB9AC002D for ; Tue, 10 May 2022 16:45:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9D1CD82B81 for ; Tue, 10 May 2022 16:45:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 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, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mzgHxKFqJKc for ; Tue, 10 May 2022 16:45:27 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by smtp1.osuosl.org (Postfix) with ESMTPS id E4B7182B49 for ; Tue, 10 May 2022 16:45:26 +0000 (UTC) Date: Tue, 10 May 2022 16:45:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1652201124; bh=veubUEcOmEYkCNNmdbp9+BGjf6bEokWEFeRSkTFqX9Y=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=L2roGEEOhO1rFCHrCDC8x5KQAeEtez96ws+VDmhUYc3HpJmpvVqB5yaf0Z/Orml66 IOT9nuQoh/Mx7FX5pVjIX54Dn65WE1MRMqS/Xmgmm7G65SQTYEoQFoi3Eqd2/Cf3Gk P2FKnoBq53bDJPx9Etl/tlAP+bMRWjdiPUMEXc81l9EWqKuQh4Sk81a2HntvtFH+fH J8xK6qNGucZxWaRuGMKGvPpMXWlcwyHWYotcmIzQ1Gk4ZlWfv5HXFY4EdDrNfw9C1A 6uapLAsSYpuRWh4+eUyqHeXOX7QcQtFlIpyLNz1vJ8lBDqRTEBmhxfLrOdobzJ5v85 CvrffRAtRCdpw== To: Billy Tetrud , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: 2872618:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories 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, 10 May 2022 16:45:27 -0000 Good morning Billy, > Very interesting exploration. I think you're right that there are issues = with the kind of partitioning you're talking about. Lightning works because= all participants sign all=C2=A0offchain states (barring data loss). If a p= articipant can be excluded from needing to agree to a new state, there must= be an additional mechanism to ensure the relevant state for that participa= nt isn't changed to their detriment.=C2=A0 > > To summarize my below email, the two techniques I can think for solving t= his problem are: > > A. Create sub-pools when the whole group is live that can be used by the = sub- pool=C2=A0participants later without the whole group's involvement. Th= e whole group is needed to change the whole group's state (eg close or open= sub-pools), but sub-pool=C2=A0states don't need to involve the whole group= . Is this not just basically channel factories? To reduce the disruption if any one pool participant is down, have each sub= -pool have only 2 participants each. More participants means that the probability that one of them is offline is= higher, so you use the minimum number of participants in the sub-pool: 2. This makes any arbitrary sub-pool more likely to be usable. But a 2-participant pool is a channel. So a large multiparticipant pool with sub-pools is just a channel factory f= or a bunch of channels. I like this idea because it has good tradeoffs, so channel factories ho. Regards, ZmnSCPxj