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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 596E9C001A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Feb 2022 00:20:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 33481400D8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Feb 2022 00:20:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id pgTrA8Lr8x4g
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Feb 2022 00:20:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com
[IPv6:2607:f8b0:4864:20::735])
by smtp2.osuosl.org (Postfix) with ESMTPS id B9822400C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Feb 2022 00:20:50 +0000 (UTC)
Received: by mail-qk1-x735.google.com with SMTP id bm39so9228176qkb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 16:20:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=message-id:date:mime-version:user-agent:content-language:to
:references:from:subject:in-reply-to;
bh=cQ1ZpjaAizDXsZXo8/NitRLmUFpeZxQZFASgrGa0hPQ=;
b=TE7TsKXtQFlfnP3EZSpNelZE0QQbOoFqtBc+L5/pCwY9S8MmTXccOwNNbSFJygrg5+
KhLRZTSWXbjdeAzxc2nK8ZYlSzT+ZifCbfJi0oLbuCS7IEAgbnTa0zPEvCaU8/YhxFhl
pcrb3c4R5mKQAKrSYHf6FLxfr9KVjfTr4Ly53CpJGw5wJ0xYaAUYWCimkNcVjxkdcNgz
YElXebv+4SgT2RFZwmkc2Bw+TDVndcjzOpBWJP4SLYSFQYpaHPsy4clhie0CkOTGm0Sz
7ZDRXt58VWCnDJLfDQuyLmxE5AJAFdBw9Aml8rhNibbWHK3loqg0zIQd5qMwVlgA0XZf
ZmjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:message-id:date:mime-version:user-agent
:content-language:to:references:from:subject:in-reply-to;
bh=cQ1ZpjaAizDXsZXo8/NitRLmUFpeZxQZFASgrGa0hPQ=;
b=F4BAdlvXzKvoi4FcmB80/XaTo7SLMGtD0Y/SvoXOQ20Kby3zij2wQU0WVu9prgjgkL
QbYsrs1aI8/TjnwZa7GWFMbcaezDqtjYWq7PiaWxIBGyTB0U630sZg7D1GO5KoczpdVq
p5uVGUdNKYk4wyTEygfEPGFKlSp2X/6jvqAIrqbGTdgPQF5aot3KXGr45Q8YDclqsTuo
Ci04uUgDDi8rfAkkVXuLWKpk6lWkigVaIqrQH0JNve3cgqZvIC5EKs3DbHK4rpc7BQDC
d9/LCivlTv6AB9t2/HiPPJWunyloG3BSDqc0S1TdgiC7Em5KqucZq7fG5FRXbNtgknHd
nzsQ==
X-Gm-Message-State: AOAM5322Kd1YQNRnAIHToi+Ws3bSvx577iffVzCM3IGyclDlVbN5FG50
AIgJziXOfgHaa4NT2G62Ddj/LPqBWho=
X-Google-Smtp-Source: ABdhPJxQrulxWE3SqcscloHQV7LqFuAzXQmdRpsYSYGGwf8q01i2EXiGD7m2aIuPVlvqbg+OiIZCng==
X-Received: by 2002:a05:620a:a82:b0:508:b41b:c44b with SMTP id
v2-20020a05620a0a8200b00508b41bc44bmr10113461qkg.100.1646007649209;
Sun, 27 Feb 2022 16:20:49 -0800 (PST)
Received: from [192.168.0.165] (ool-45714b6d.dyn.optonline.net.
[69.113.75.109]) by smtp.googlemail.com with ESMTPSA id
o1-20020a37be01000000b00648eadafd9bsm4363287qkf.24.2022.02.27.16.20.48
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 27 Feb 2022 16:20:48 -0800 (PST)
Content-Type: multipart/alternative;
boundary="------------5waTeVtYMaDK1zIYKPWbel0a"
Message-ID: <0af7c513-3df8-dcc8-9a14-e7e909e7fdc6@gmail.com>
Date: Sun, 27 Feb 2022 19:20:47 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0 Thunderbird/91.5.0
Content-Language: en-US
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
<87leymuiu8.fsf@rustcorp.com.au>
<CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@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>
From: Paul Sztorc <truthcoin@gmail.com>
In-Reply-To: <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
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: Mon, 28 Feb 2022 00:20:52 -0000
This is a multi-part message in MIME format.
--------------5waTeVtYMaDK1zIYKPWbel0a
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/26/2022 9:00 PM, ZmnSCPxj wrote:
> ...
>> Such a technique would need to meet two requirements (or, so it seems to me):
>> #1: The layer1 UTXO (that defines the channel) can never change (ie, the 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-they-were when the channel was opened).
>> #2: The new part-owners (who are getting coins from the rich man), will have new pubkeys which are NOT known, until AFTER the channel is opened and confirmed on the blockchain.
>>
>> Not sure how you would get both #1 and #2 at the same time. But I am not up to date on the latest LN research.
> Yes, using channel factories.
I think you may be wrong about this.
Channel factories do not meet requirement #2, as they cannot grow to onboard new users (ie, new pubkeys).
The factory-open requires that people pay to (for example), a 5-of-5 multisig. So all 5 fixed pubkeys must be known, before the factory-open is confirmed, not after.
> We assume that onboarding new members is much rarer than existing members actually paying each other
Imagine that Bitcoin could only onboard 5 new users per millennium, but once onboarded they had payment nirvana (could transact hundreds of trillions of times per second, privately, smart contracts, whatever).
Sadly, the payment nirvana would not matter. The low onboarding rate would kill the project.
The difference between the two rates [onboarding and payment], is not relevant. EACH rate must meet the design goal.
It is akin to saying: " Our car shifts from park to drive in one-millionth of a second, but it can only shift into reverse once per year; but that is OK because 'we assume that going in reverse is much rarer than driving forward' ".
> 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.
That's true, but I think you have neglected to actually take out your calculator and run the numbers.
Hypothetically, 10 largeblock-sidechains would be 320 bytes per block (00.032%, essentially nothing).
Those 10, could onboard 33% of the planet in a single month [footnote], even if each sc-onboard required an average of 800 sc-bytes.
Certainly not a perfect idea, as the SC onboarding rate is the same as the payment rate. But once they are onboarded, those users can immediately join the LN *from* their sidechain. (All of the SC LNs would be interoperable.)
Such a strategy would take enormous pressure *off* of layer1 (relative to the "LN only" strategy). The layer1 blocksize could even **shrink** from 4 MB (wu) to 400 kb, or lower. That would cancel out the 320 bytes of overhead, many hundreds of times over.
Paul
[footnote] Envelope math, 10 sidechains, each 50 MB forever-fixed blocksize (which is a mere 12.5x our current 4M wu limit): 10 * 6*24*30 * ((50*1000*1000)/800) / 8.2 billion = .32926
--------------5waTeVtYMaDK1zIYKPWbel0a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<pre>On 2/26/2022 9:00 PM, ZmnSCPxj wrote:</pre>
</div>
<blockquote type="cite"
cite="mid:Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com">...
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Such a technique would need to meet two requirements (or, so it seems to me):
#1: The layer1 UTXO (that defines the channel) can never change (ie, the 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-they-were when the channel was opened).
#2: The new part-owners (who are getting coins from the rich man), will have new pubkeys which are NOT known, until AFTER the channel is opened and confirmed on the blockchain.
Not sure how you would get both #1 and #2 at the same time. But I am not up to date on the latest LN research.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yes, using channel factories.</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think you may be wrong about this.
Channel factories do not meet requirement #2, as they cannot grow to onboard new users (ie, new pubkeys).
The factory-open requires that people pay to (for example), a 5-of-5 multisig. So all 5 fixed pubkeys must be known, before the factory-open is confirmed, not after.
<blockquote type="cite"><pre class="moz-quote-pre" wrap="">We assume that onboarding new members is much rarer than existing members actually paying each other
</pre></blockquote>
Imagine that Bitcoin could only onboard 5 new users per millennium, but once onboarded they had payment nirvana (could transact hundreds of trillions of times per second, privately, smart contracts, whatever).
Sadly, the payment nirvana would not matter. The low onboarding rate would kill the project.
The difference between the two rates [onboarding and payment], is not relevant. EACH rate must meet the design goal.
It is akin to saying: " Our car shifts from park to drive in one-millionth of a second, but it can only shift into reverse once per year; but that is OK because 'we assume that going in reverse is much rarer than driving forward' ".
<blockquote type="cite"><pre class="moz-quote-pre" wrap="">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.</pre></blockquote>
That's true, but I think you have neglected to actually take out your calculator and run the numbers.
Hypothetically, 10 largeblock-sidechains would be 320 bytes per block (00.032%, essentially nothing).
Those 10, could onboard 33% of the planet in a single month [footnote], even if each sc-onboard required an average of 800 sc-bytes.
Certainly not a perfect idea, as the SC onboarding rate is the same as the payment rate. But once they are onboarded, those users can immediately join the LN *from* their sidechain. (All of the SC LNs would be interoperable.)
Such a strategy would take enormous pressure *off* of layer1 (relative to the "LN only" strategy). The layer1 blocksize could even **shrink** from 4 MB (wu) to 400 kb, or lower. That would cancel out the 320 bytes of overhead, many hundreds of times over.
Paul
[footnote] Envelope math, 10 sidechains, each 50 MB forever-fixed blocksize (which is a mere 12.5x our current 4M wu limit): 10 * 6*24*30 * ((50*1000*1000)/800) / 8.2 billion = .32926
</pre>
</body>
</html>
--------------5waTeVtYMaDK1zIYKPWbel0a--
|
