Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id ECD61C001A for ; Sun, 27 Feb 2022 02:00:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E930582F6F for ; Sun, 27 Feb 2022 02:00:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 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_FMBLA_NEWDOM=1.498, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 TcFDAI_EXST7 for ; Sun, 27 Feb 2022 02:00:48 +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 2506882F3D for ; Sun, 27 Feb 2022 02:00:48 +0000 (UTC) Date: Sun, 27 Feb 2022 02:00:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1645927245; bh=6PAQWKggUgMh0oBbz5lnAUNOXTUlTZMdy906YmRoQuU=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID; b=l9mZoOgL5BZiwK5RU2t1XUlfWQ94zANxqBNSs8cZ0H9E9wbZdTSsN1usVzBDRl4bB X62UqQYBY2SvWuNOohPC1zCPhLnD9FCaVCBaClqQD2iAqvFWaii+kRcTLFr/HuxwUh /zxqDZ80INsRvBC/Bc0agIMLZyAVdTqTa5peVaKIwoo9KfBpzeLz61r28RdOq9UMm+ aCT3moeiCRxIa0GS1rGRgf2u50qLdJXRRH2McI9gF8sxKKrtQldkniukqIpd2qa2ST qqDpoTfl1Rmqwor7Qa4PojSVO9+A7YFH757/qx/7kTnRYrQ4UUWnLIh21xMR71HdYQ iGMAsRPx8YE5g== To: Paul Sztorc , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com> References: <87leymuiu8.fsf@rustcorp.com.au> <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> <20220224065305.GB1965@erisian.com.au> <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT 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: Sun, 27 Feb 2022 02:00:49 -0000 Good morning Paul, > *** > > You have emphasized the following relation: "you have to show your transa= ction to everyone" =3D "thing doesn't scale". > > However, in LN, there is one transaction which you must, in fact, "show t= o everyone": your channel-opener. > > Amusingly, in the largeblock sidechain, there is not. You can onboard usi= ng only the blockspace of the SC. > (One "rich guy" can first shift 100k coins Main-to-Side, and he can hence= forth onboard many users over there. Those users can then onboard new users= , forever.) > > So it would seem to me, that you are on the ropes, even by your own crite= rion. [Footnote 1] > > *** > > Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new lay= er1 bytes. > > If so, a "rich man" could open a LN channel, and gradually transfer it to= new people. > > Such a technique would need to meet two requirements (or, so it seems to = me): > #1: The layer1 UTXO (that defines the channel) can never change (ie, the = 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-= they-were when the channel was opened). > #2: The new part-owners (who are getting coins from the rich man), will h= ave new pubkeys which are NOT known, until AFTER the channel is opened and = confirmed on the blockchain. > > Not sure how you would get both #1 and #2 at the same time. But I am not = up to date on the latest LN research. Yes, using channel factories. A channel factory is a N-of-N where N >=3D 3, and which uses the same offch= ain technology to host multiple 2-of-2 channels. We observe that, just as an offchain structure like a payment channel can h= ost HTLCs, any offchain structure can host a lot of *other* contracts, beca= use the offchain structure can always threaten to drop onchain to enforce a= ny onchain-enforceable contract. But an offchain structure is just another onchain contract! Thus, an offchain structure can host many other offchain structures, and th= us an N-of-N channel factory can host multiple 2-of-2 channel factories. (I know we discussed sidechains-within-sidechains before, or at least I men= tioned that to you in direct correspondence, this is basically that idea br= ought to its logical conclusion.) Thus, while you still have to give *one* transaction to all Bitcoin users, = that single transaction can back several channels, up to (N * (N - 1)) / 2. It is not quite matching your description --- the pubkeys of the peer parti= cipants need to be fixed beforehand. However, all it means is some additional pre-planning during setup with no = scope for dynamic membership. At least, you cannot dynamically change membership without onchain action. You *can* change membership sets by publishing a one-input-one-output trans= action onchain, but with Taproot, the new membership set is representable i= n a single 32-byte Taproot address onchain (admittedly, the transaction inp= ut is a txin and thus has overhead 32 bytes plus 1 byte for txout index, an= d you need 64 bytes signature for Taproot as well). The advantage is that, in the meantime, if membership set is not changed, p= ayments can occur *without* any data published on the blockchain (literally= 0 data). With sidechains, changing the ownership set requires that the sidechain pro= duce a block. That block requires a 32-byte commitment in the coinbase. What is more, if *any* transfers occur on the sidechain, they cannot be rea= l without a sidechain block, that has to be committed on the mainchain. Thus, while changing the membership set of a channel factory is more expens= ive (it requires a pointer to the previous txout, a 64-byte Taproot signatu= re, and a new Taproot address), continuous operation does not publish any d= ata at all. While in sidehchains, continuous operation and ordinary payments requires i= deally one commitment of 32 bytes per mainchain block. Continuous operation of the sidechain then implies a constant stream of 32-= byte commitments, whereas continuous operation of a channel factory, in the= absence of membership set changes, has 0 bytes per block being published. We assume that onboarding new members is much rarer than existing members a= ctually paying each other in an actual economy (after the first burst of on= boarding, new members will only arise in proportion to the birth rate, but = typical economic transactions occur much more often), so optimizing for the= continuous operation seems a better tradeoff. Channel factories have the nice properties: * N-of-N means that nobody can steal from you. * Even with a 51% miner, nobody can steal from you as long as none of the= N participants is the 51% miner, see the other thread. * Graceful degradation: even if if 1 of the N is offline, payments are done= over the hosted 2-of-2s, and the balance of probability is that most of th= e 2-of-2s have both participants online and payments can continue to occur. -- The reason why channel factories do not exist *yet* is that the main offcha= in construction we have, Poon-Dryja, is 2-of-2. We have Decker-Wattenhofer, which supports N >=3D 2, but it needs to publis= h a lot of onchain data in case of dispute, and has lousy UX due to how it = uses delays (you can only be safely offline for some small number of blocks= , but you have to wait out a large multiple of that parameter). We also have the newer Decker-Russell-Osuntokun ("eltoo"), but that require= s `SIGHASH_NOINPUT`, which is now today called `SIGHASH_ANYPREVOUT`. `OP_CTV` also is useful for publishing commitments-to-promised-outputs with= out having to publish outputs right now. This is why I want to focus on getting both on Bitcoin first, *before* any = recursive-contract-enabling technologies. Admittedly, the recursive-covenant-enabling constructs look like they enabl= e functionality equivalent to `SIGHASH_NOINPUT` and `OP_CTV`, though as I u= nderstand them, they would require more bytes than `SIGHASH_NOINPUT` or `OP= _CTV`. And scaling is really improved by reducing the number of bytes published, s= o there is value in merging in `SIGHASH_ANYPREVOUT` and `OP_CTV` at some po= int, so why not now. Regards, ZmnSCPxj