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
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D4469C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Jul 2023 20:45:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 9A7C541B61
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Jul 2023 20:45:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9A7C541B61
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=TJItPO6Z
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id jK0PdkQ9B9wp
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Jul 2023 20:45:29 +0000 (UTC)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
[IPv6:2a00:1450:4864:20::634])
by smtp4.osuosl.org (Postfix) with ESMTPS id B7D2D416AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Jul 2023 20:45:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B7D2D416AD
Received: by mail-ej1-x634.google.com with SMTP id
a640c23a62f3a-98e39784a85so265816966b.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Jul 2023 13:45:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1689799527; x=1690404327;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=yO4pY1bNXWZYiHKtxh9523R1Rbh/wJpSEFsl7A2nkkA=;
b=TJItPO6Zm2WccNCzU76AruplnKAeYOHZC3pIf4mnpfHguvQm2KnyvoksRmQFa+guey
nHPdFlGwIR4Kc20NYdQ1w3Kuu8Ovxz2+V/37G+apRCVEo07mzoYBlZzUqb8jAdxgBTsa
IEzAwEYabmNezndmM67V53TxvfPfM2F8N9BMm5WyrNmY6udfkdGtF47j7cUORY8nvJEU
SUKmVVne6cOIm9oqxW8KHr/mW9pQf22HGgyVrxpAtYr29ieSjqeAZK0t1w7Q1HZGhFxt
ZWlpjFwzBy3EHqHfGUokqraWEOGlcAHPjuSqOCD/rE8tpLQofyx1hyzFq5tqvilyKUcj
eaCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1689799527; x=1690404327;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=yO4pY1bNXWZYiHKtxh9523R1Rbh/wJpSEFsl7A2nkkA=;
b=UgAWfA2uwdo6z1PsVjgUiskFAEvYF6P8tzu6NFXxFrOkLgL6CnOxqUe/YhLVNha8em
ZrP/sc+ofQfErXX/3oD6rLodO6vcv86f980qzOBN2yUwQCvmTb/ps9RCgxO2qK4fXNRX
VnTNVMzRtbY0aNvBPXMfat2cilTbwTKfCLnDg80YjzUf6NA+3ShH29joPK528OS6gyG8
uRSKJpnrTIccZiScd8RgVmXkjw716XqjdgDaRs2SEoMdoDi07Vs2LCL5eed+zRpgCElp
Zh+4Sh6zv7IwwjvFrqVn8viLCg/7yE46DDKjYJNBeOY2UgqKvZP2P3BRNbTJtXJeGE8/
mjDQ==
X-Gm-Message-State: ABy/qLY9h7xGIu+HQGvSQ2Ykty282qKCKSC1cwrlnlMlnEKaFWmRXHpB
wmxIHP8JlomtRmtpYS1tlw0i98LNZGaj3TBYe0E=
X-Google-Smtp-Source: APBJJlEmmHp9kBFxVjTc7IcVbBhRicEWLAwKo4SMDfN+R+DR6bmf7ISGKL20qTa64VrWPF1dhoq+iiemKVooabyqEjo=
X-Received: by 2002:a17:906:5195:b0:994:1805:1fad with SMTP id
y21-20020a170906519500b0099418051fadmr3707250ejk.10.1689799526369; Wed, 19
Jul 2023 13:45:26 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+G=zhzHFTVLxLMgYeQ64srWA7GmfDrkdF+bc6q4+uTnCQ@mail.gmail.com>
<CALeFGL0wzi0z13-H_t13fyrvy5cTo2j0f6qOL0-_zt8suMZU4A@mail.gmail.com>
In-Reply-To: <CALeFGL0wzi0z13-H_t13fyrvy5cTo2j0f6qOL0-_zt8suMZU4A@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 19 Jul 2023 16:45:15 -0400
Message-ID: <CAB3F3DsSjtXxA3X34ky7P=QSr3rEcG94dJ6k7sO543G0HvCv-A@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000082d26c0600dd1cfd"
Subject: Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting
Primitives WG and marking this community process "up for grabs"
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: Wed, 19 Jul 2023 20:45:31 -0000
--00000000000082d26c0600dd1cfd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello Keagen,
Most of the complexity of LN cannot be resolved with covenants. Of the
things that can be simplified in my experience, you're going to need more
than CTV to get significant gains. And in the end, channels can only get so
simple since we have many other BOLTs to deal with. And even then, you're
going to have to convince LN spec writers to include such changes, whatever
they are, then get deployment.
Step 1 is finding a primitive that seems interesting. It's important to
moderate enthusiasm for any primitive with reality, and probably by being
concrete by writing specs that use a primitive, and code it up to discover
what we're overlooking. We're always overlooking something! In my humble
opinion these are step 2 and 3 of gathering mind-share.
As a more productive tact, if we're thinking beyond 2/small party channels,
probably better to snap your fingers, pretend we have Simplicity, see what
we can build, and work backwards from there to see if we can accomplish
this within the confines of bitcoin script?
Cheers,
Greg
On Wed, Jul 19, 2023 at 3:59=E2=80=AFPM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Antoine,
>
> Thank you for the effort you've put towards this. I generally agree that =
a
> smooth functioning Lightning Network is of greater importance than advanc=
ed
> contracting capabilities. However, as I dive deeper into some of the more
> ambitious goals for LN development I am learning that a great deal of
> complexity of some current lightning (LN) proposals can be handily
> discharged with CTV. While I am not intimately familiar with all of the
> other covenant schemes to the same level of technical proficiency, I have=
a
> suspicion that a number of them, if not all of them, are capable of
> discharging the same flavor and amount of complexity as well. Others shou=
ld
> chime in if they can confirm this claim.
>
> I have been publicly on the record as supporting the addition of some
> covenant scheme into Bitcoin for some time and have long held on
> theoretical grounds that the addition of such a mechanism is both necessa=
ry
> and inevitable if Bitcoin is to survive in the long term. However, as I'v=
e
> started to work more directly with the Lightning protocol, these
> theoretical and purely logical arguments became far more concrete and
> immediately beneficial.
>
> I say this primarily to challenge the idea that covenants are a
> distraction from lightning development. It may very well be that your are=
as
> of focus on LN preclude you from splitting your attention and none of thi=
s
> email should be interpreted as a criticism of you applying your efforts i=
n
> the highest leverage manner you can manage. That said, I don't want
> observers of this thread to walk away with the impression that they are t=
wo
> independent efforts as covenants can significantly contribute to LN's
> maturity. When and how should they be prioritized? Unfortunately I don't
> feel able to comment on that at this time. All I know is that Lightning
> would almost certainly benefit substantially from having a covenant
> primitive.
>
> Cheers,
> Keags
>
> On Tue, Jul 18, 2023 at 3:40=E2=80=AFPM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi list,
>>
>> Last year amid the failure of the CTV speedy trial activation and intens=
e
>> conversations about a rainbow of covenant proposals, I introduced the id=
ea
>> of a new community process to specify covenants [0]. This post is to res=
ume
>> the experiment so far and officially mark the process maintenance as "up
>> for grabs", as I won't actively pursue it further (after wavering on suc=
h a
>> decision a bit during May / June).
>>
>> Few of the goals announced at that time were to build a consistent
>> framework to evaluate covenant proposals, see the common grounds between
>> proposals if they could be composed or combined by their authors, open t=
he
>> consensus changes development process beyond the historical boundaries =
of
>> Bitcoin Core and maintain high-quality technical archive as a consensus
>> discussions have spawned half a decade from intellectual conception to
>> activation in average (at least for segwit, schnorr, taproot).
>>
>> Such effort was a speak-by-the-act answer to the issues in
>> consensus development changes pointed out by Jeremy Rubin in April of la=
st
>> year [1]: namely the lack of a "codified checklist" for consensus change=
s,
>> that "consensus is memoryless" and "bitcoin core is not bitcoin"
>> (independently of the technical concerns as I have as limited or
>> non-adequate primitive for vaults / payment pools I expressed during the
>> same time). Other complementary initiatives have been undertaken during =
the
>> same period, AJ with the bitcoin-inquisition fork where the community of
>> developers and contracting primitives of researchers on a consensus-enab=
led
>> fork of core [2]. And Dave Harding with the careful archiving of all
>> covenant proposals under the Optech umbrella [3].
>>
>> About the Bitcoin Contracting Primitives WG, a Github repository was
>> started and maintained to archive and document all the primitives (apo,
>> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
>> check_output_covenant_verify, inherited ids, anyamount, singletons,
>> op_vault) and the corresponding protocols (payment pools, vaults,
>> drivechains, trust-minimized mining pools payouts). We had a total of 6
>> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg f=
or
>> a number of more than 20 individual attendees representing most of the
>> parts of the community. I think (missing march logs). Numerous in-depth
>> discussions did happen on the repository and on the channel on things li=
ke
>> "merkelized all the things" or "payment pools for miners payoffs".
>>
>> As I've been busy on the Lightning-side and other Bitcoin projects, I've
>> not run an online meeting since the month of April, while still having a
>> bunch of fruitful technical discussions with folks involved in the effor=
t
>> at conferences and elsewhere. I launched the effort as an experiment wit=
h
>> the soft commitment to dedicate 20% of my time on it, after few successf=
ul
>> sessions I think such a process has an interest of its own, however it
>> comes with direct competition of my time to work on Lightning robustness=
.
>> Getting my hands dirty on low-level LDK development recently made me
>> realize we still have years of titan work to get a secure and reliable
>> Lightning Network.
>>
>> As such, between extended covenant capabilities for advanced contracts
>> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
>> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I thin=
k
>> the latter goal is more critical for Bitcoin existential survival, and
>> where on a personal title I'll allocate the best of my time and energy (=
and
>> somehow it match the "slow" technical activity on bitcoin-inquisition
>> mostly done by Lightning hands).
>>
>> This is my personal conclusion only on the state of Bitcoin technologica=
l
>> momentum, and this is quite tainted by my deep background in Lightning
>> development. If you've been working on covenant changes proposals, pleas=
e
>> don't take it as a discouragement, I think Taproot (privacy-preserving
>> script policies behind the taproot tree branches) and Schnorr (for nativ=
e
>> multi-sig) soft forks have shown how it can improve the building of
>> self-custody solutions by one or two order of magnitude, and small
>> incremental changes might be good enough to have a lower technical
>> consensus bar.
>>
>> On my side, I'll pursue pure R&D works on CoinPool, notably coming with
>> better solutions with the interactivity issue and mass-compression of
>> withdrawal and design exotic advanced Bitcoin contracts based on the
>> taproot annex, though more in a "l'art pour l'art" approach for the time
>> being [4]. Additionally, I might start to submit an in-depth security
>> review of consensus changes under pseudonyms, it has already been done i=
n
>> the past and somehow it's good practice in terms of "message neutrality"
>> [5]. If folks wanna experiment in terms of payment pools deployment, Gre=
g
>> Maxwell's old joinpool can be used today (and somehow it's worthy of its
>> own as a net advance for coinjoins).
>>
>> I'll honestly acknowledge towards the community, I might have
>> overpromised with the kickstart of this new process aiming to move the
>> frontlines in matters of Bitcoin consensus changes development process. =
On
>> the other hand, I think enough sessions of the working group have been
>> runned and enough marks of technical interests have been collected to
>> demonstrate the minimal value of such a process, so I would estimate my
>> open-source balance sheet towards the community to be in good standing ?
>> (open-minded question).
>>
>> I don't think Bitcoin fundamentally lacks compelling technical proposals
>> to advance the capabilities of Bitcoin Script today, nor the crowd of
>> seasoned and smart protocol developers to evaluate mature proposals
>> end-to-end and on multiple dimensions with a spirit of independence.
>> Rather, I believe what Bitcoin is lacking is a small crowd of technical
>> historians and archivist doing the work of assessing, collecting and
>> preserving consensus changes proposals and QA devs to ensure any consens=
us
>> change proposals has world-class battle-ground testing before to be
>> considered for deployment, ideally with the best standards of Bitcoin
>> decentralization and FOSS neutrality [6].
>>
>> If you would like to pursue the maintenance and nurturing of the Bitcoin
>> Contracting Primitives WG (or the bitcoin-inquisition fork or collaborat=
e
>> with Optech to organize industry-wise workshop on covenants at the image=
of
>> what has been done in 2019 for Taproot), that you're willing to show
>> proof-of-work and you estimate that operational ground, legal informatio=
n
>> or financial resources will anchor your individual work on the long-term=
,
>> don't hesitate to reach out, I'll see what I can do with a disinterested
>> mind [7].
>>
>> With humility,
>> Antoine
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763=
.html
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/02023=
3.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0=
20921.html
>> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
>> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
>> remaining "Big Problems" is still pending on my visit to co-author Gleb
>> Naumenko in Ukraine, which has been postponed few times in light of the
>> conflict operational evolutions.
>> [5] See
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/01=
7614.html.
>> For the philosophical reasons of doing so, I invite you to read Foucault=
's
>> famous essay "Le philosophe masque".
>> [6] Somehow I come to share Jeremy's thesis's "Product management is not
>> "my Job" it's yours" in matters of consensus changes. I believe we might=
be
>> past the technical complexity threshold where even simple consensus chan=
ges
>> can be conducted from A to Z as a one man job or even by a group of 2/3
>> elite devs.
>> [7] I've been reached out multiple times and consistently by R&D
>> non-profits, plebs whales and VC firms who were interested to commit
>> resources to advance softforks and covenants in the Bitcoin space, no do=
ubt
>> when you're reliable and with a track record, folks are ready to offer y=
ou
>> opportunities to work full-time on consensus changes.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000082d26c0600dd1cfd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello Keagen,<div><br></div><div>Most of the complexity of=
LN cannot be resolved with covenants. Of the things that can be simplified=
in my experience, you're going to need more than CTV to get significan=
t gains. And in the end, channels can only get so simple since we have many=
other BOLTs to deal with. And even then, you're going to have to convi=
nce LN spec writers to include such changes, whatever they are, then get de=
ployment.</div><div><br></div><div>Step 1 is finding a primitive that seems=
interesting. It's important to moderate enthusiasm for any primitive w=
ith reality, and probably by being concrete by writing specs that use a pri=
mitive, and code it up to discover what we're overlooking. We're al=
ways overlooking something! In my humble opinion these=C2=A0are step=C2=A02=
and 3 of gathering mind-share.</div><div><br></div><div>As a more producti=
ve tact, if we're thinking beyond 2/small party channels, probably bett=
er to snap your fingers, pretend we have Simplicity, see what we can build,=
and work backwards from there to see if we can accomplish this within the =
confines of bitcoin script?=C2=A0</div><div><br></div><div>Cheers,</div><di=
v>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Wed, Jul 19, 2023 at 3:59=E2=80=AFPM Keagan McClelland via b=
itcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Ant=
oine,<div><br></div><div>Thank you for the effort you've put towards th=
is. I generally agree that a smooth functioning Lightning Network is of gre=
ater importance than advanced contracting capabilities. However, as I dive =
deeper into some of the more ambitious goals for LN development I am learni=
ng that a great deal of complexity of some current lightning (LN) proposals=
can be handily discharged with CTV. While I am not intimately familiar wit=
h all of the other covenant schemes to the same level of technical proficie=
ncy, I have a suspicion that a number of them, if not all of them, are capa=
ble of discharging the same flavor and amount of complexity as well. Others=
should chime in if they can confirm this claim.</div><div><br></div><div>I=
have been publicly on the record as supporting the addition of some covena=
nt scheme into Bitcoin for some time and have long held on theoretical grou=
nds that the addition of such a mechanism is both necessary and inevitable =
if Bitcoin is=C2=A0to survive in the long term. However, as I've starte=
d to work more directly with the Lightning protocol, these theoretical and =
purely logical arguments became far more concrete and immediately beneficia=
l.</div><div><br></div><div>I say this primarily to challenge the idea that=
covenants are a distraction from lightning development. It may very well b=
e that your areas of focus on LN preclude you from splitting your attention=
and none of this email should be interpreted as a criticism of you applyin=
g your efforts in the highest leverage manner you=C2=A0can manage. That sai=
d, I don't want observers of this thread to walk away with the impressi=
on that they are two independent efforts as covenants can significantly con=
tribute to LN's maturity. When and how should they be prioritized? Unfo=
rtunately I don't feel able to comment on that at this time. All I know=
is that Lightning would almost certainly benefit substantially from having=
a covenant primitive.</div><div><br></div><div>Cheers,</div><div>Keags</di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Tue, Jul 18, 2023 at 3:40=E2=80=AFPM Antoine Riard via bitcoin-dev <=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi list,<div><br></d=
iv><div>Last year amid the failure of the CTV speedy trial activation and i=
ntense conversations about a rainbow of covenant proposals, I introduced th=
e idea of a new community process to specify covenants [0]. This post is to=
resume the experiment so far and officially mark the process maintenance a=
s "up for grabs", as I won't actively pursue it further (afte=
r wavering=C2=A0on such a decision a bit during May / June).</div><div><br>=
</div><div>Few of the goals announced at that time were to build a consiste=
nt framework to evaluate covenant proposals, see the common grounds between=
proposals if they could be composed or combined=C2=A0by their authors, ope=
n the consensus=C2=A0 changes development process beyond the historical bou=
ndaries of Bitcoin Core and maintain=C2=A0high-quality technical archive as=
a consensus discussions have spawned half a decade from intellectual conce=
ption to activation in average (at least for segwit, schnorr, taproot).</di=
v><div><br></div><div>Such effort was a speak-by-the-act answer to the issu=
es in consensus=C2=A0development changes pointed out by Jeremy Rubin in Apr=
il of last year [1]: namely the lack of a "codified checklist" fo=
r consensus changes, that "consensus is memoryless" and "bit=
coin core is not bitcoin" (independently of the technical concerns as =
I have as limited or non-adequate primitive for vaults / payment pools I ex=
pressed during the same time). Other complementary initiatives have been un=
dertaken during the same period, AJ with the bitcoin-inquisition fork where=
the community of developers and contracting primitives of researchers on a=
consensus-enabled fork of core [2]. And Dave Harding with the careful arch=
iving of all covenant proposals under the Optech umbrella [3].</div><div><b=
r></div><div>About the Bitcoin Contracting Primitives WG, a Github reposito=
ry was started and maintained to archive and document all the primitives (a=
po, tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict, =
check_output_covenant_verify, inherited ids, anyamount, singletons, op_vaul=
t) and the corresponding protocols (payment pools, vaults, drivechains, tru=
st-minimized mining pools payouts). We had a total of 6 monthly meetings on=
the Libera chat #bitcoin-contracting-primitives-wg for a number of more th=
an 20 individual attendees representing most of the parts of the community.=
I think (missing march logs). Numerous in-depth discussions did happen on =
the repository and on the channel on things like "merkelized all the t=
hings" or "payment pools for miners payoffs".</div><div><br>=
</div><div>As I've been busy on the Lightning-side and other Bitcoin pr=
ojects, I've not run an online meeting since the month of April, while =
still having a bunch of fruitful technical discussions with folks involved =
in the effort at conferences and elsewhere. I launched the effort as an exp=
eriment with the soft commitment to dedicate 20% of my time on it, after fe=
w successful sessions I think such a process has an interest of its own, ho=
wever it comes with direct competition of my time to work on Lightning robu=
stness. Getting my hands dirty on low-level LDK development recently made m=
e realize we still have years of titan work to get a secure and reliable Li=
ghtning Network.</div><div><br></div><div>As such, between extended covenan=
t capabilities for advanced contracts coming as a reality for Bitcoin _or_ =
LN working smoothly at scale with 50-100M UTXO-sharing users on it during t=
he next 5-7 years cycle, I think the latter goal is more critical for Bitco=
in existential survival, and where on a personal title I'll allocate th=
e best of my time and energy (and somehow it match the "slow" tec=
hnical activity on bitcoin-inquisition mostly done by Lightning hands).</di=
v><div><br></div><div>This is my personal conclusion only on the state of B=
itcoin technological momentum, and this is quite tainted by my deep backgro=
und in Lightning development. If you've been working on covenant change=
s proposals, please don't take it as a discouragement, I think Taproot =
(privacy-preserving script policies behind the taproot tree branches) and S=
chnorr (for native multi-sig) soft forks have shown how it can improve the =
building of self-custody solutions by one or two order of magnitude, and sm=
all incremental changes might be good enough to have a lower technical cons=
ensus bar.</div><div><br></div><div>On my side, I'll pursue pure R&=
D works on CoinPool, notably coming with better solutions with the interact=
ivity issue and mass-compression of withdrawal and design exotic advanced B=
itcoin contracts based on the taproot annex, though more in a "l'a=
rt pour l'art" approach for the time being [4]. Additionally, I mi=
ght start to submit an in-depth security review of consensus changes under =
pseudonyms, it has already been done in the past and somehow it's good =
practice in terms of "message neutrality" [5]. If folks wanna exp=
eriment in terms of payment pools deployment, Greg Maxwell's old joinpo=
ol can be used today (and somehow it's worthy of its own as a net advan=
ce for coinjoins).</div><div><br></div><div>I'll honestly acknowledge t=
owards the community, I might have overpromised with the kickstart of this =
new process aiming to move the frontlines in matters of Bitcoin consensus c=
hanges development process. On the other hand, I think enough sessions of t=
he working group have been runned and enough marks of technical interests h=
ave been collected to demonstrate the minimal value of such a process, so I=
would estimate my open-source balance sheet towards the community to be in=
good standing ? (open-minded question).</div><div><br></div><div>I don'=
;t think Bitcoin fundamentally lacks compelling technical proposals to adva=
nce the capabilities of Bitcoin Script today, nor the crowd of seasoned and=
smart protocol developers to evaluate mature proposals end-to-end and on m=
ultiple dimensions with a spirit of independence. Rather, I believe what Bi=
tcoin is lacking is a small crowd of technical historians and archivist doi=
ng the work of assessing, collecting and preserving consensus changes propo=
sals and QA devs to ensure any consensus change proposals has world-class b=
attle-ground testing before to be considered for deployment, ideally with t=
he best standards of Bitcoin decentralization and FOSS neutrality [6].</div=
><div><br></div><div>If you would like to pursue the maintenance and nurtur=
ing of the Bitcoin Contracting Primitives WG (or the bitcoin-inquisition fo=
rk or collaborate with Optech to organize industry-wise workshop on covenan=
ts at the image of what has been done in 2019 for Taproot), that you're=
willing to show proof-of-work and you estimate that operational ground, le=
gal information or financial resources will anchor your individual work on =
the long-term, don't hesitate to reach out, I'll see what I can do =
with a disinterested mind [7].</div><div><br></div><div>With humility,</div=
><div>Antoine</div><div><br></div><div>[0]=C2=A0<a href=3D"https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html" target=3D"_b=
lank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020=
763.html</a></div><div>[1]=C2=A0<a href=3D"https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2022-April/020233.html" target=3D"_blank">https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html</a></=
div><div>[2]=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bi=
tcoin-dev/2022-September/020921.html" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-September/020921.html</a></div><d=
iv>[3]=C2=A0<a href=3D"https://github.com/bitcoinops/bitcoinops.github.io/p=
ull/806" target=3D"_blank">https://github.com/bitcoinops/bitcoinops.github.=
io/pull/806</a></div><div>[4] Version 0.2 of the CoinPool whitepaper addres=
sing most of the remaining "Big Problems" is still pending on my =
visit to co-author Gleb Naumenko in Ukraine, which has been postponed few t=
imes in light of the conflict operational evolutions.</div><div>[5] See=C2=
=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-=
February/017614.html" target=3D"_blank">https://lists.linuxfoundation.org/p=
ipermail/bitcoin-dev/2020-February/017614.html</a>. For the philosophical r=
easons of doing so, I invite you to read Foucault's famous essay "=
Le philosophe masque".</div><div>[6] Somehow I come to share Jeremy=
9;s thesis's "Product management is not "my Job" it'=
s yours" in matters of consensus changes. I believe we might be past t=
he technical complexity threshold where even simple consensus changes can b=
e conducted from A to Z as a one man job or even by a group of 2/3 elite de=
vs.</div><div>[7] I've been reached out multiple times and consistently=
by R&D non-profits, plebs whales and VC firms who were interested to c=
ommit resources=C2=A0to advance softforks and covenants in the Bitcoin spac=
e, no doubt when you're reliable and with a track record, folks are rea=
dy to offer you opportunities to work full-time on consensus changes.</div>=
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000082d26c0600dd1cfd--
|