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
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9F4DBC001A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 00:58:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7881483E02
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 00:58:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.717
X-Spam-Level:
X-Spam-Status: No, score=-0.717 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.117,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.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 u7KKUHzcxr8C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 00:58:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com
[IPv6:2607:f8b0:4864:20::731])
by smtp1.osuosl.org (Postfix) with ESMTPS id 5EC4B83DFB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Feb 2022 00:58:05 +0000 (UTC)
Received: by mail-qk1-x731.google.com with SMTP id b13so7689771qkj.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 16:58:05 -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=LLhtDbpG5A84a8u+QUJ5yT5U/ZWvzaVFm/5JSdKFPeA=;
b=UzTbkM6czYpkrCuVnqEICOS5aEqWueachyOdnxHtPiT82yfj/6OLr05Y4s8j+ggteo
RI8f5L00vFKxVMRtLxl/u9IFsV5kI6B+tdNf1Y/9kEDt6W3CUy9MB7rOSu7vwnYW4U6w
TmhGuv6J+V0DIA2Xn98XKsJjsHwGCT19gUObpkh+V1p2KM2DK7KOBLQ3N2d8Z9cnzOo6
LyzyQ9IpRcQ0irIpO1CboUVbnKxyWSv4dh+XOyZH+W63tAoBTQ3Ysaa5MZoOGXxweyth
qYS9gum0gMf0AIPnAs1wEWubwj4J3yW1J1d23MFKzKcGourVFu9LydauameGxffxLhw/
mYWw==
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=LLhtDbpG5A84a8u+QUJ5yT5U/ZWvzaVFm/5JSdKFPeA=;
b=y4F5gAEUgxASNsk5MK9iRAHmQqh1tqQmzybU9gC9iq7vCdqS57lwfDCsQhPp2zp6Hf
HVLseGGOgLQxAw1g3ubiycohu7tpfRtQTkupB/xVm+GSmlAsfJSRADeDLkxeLPgknYPv
A3ghdYLRVcSCqW22g3mW2lGiyRn327EELROssB3wiTr0NY3QgP9Qeo04lwFhofPQtCKQ
Mgz+GneK/86OVrYvzYfoHIQNkqzdZespxNImzWpy9lEUyWOykWdWx50SXsBgRJY8yX5b
YxJBJ9Mm1sgFAMX23gnXkHeiwyAc75mqbUldT/TkjSDZr5H2CjZZ1t6lOkFrITJ/5Cy0
XsYw==
X-Gm-Message-State: AOAM5337+ssw4PkBmqctngUCCPIuDEcbUgFxIfiKvjGy8DYgFkC/euke
fB/jf/1VKp5++PYEh6e5jselF/UtNLU=
X-Google-Smtp-Source: ABdhPJwHQpyezfVXo52XYsdXy3sX+zVcRoUkJ+WpDTTvSW2e8wcgWs+2KhtT9mReAMeCUWPmUvsGEA==
X-Received: by 2002:a05:620a:125c:b0:648:ad0a:4deb with SMTP id
a28-20020a05620a125c00b00648ad0a4debmr8120878qkl.629.1645923483829;
Sat, 26 Feb 2022 16:58:03 -0800 (PST)
Received: from [192.168.0.165] (ool-45714b6d.dyn.optonline.net.
[69.113.75.109]) by smtp.googlemail.com with ESMTPSA id
p20-20020a05620a22b400b00648ca1458b4sm3167887qkh.5.2022.02.26.16.58.03
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sat, 26 Feb 2022 16:58:03 -0800 (PST)
Content-Type: multipart/alternative;
boundary="------------k8qCMw50rbuzzLc0pF4oRaB8"
Message-ID: <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com>
Date: Sat, 26 Feb 2022 19:58:01 -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>
From: Paul Sztorc <truthcoin@gmail.com>
In-Reply-To: <fV9nkjr6K9fQWJWXtO4b3uZGzpHvDNdQa89X73yUB2YVsvuNVPDqsJln88pEef1fzHsui-qnneXdmYsO7CDibxMrm9PBDOO0Ls8RV1Bx1BI=@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: Sun, 27 Feb 2022 00:58:06 -0000
This is a multi-part message in MIME format.
--------------k8qCMw50rbuzzLc0pF4oRaB8
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/26/2022 1:43 AM, ZmnSCPxj via bitcoin-dev wrote:
> ...
> Drivechains are not a scaling solution [FOOTNOTE 1] ...
> I personally am interested only in scaling solutions, adding more non-scaling-useable functionality is not of interest to me and I do not really care
> ...
> But if there is consensus that those arguments are bogus, then go ahead --- add Drivechains and/or recursive covenants.
> ...
>
> [FOOTNOTE 1] Sidechains are not a scaling solution ... Blockchains are inefficient ... and you have to show your transaction to everyone.
> ...
> Now you might conter-argue that you can have multiple smaller sidechains and just use HTLCs to trade across them ... I would then counter-counter-argue that bringing this to the most extreme conclusion, you would have tons of sidechains with only 2 participants each ...
Do you really hang your entire --"sidechains are not a scaling solution"-- argument on this frail logic?
The scaling strategy (in LN and DC) is the same: try NOT to "show your transaction to everyone". The details are of course different.
I think largeblock sidechains should be reconsidered:
* They are not a blocksize increase.
* They endorse the principle of scaling in layers.
* They allow users to be different. Some can pay more (for more decentralization), some less (for less decentralization).
(We are currently gambling the entire future of BTC, on the premise that strong decentralization will always be needed at all points in time.)
(This leaves us vulnerable to a strategy where our adversaries temporarily favor/promote centralized chains, so as to "domesticate" / control these in the future.)
* We can learn from past mistakes -- when a new largeblock sidechain is needed, we can make a new one from scratch, using everything we know.
* Different teams can compete, releasing different chains independently; thus curtailing "toxicity".
* All of the fees, paid on all blockchains, arrive as revenue to the same group of miners, thus improving total hashrate/difficulty.
* Sidechains will organize geographically, which may help security (ie, USA could spitefully run full nodes of the "China" largeblock sidechain).
* Relative to LN, users enjoy: unlimited "inbound liquidity", can receive money while offline, no risk that the channel will close, etc.
Certainly, sidechains are NOT for everyone. (Just as [I imagine] the LN is not for everyone.)
However, in 2015, many hardfork-largeblockers said: "we do not run a full node, full nodes are not important; we use SPV; read the whitepaper" etc.
They used SPV completely; and wanted large blocks. Presumably they would be happy users of a largeblock sidechain. So it would be >0 users.
Sadly, this idea is neglected, (I think) because of its unfortunate resemblance to naive-largeblock-ism. This is irrational.
***
You have emphasized the following relation: "you have to show your transaction to everyone" = "thing doesn't scale".
However, in LN, there is one transaction which you must, in fact, "show to everyone": your channel-opener.
Amusingly, in the largeblock sidechain, there is not. You can onboard using only the blockspace of the SC.
(One "rich guy" can first shift 100k coins Main-to-Side, and he can henceforth onboard many users over there. Those users can then onboard new users, forever.)
So it would seem to me, that you are on the ropes, even by your own criterion. [Footnote 1]
***
Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 bytes.
If so, a "rich man" could open a LN channel, and gradually transfer it to new people.
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.
Paul
[Footnote 1]
I am certainly not a LN expert, so perhaps this analysis is misconceived. But consider these "best case scenario" assumptions for LN:
* Each new channel-open consumes just 32 vbytes (since they are all done via one or more "rich men" who batches all these into one block, 24/7/365)
* Each new channel-open, onboards 5 users at once who are a permanent trust group / channel factory / what-have-you
(these five newcomers must coordinate with each other and the "rich man", presumably via calendly link or whatever, for their one shot at getting on the blockchain).
* That one single channel is able to meet 100% of the user's payment needs
(it never has any problems, with liquidity /balancing /routing /uptime /hotwallet-crashing /counterparty-fees /etc)
(and also, people do NOT desire >1 channel for other reasons: their alt nyms, small business, church, etc)
* 99.9% of the 1MB (vB) blocksize is used for channel-opens (the spare 1000 vb = the coinbase + the single "rich man"-input)
* World population becomes a fixed 8.2 billion (and henceforth stops growing)
By simple envelop math, 6*24*365*(((1000000*.999)/32)*5) / 8.2 billion = ~exactly one year to onboard everyone.
But if the above assumptions contain, say, two orders of magnitude of "optimism", then it would instead take 100 years.
--------------k8qCMw50rbuzzLc0pF4oRaB8
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><font face="monospace">On 2/26/2022 1:43 AM, ZmnSCPxj via bitcoin-dev wrote:
</font></pre>
</div>
<blockquote type="cite"
cite="mid:fV9nkjr6K9fQWJWXtO4b3uZGzpHvDNdQa89X73yUB2YVsvuNVPDqsJln88pEef1fzHsui-qnneXdmYsO7CDibxMrm9PBDOO0Ls8RV1Bx1BI=@protonmail.com">
<pre>...
Drivechains are not a scaling solution [FOOTNOTE 1] ...
I personally am interested only in scaling solutions, adding more non-scaling-useable functionality is not of interest to me and I do not really care</pre>
<pre class="moz-quote-pre" wrap="">...
But if there is consensus that those arguments are bogus, then go ahead --- add Drivechains and/or recursive covenants.
...
[FOOTNOTE 1] Sidechains are not a scaling solution ... Blockchains are inefficient ... and you have to show your transaction to everyone.
...
Now you might conter-argue that you can have multiple smaller sidechains and just use HTLCs to trade across them ... I would then counter-counter-argue that bringing this to the most extreme conclusion, you would have tons of sidechains with only 2 participants each ...
</pre>
</blockquote>
<pre>Do you really hang your entire --"sidechains are not a scaling solution"-- argument on this frail logic?
The scaling strategy (in LN and DC) is the same: try NOT to "show your transaction to everyone". The details are of course different.
I think largeblock sidechains should be reconsidered:
* They are not a blocksize increase.
* They endorse the principle of scaling in layers.
* They allow users to be different. Some can pay more (for more decentralization), some less (for less decentralization).
(We are currently gambling the entire future of BTC, on the premise that strong decentralization will always be needed at all points in time.)
(This leaves us vulnerable to a strategy where our adversaries temporarily favor/promote centralized chains, so as to "domesticate" / control these in the future.)
* We can learn from past mistakes -- when a new largeblock sidechain is needed, we can make a new one from scratch, using everything we know.
* Different teams can compete, releasing different chains independently; thus curtailing "toxicity".
* All of the fees, paid on all blockchains, arrive as revenue to the same group of miners, thus improving total hashrate/difficulty.
* Sidechains will organize geographically, which may help security (ie, USA could spitefully run full nodes of the "China" largeblock sidechain).
* Relative to LN, users enjoy: unlimited "inbound liquidity", can receive money while offline, no risk that the channel will close, etc.
Certainly, sidechains are NOT for everyone. (Just as [I imagine] the LN is not for everyone.)
However, in 2015, many hardfork-largeblockers said: "we do not run a full node, full nodes are not important; we use SPV; read the whitepaper" etc.
They used SPV completely; and wanted large blocks. Presumably they would be happy users of a largeblock sidechain. So it would be >0 users.
Sadly, this idea is neglected, (I think) because of its unfortunate resemblance to naive-largeblock-ism. This is irrational.
***
You have emphasized the following relation: "you have to show your transaction to everyone" = "thing doesn't scale".
However, in LN, there is one transaction which you must, in fact, "show to everyone": your channel-opener.
Amusingly, in the largeblock sidechain, there is not. You can onboard using only the blockspace of the SC.
(One "rich guy" can first shift 100k coins Main-to-Side, and he can henceforth onboard many users over there. Those users can then onboard new users, forever.)
So it would seem to me, that you are on the ropes, even by your own criterion. [Footnote 1]
***
Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 bytes.
If so, a "rich man" could open a LN channel, and gradually transfer it to new people.
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.
Paul
[Footnote 1]
I am certainly not a LN expert, so perhaps this analysis is misconceived. But consider these "best case scenario" assumptions for LN:
* Each new channel-open consumes just 32 vbytes (since they are all done via one or more "rich men" who batches all these into one block, 24/7/365)
* Each new channel-open, onboards 5 users at once who are a permanent trust group / channel factory / what-have-you
(these five newcomers must coordinate with each other and the "rich man", presumably via calendly link or whatever, for their one shot at getting on the blockchain).
* That one single channel is able to meet 100% of the user's payment needs
(it never has any problems, with liquidity /balancing /routing /uptime /hotwallet-crashing /counterparty-fees /etc)
(and also, people do NOT desire >1 channel for other reasons: their alt nyms, small business, church, etc)
* 99.9% of the 1MB (vB) blocksize is used for channel-opens (the spare 1000 vb = the coinbase + the single "rich man"-input)
* World population becomes a fixed 8.2 billion (and henceforth stops growing)
By simple envelop math, 6*24*365*(((1000000*.999)/32)*5) / 8.2 billion = ~exactly one year to onboard everyone.
But if the above assumptions contain, say, two orders of magnitude of "optimism", then it would instead take 100 years.
</pre>
</body>
</html>
--------------k8qCMw50rbuzzLc0pF4oRaB8--
|
