Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[vjudeu@gazeta.pl]

> 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 transaction and a solo miner or mining pool that is getting the whole reward. So, instead of using separate OP_RETURN's for each sidechain, for each federation, and for every "commitment to the blockchain", all we need is just tweaking 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 only need a commitment and a MAST-based path that can link such commitment to 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 published.
>
> The sidechain can push zero bytes on-chain, just by placing a sidechain hash in OP_RETURN inside TapScript. Then, every sidechain node can check that "this sidechain hash is connected with this Taproot address", without pushing 32 bytes on-chain.

The Taproot address itself has to take up 32 bytes onchain, so this saves nothing.

Regards,
ZmnSCPxj