1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id CC9C9C001A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 07:25:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id B5A0D82A53
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 07:25:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_FMBLA_NEWDOM=1.498, FROM_LOCAL_NOVOWEL=0.5,
RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id kodRH2Ef4M9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 07:25:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4027.protonmail.ch (mail-4027.protonmail.ch [185.70.40.27])
by smtp1.osuosl.org (Postfix) with ESMTPS id C24388297F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 07:25:39 +0000 (UTC)
Date: Sun, 27 Feb 2022 07:25:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645946736;
bh=94GeTEqWIRJ6FA80XH7cOSt8V+r11rpxXoak0YDJu94=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=kF5Bfjv2e5UDU7r5LXF/kQTvWUgwa7qONE5AHl149QM60FmsbFDIr1iW1sARMOfW/
ClOp5VYEkNgjwl32mr8aCOvD1Fm6ud6F7GSDXkdHxkLfMC5Sn0YfoEmHTq4gz1hs0X
yiBRF5dPy8Vjug4b0MWjRRXoqWAxYOTO3TmzuXkWhBYLdbt8Sc5rtR0vQfRQMNxCy0
0jA9jgCOEKS2rEbv5CEk/vgLF4+YCeKY8wI+rgnzE0QKw1ZaJBWjRvhjnqo7Fs3KEr
n36J3OpvLzaAfGAEsF8t1xp1KRCrjm5L1/bdlrLilOqzl1i1zfe193CTnXW7HBNnXP
eEUjeZjuFuing==
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <erNX61VSwzTcxedBOPn50Qh5rqidnUXBcqOXDz9i13U7Ac-knnYzdr3bMYT1ATyUE37OlEgRirv8BdD4EpG8vj0pNdd2p8x8gkoKvhTh0J8=@protonmail.com>
In-Reply-To: <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
<0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
<i710HUIxNHIqCNhkh07dzlShyDp9ZkoEokw9ZBezCFvsk05ZUy5fXK1xx_IQifLh4f3RYb8FJM_MFm7hAaQFaUM3Jy3E8QhfSzkaogAu1Gs=@protonmail.com>
<20220224065305.GB1965@erisian.com.au>
<bQvm5sSOMGRKR2udDFTNCJlOv_2vuIjkkBsoYqi4463y8ZjFDY4kxVvJEz7yv0GfxbyrMo-eOhOnEnd6sKPrWSk6PXn8KNerRlWsiGsWZRU=@protonmail.com>
<CAGpPWDaVN4iAzfDKEQs2hmoQOHtToyPao1FgDCsMTJvt7pbq5g@mail.gmail.com>
<fV9nkjr6K9fQWJWXtO4b3uZGzpHvDNdQa89X73yUB2YVsvuNVPDqsJln88pEef1fzHsui-qnneXdmYsO7CDibxMrm9PBDOO0Ls8RV1Bx1BI=@protonmail.com>
<0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com>
<Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
or the absence thereof,
was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and
ANYPREVOUT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Feb 2022 07:25:40 -0000
Good morning again Paul,
> With sidechains, changing the ownership set requires that the sidechain p=
roduce 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 rea=
l 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 tha=
t the miner is being bribed to put in the coinbase, and a txout for any cha=
nge the sidechain validator has.
This is somewhat worse than the case for channel factories, even if you ass=
ume 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 expe=
nsive (it requires a pointer to the previous txout, a 64-byte Taproot signa=
ture, 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 3=
2-byte commitments, whereas continuous operation of a channel factory, in t=
he 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, bu=
t typical economic transactions occur much more often), so optimizing for t=
he 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 requi=
res a commitment on the mainchain:
* Onchain: onboarding / deboarding, payments
While it is true that all onboarding, deboarding, and payments are summariz=
ed in a single commitment, notice how in LN-with-channel-factories, all onb=
oarding / deboarding is *also* summarized, but payments *have no onchain im=
pact*, 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, d=
ue 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 im=
plicit 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 publish=
ed 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, b=
ut at least you can *start* a new channel without being censored, which you=
cannot do with Drivechain sidechains.)
Regards,
ZmnSCPxj
|
