From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
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
Date: Sun, 27 Feb 2022 07:25:27 +0000 [thread overview]
Message-ID: <erNX61VSwzTcxedBOPn50Qh5rqidnUXBcqOXDz9i13U7Ac-knnYzdr3bMYT1ATyUE37OlEgRirv8BdD4EpG8vj0pNdd2p8x8gkoKvhTh0J8=@protonmail.com> (raw)
In-Reply-To: <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
Good morning again Paul,
> With sidechains, changing the ownership set requires that the sidechain produce a block.
> That block requires a 32-byte commitment in the coinbase.
> What is more, if any transfers occur on the sidechain, they cannot be real without a sidechain block, that has to be committed on the mainchain.
The above holds if the mainchain miners also act as sidechain validators.
If they are somehow separate (i.e. blind merge mining), then the `OP_BRIBE` transaction needed is also another transaction.
Assuming the sidechain validator is using Taproot as well, it needs the 32+1 txin, a 64-byte signature, a 32-byte copy of the sidechain commitment that the miner is being bribed to put in the coinbase, and a txout for any change the sidechain validator has.
This is somewhat worse than the case for channel factories, even if you assume that every block, at least one channel factory has to do an onboarding event.
> Thus, while changing the membership set of a channel factory is more expensive (it requires a pointer to the previous txout, a 64-byte Taproot signature, and a new Taproot address), continuous operation does not publish any data at all.
> While in sidehchains, continuous operation and ordinary payments requires ideally one commitment of 32 bytes per mainchain block.
> 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.
>
> We assume that onboarding new members is much rarer than existing members actually paying each other in an actual economy (after the first burst of onboarding, new members will only arise in proportion to the birth rate, but typical economic transactions occur much more often), so optimizing for the continuous operation seems a better tradeoff.
Perhaps more illustratively, with channel factories, different layers have different actions they can do, and the only one that needs to be broadcast widely are actions on the onchain layer:
* Onchain: onboarding / deboarding
* Channel Factory: channel topology change
* Channel: payments
This is in contrast with merge-mined Sidechains, where *all* activity requires a commitment on the mainchain:
* Onchain: onboarding / deboarding, payments
While it is true that all onboarding, deboarding, and payments are summarized in a single commitment, notice how in LN-with-channel-factories, all onboarding / deboarding is *also* summarized, but payments *have no onchain impact*, at all.
Without channel factories, LN is only:
* Onchain: onboarding / deboarding, channel topology change
* Channel: payments
So even without channel factories there is already a win, although again, due to the large numbers of channels we need, a channel factory in practice will be needed to get significantly better scaling.
Finally, in practice with Drivechains, starting a new sidechain requires implicit permission from the miners.
With LN, new channels and channel factories do not require any permission, as they are indistinguishable from ordinary transactions.
(the gossip system does leak that a particular UTXO is a particular published channel, but gossip triggers after deep confirmation, at which point it would be too late for miners to censor the channel opening.
The miners can censor channel closure for published channels, admittedly, but at least you can *start* a new channel without being censored, which you cannot do with Drivechain sidechains.)
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-02-27 7:25 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 17:20 [bitcoin-dev] " Russell O'Connor
2022-01-26 22:16 ` Jeremy
2022-01-27 4:20 ` James Lu
2022-01-27 19:16 ` Russell O'Connor
2022-01-28 0:18 ` James O'Beirne
2022-01-28 13:14 ` Michael Folkson
2022-01-28 14:17 ` Anthony Towns
2022-01-28 16:38 ` Jeremy
2022-01-28 14:13 ` Russell O'Connor
2022-01-28 15:14 ` James O'Beirne
2022-01-29 15:43 ` Russell O'Connor
2022-01-29 17:02 ` Jeremy Rubin
[not found] ` <CAD5xwhjHv2EGYb33p2MRS=VSz=ciGwAsiafX1yRHjxQEXfykSA@mail.gmail.com>
2022-01-29 17:14 ` Russell O'Connor
2022-01-31 2:18 ` Anthony Towns
2022-01-28 1:34 ` Anthony Towns
2022-01-28 13:56 ` Russell O'Connor
2022-02-01 1:16 ` Anthony Towns
2022-02-08 2:16 ` Russell O'Connor
2022-02-17 14:27 ` Anthony Towns
2022-02-17 14:50 ` Russell O'Connor
2022-02-08 3:40 ` Rusty Russell
2022-02-08 4:34 ` Jeremy Rubin
2022-02-11 0:55 ` [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding
2022-02-11 3:42 ` Jeremy Rubin
2022-02-11 17:42 ` James O'Beirne
2022-02-11 18:12 ` digital vagabond
2022-02-12 10:54 ` darosior
2022-02-12 15:59 ` Billy Tetrud
2022-02-17 15:15 ` Anthony Towns
2022-02-18 7:34 ` ZmnSCPxj
2022-02-23 11:28 ` ZmnSCPxj
2022-02-23 18:14 ` Paul Sztorc
2022-02-24 2:20 ` ZmnSCPxj
2022-02-24 6:53 ` Anthony Towns
2022-02-24 12:03 ` ZmnSCPxj
2022-02-26 5:38 ` Billy Tetrud
2022-02-26 6:43 ` ZmnSCPxj
2022-02-27 0:58 ` Paul Sztorc
2022-02-27 2:00 ` ZmnSCPxj
2022-02-27 7:25 ` ZmnSCPxj [this message]
2022-02-27 16:59 ` Billy Tetrud
2022-02-27 23:50 ` Paul Sztorc
2022-02-28 0:20 ` Paul Sztorc
2022-02-28 6:49 ` ZmnSCPxj
2022-02-28 7:55 ` vjudeu
2022-03-04 8:42 ` ZmnSCPxj
2022-03-04 13:43 ` vjudeu
2022-02-28 22:54 ` Paul Sztorc
2022-03-01 5:39 ` Billy Tetrud
2022-03-02 0:00 ` Paul Sztorc
2022-03-04 12:35 ` Billy Tetrud
2022-03-04 20:06 ` Paul Sztorc
2022-02-26 6:00 ` Anthony Towns
2022-02-15 8:45 ` [bitcoin-dev] " Rusty Russell
2022-02-15 18:57 ` Jeremy Rubin
2022-02-15 19:12 ` Russell O'Connor
2022-02-16 2:26 ` Rusty Russell
2022-02-16 4:10 ` Russell O'Connor
2022-02-14 2:40 [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " Lucky Star
2022-02-26 7:47 Prayank
2022-02-26 16:18 ` Billy Tetrud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='erNX61VSwzTcxedBOPn50Qh5rqidnUXBcqOXDz9i13U7Ac-knnYzdr3bMYT1ATyUE37OlEgRirv8BdD4EpG8vj0pNdd2p8x8gkoKvhTh0J8=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox