Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
In-Reply-To: <HLa5I3wJJu9SEQ2UD69HYFY1pwaIzvK1iQzdTggBVZkLHEdaXcp1UbLFiSMJOxcSZqr-EKYb7Irtxa7kI830XJamCqSy4jJ8WynGPqZ-xoM=@protonmail.com>
Date: Fri, 04 Mar 2022 14:43:40 +0100
Message-Id: <158184081-a1d5b424942fc47a0a6665ca7ba04258@pmq4v.m5r2.onet>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
 or the absence thereof,
 was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Precedence: list

> 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:

<coinbasePubkey>
<opReturn1>
<opReturn2>
...
<opReturnN>

We could have:

<tweakedCoinbasePubkey>

On 2022-03-04 09:42:23 user ZmnSCPxj <ZmnSCPxj@protonmail.com> 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