> 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 <zmnsc...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
