From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 87172C000B for ; Fri, 4 Mar 2022 13:43:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 62D6740305 for ; Fri, 4 Mar 2022 13:43:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6sSZaD5vOSF for ; Fri, 4 Mar 2022 13:43:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo107.poczta.onet.pl (smtpo107.poczta.onet.pl [213.180.149.160]) by smtp4.osuosl.org (Postfix) with ESMTPS id 5D9A1402F9 for ; Fri, 4 Mar 2022 13:43:48 +0000 (UTC) Received: from pmq4v.m5r2.onet (pmq4v.m5r2.onet [10.174.32.70]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4K98Fm2mM5z1srH; Fri, 4 Mar 2022 14:43:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1646401420; bh=colgvHZLh4m2D9Ayw5ysVmIq65tSI0vgQGD4ZSrQuns=; h=From:Cc:To:In-Reply-To:Date:Subject:From; b=CzkbvAwRkcg7Wovya0ujpUD/CUB3Ipt1amp2jlih9AbfEplksPtzdS0UL10nVnxfk 0hG/GqHmGwgNj/yNFmgsQq2IVeAxts8D5FzBvjil9Tc63dVQhF59DMquhqU1lLjbvh G4IiT+PjB2Oe1C2rD7j/8srSUODBDb7P0g7B/O3k= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [82.177.167.2] by pmq4v.m5r2.onet via HTTP id ; Fri, 04 Mar 2022 14:43:40 +0100 From: vjudeu@gazeta.pl X-Priority: 3 To: ZmnSCPxj In-Reply-To: Date: Fri, 04 Mar 2022 14:43:40 +0100 Message-Id: <158184081-a1d5b424942fc47a0a6665ca7ba04258@pmq4v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;3 X-Mailman-Approved-At: Fri, 04 Mar 2022 15:19:57 +0000 Cc: Bitcoin Protocol Discussion 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: Fri, 04 Mar 2022 13:43:49 -0000 > The Taproot address itself has to take up 32 bytes onchain, so this saves= nothing. There is always at least one address, because you have a coinbase transacti= on and a solo miner or mining pool that is getting the whole reward. So, in= stead of using separate OP_RETURN's for each sidechain, for each federation= , and for every "commitment to the blockchain", all we need is just tweakin= g that miner's key and placing everything inside unused TapScript. Then, we= don't need separate 32 bytes for this and separate 32 bytes for that, we o= nly need a commitment and a MAST-based path that can link such commitment t= o the address of this miner. So, instead of having: ... We could have: On 2022-03-04 09:42:23 user ZmnSCPxj wrote: > Good morning vjudeu, > > 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 publish= ed. > > The sidechain can push zero bytes on-chain, just by placing a sidechain h= ash in OP_RETURN inside TapScript. Then, every sidechain node can check tha= t "this sidechain hash is connected with this Taproot address", without pus= hing 32 bytes on-chain. The Taproot address itself has to take up 32 bytes onchain, so this saves n= othing. Regards, ZmnSCPxj