📅 Original date posted:2022-03-04
📝 Original message:> 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 at 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
vjudeu at gazeta.pl [ARCHIVE] /
npub135…nssga
2023-06-07 23:05:04
in reply to nevent1q…lm2g
Author Public Key
npub1357006afyypkgz03lmq8fnuvlkyjt0rukx8rt56ck8xv396jaceqmnssgaPublished at
2023-06-07 23:05:04Event JSON
{
"id": "922cfcf87e249f90cd71407e7314db43c3fb92256f22e0489747be7d7d5ff9de",
"pubkey": "8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32",
"created_at": 1686179104,
"kind": 1,
"tags": [
[
"e",
"3f4afa40f1b3d3df02303b20f32131f3ef04d46df1c07a411f3b0335c1528661",
"",
"root"
],
[
"e",
"be9ee1067e954ed17510146f22d7b1d274f494e2f8ba0b3b083be20f50702c74",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2022-03-04\n📝 Original message:\u003e The Taproot address itself has to take up 32 bytes onchain, so this saves nothing.\n\nThere 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.\n\nSo, instead of having:\n\n\u003ccoinbasePubkey\u003e\n\u003copReturn1\u003e\n\u003copReturn2\u003e\n...\n\u003copReturnN\u003e\n\nWe could have:\n\n\u003ctweakedCoinbasePubkey\u003e\n\nOn 2022-03-04 09:42:23 user ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e Good morning vjudeu,\n\n\u003e \u003e 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.\n\u003e\n\u003e 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.\n\nThe Taproot address itself has to take up 32 bytes onchain, so this saves nothing.\n\nRegards,\nZmnSCPxj",
"sig": "0caf8d1898b3edb390d11ff2fbb29562a574292947e172b6ad2c6a3b4d0b2031701efc4e92849d5a0ea9242f4f81cc7334ad29758870fd3d05a560b8a2a865fc"
}