summaryrefslogtreecommitdiff
path: root/6a/4e33e35a778418c5a897c08407a72d818c63c5
blob: 7b856756d8d4f8aca31dd4d8efb80abf0510827a (plain)
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
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6B29CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  7 Oct 2022 15:33:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 385A261189
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  7 Oct 2022 15:33:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 385A261189
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=adpIQKjS
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
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id FZ4zG6fdQRIS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  7 Oct 2022 15:33:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D15BB605B0
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com
 [IPv6:2607:f8b0:4864:20::d29])
 by smtp3.osuosl.org (Postfix) with ESMTPS id D15BB605B0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  7 Oct 2022 15:33:25 +0000 (UTC)
Received: by mail-io1-xd29.google.com with SMTP id 187so3877369iov.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 07 Oct 2022 08:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=TrRfvBWgXzGpjBJdaDNhrnVnfXtzlbfW4GwkoiMma/Y=;
 b=adpIQKjSA0CCqEPew4R0kz84H/PeWAq3QLGTdTBl2O6PosBitW+oNKA/iYtA/IAQqZ
 xlmjwTDLn9tn+ta9kzlfQtyu31UZsTalWCeLkR0FJ9eMhIOsuHapDFHbPIygNYzbi/ra
 EEAKytWro8EBaKKgfKpbb0OnJZE2m3qANLd1P5/ILxwjXAs19WnEBRAYdbLp2kbeeD5G
 zBdRS6cjaPU5/x7snQmoKCk4X9SkA3U7nbIvP9MXJ/KgFvR6aphEN3FHlkIsNMBZTBv5
 x2TcqJhy4bVH4SmJ7wHurmNAe9Ofthed+9fs0f9pREwEpnKhstEhYOaosdcVuhvV12JX
 ghcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=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=TrRfvBWgXzGpjBJdaDNhrnVnfXtzlbfW4GwkoiMma/Y=;
 b=CaITs6eeEfMWNsW8CKvAljdBfPdkjkZFBBXnW1ywkZ2syosr33JRP+OpNZXY1Y30be
 t4xqmMLNHjcLgs+SVzD2Rs5g/CP4KHB+8NXKUNQ4cAHNHzRD+yvnKN8jn9hz6ISOzH74
 JsNDvOuxlIEWk81Hq/8/5WYl4SDwpGdLxngxfuUPof0+Yj2W8P1gtB565ULyn9gE5dSB
 WzJVQLG5UWDRmnsNlMEkEOes17pFqse1jUjGFdbktro4sDlwDRLdr2WVGcGq64OMhSkr
 9aSgj/pDq83momt/7kaUDEaDGt8pSTO3aOA+CmhF5b6wZkfLA70IjdK8P/8gahDHIXe/
 1QyA==
X-Gm-Message-State: ACrzQf1cqJ0dn1uF+5VzqRdn6RWef57R6it4sF2i/tERxHskcE5SFnac
 jUCIIdbfmwkyVWW+SINAHWx0djbFcQXKCF7+aogQhAYya1Y=
X-Google-Smtp-Source: AMsMyM7hJ9qcSK3bicUEXCdofBdXYbWgWJ9TZ1ABT+UJY5AktKluxvmfHFmToMaxxFPx8cnjcE0fZEJC02ByJezaxYk=
X-Received: by 2002:a05:6638:1612:b0:35a:3f48:f3a3 with SMTP id
 x18-20020a056638161200b0035a3f48f3a3mr2690609jas.43.1665156804326; Fri, 07
 Oct 2022 08:33:24 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
In-Reply-To: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 7 Oct 2022 11:33:12 -0400
Message-ID: <CALZpt+HwBNZi67VfA5B+nyc3nQFWFHTnXJ1Csn+L4MgaFj6hqA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d13fec05ea73871e"
X-Mailman-Approved-At: Fri, 07 Oct 2022 15:36:42 +0000
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
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: Fri, 07 Oct 2022 15:33:28 -0000

--000000000000d13fec05ea73871e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

Following up my September's mail on the setting of a new decentralized,
open and neutral community process dedicated to covenants R&D, a.k.a
"Bitcoin Contracting Primitives WG", few updates.

After collecting feedback on the adequate communication channel, a low
access bar and pseudonymous participation sounds to be recurring criterias.
As such, I would like to propose using IRC on Libera Chat.

Opened the following chan:

#bitcoin-contracting-primitives-wg

If there are still strong likes for another communication channel, we can
still consider it.

For the 1st meeting date, I was thinking about the second week of November
starting the 7th. About the day and time, we have the following list of
Bitcoin open-source meetings happening across the ecosystem:
- Bitcoin Core general developer meeting Thursday 19:00 UTC
- Bitcoin Core wallet developer meeting Friday 19:00 UTC (every second week=
)
- Bitcoin Core PR review club Wednesday 17:00 UTC
- Lightning developer meeting Monday 20:00 UTC (bi-weekly, modulo weird
Australian timezones details that I don't understand)
- Core Lightning developer meeting Monday 20:00 UTC (every second week)
- LDK developer meeting Monday 17:00 UTC (every second week)
- LND PR review club Thursday 17:00 UTC (every second week)
- LDK PR review club Tuesday 18:00 UTC (every second week)
- DLC specs meeting Tuesday 19:00 CST (monthly)
- LSP specs meeting Wednesday 10:00 UTC (every second week)

This is a best effort to collect all the open-source engineering meetings
across the ecosystem, though we might have more, feel free to point out the
ones I'm forgetting.

Minding all those meetings happenings and all the time zones, the usual
times slots fitting most of the people are probably the ones between 16:00
UTC and 21:00 UTC.

Looking forward to collecting what would be a good time slot for the
happening of Bitcoin Contracting primitives WG.

For the meeting frequency, I think we can start with a monthly frequency,
then in function of the pace and sustained interest move to bi-weekly. No
agenda, we'll see how things are evolving unconf style.

In the process to collect and document all the known contracting protocol
use-cases at:
https://github.com/ariard/bitcoin-contracting-primitives-wg

So far I've bookmarked the following list:
- vaults
- payment pools
- channel factories
- drivechains
- eltoo channels
- decentralized mining pools
- scalable stateful contracts (e.g DLCs)
- congestion control redux
- non-interactive channels setups
- state channels

Though we're likely to see more emerge with time, feel free to point to the
ones I'm forgetting.

Recently, during a panel at a Bitcoin conference, I've been asked why such
a primitives working group rather than a specialized WG on the use-case I'm
mostly interested in (i.e payment pools). From my experience, the
contracting primitives or covenant you're designing is more likely to be a
function of the use-case properties you've in mind (e.g economic efficiency
or flexibility), however it might not generalize well to the other
contracting use-cases envisioned by a lot of other folks. One wishful
thinking of setting up this R&D effort could yield one common contracting
primitives toolchain servicing all the known use-cases. Though this is only
wishful thinking and we'll see what happens, in fine Bitcoin development is
kinda like jazz music, loosely structured, you launch the first few notes
and then you listen to what the other musicians keep going on.

Still open to more feedback on what the ideal Bitcoin contracting
primitives WG would look like.

Cheers,
Antoine

Le mer. 20 juil. 2022 =C3=A0 16:42, Antoine Riard <antoine.riard@gmail.com>=
 a
=C3=A9crit :

> Hi,
>
> Discussions on covenants have been prolific and intense on this mailing
> list and within the wider Bitcoin technical circles, I believe however
> without succeeding to reach consensus on any new set of contracting
> primitives satisfying the requirements of known covenant-enabled use-case=
s.
> I think that's a fact to deplore as covenants would not only offer vast
> extensions of the capabilities of Bitcoin as a system, i.e enabling new
> types of multi-party contract protocols. But also empowering Bitcoin on i=
ts
> fundamental value propositions of store of value (e.g by making vaults mo=
re
> flexible) and payment system (e.g by making realistic channel
> factories/payment pools).
>
> If we retain as a covenant definition, a spending constraint restricting
> the transaction to which the spent UTXO can be spent, and enabling to
> program contracts/protocols at the transaction-level instead of the
> script-level, the list of Script primitives proposed during the last year=
s
> has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1],
> CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4],
> PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROU=
P
> [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, a=
ll
> the listed primitives are at different states of formalization, some
> already fully fleshed-out in BIPs, other still ideas on whiteboard, yet
> they all extend the range of workable multi-party contract protocols.
>
> Indeed this range has grown wild. Without aiming to be exhaustive (I'm
> certainly missing some interesting proposals lost in the abyss of
> bitcointalk.org), we can mention the following use-cases: multi-party
> stateful contracts [11], congestion trees [12], payment pools [13], "elto=
o"
> layered commitments [14], programmable vaults [15], multi-events contract=
s
> [16], blockchain-as-oracle bets [17], spacechains [18], trustless
> collateral lending [19], ...
>
> Minding all those facts, I would say the task of technical evaluation of
> any covenant proposal sounds at least two fold. There is first reasoning
> about the enabled protocols on a range of criterias such as scalability,
> efficiency, simplicity, extensibility, robustness, data confidentiality,
> etc. Asking questions like what are the interactions between layers, if a=
ny
> ? Or how robust is the protocol, not just interactivity failure between
>  participant nodes but in the face of mempools spikes or internet
> disruption ? Or if the performance is still acceptable on shared resource=
s
> like blockspace or routing tables if everyone is using this protocol ? Or
> if the protocol minimizes regulatory attack surface or centralization
> vectors ?
>
> Though once this step is achieved, there is still more reasoning work to
> evaluate how good a fit is a proposed Script primitive, the
> efficiency/simplicity/ease to use trade-offs, but also if there are no
> functionality overlap or hard constraints on the use-cases design
> themselves or evolvability w.rt future Script extensions or generalizatio=
n
> of the opcode operations.
>
> Moreover, if you would like your evaluation of a covenant proposal to be
> complete, I don't believe you can squeeze the implications with the mempo=
ol
> rules and combination with any consistent fee-bumping strategy. To say
> things politely, those areas have been a quagmire of vulnerabilities,
> attacks and defects for second-layers Bitcoin protocols during the last
> years [20].
>
> Considering the abundant problem-space offered by covenants, I believe
> there is a reasonable groundwork to pursue in building the use-cases
> understanding (e.g prototype, pseudo-specification, documentation, ...) a=
nd
> building consensus on the framework of criterias on which to evaluate the=
m
> [21]. It might raise a really high bar for any covenant proposal compared
> to previous softforks, however I think it would adequately reflect the
> growth in Bitcoin complexity and funds at stakes during the last years.
>
> Moving towards this outcome, I would like to propose a new covenant open
> specification process, in the same spirit as we have with the BOLTs or
> dlcspecs. We would have regular meetings (biweekly/monthly ?), an open
> agenda where topics of discussion can be pinned in advance and
> documentation artifacts would be built with time driven by consensus (e.g
> 1st phase could be to collect, pseudo-specify and find champion(s) for
> known use-cases ?) and no timeframe. Starting date could be September /
> October / November (later, 2023 ?), giving time for anyone interested in
> such a covenant process to allocate development and contribution bandwidt=
h
> in function of their involvement interest.
>
> Learning from the good but specially from the bad with setting up the L2
> onchain support meetings last year, I think it would be better to keep th=
e
> agenda open, loose and free as much we can in a "burn-the-roadmap" spirit=
,
> avoiding to create a sense of commitment or perceived signaling in the
> process participants towards any covenant solution. I would guess things =
to
> be experimental and evolutionary and folks to spend the first meetings
> actually to express what they would like the covenant process to be about
> (and yes that means if you're a domain expert and you find the pace of
> things too slow sometimes, you have to learn to handle your own
> frustration...).
>
> In a "decentralize-everything" fashion, I believe it would be good to hav=
e
> rotating meeting chairs and multiple covenant documentation archivists. I=
'm
> super happy to spend the time and energy bootstrapping well such covenant
> process effort, though as it's Bitcoin learn to decentralize yourself.
>
> I'm really curious what the outcome of such a covenant process would look
> like. We might end up concluding that complex covenants are too unsafe by
> enabling sophisticated MEV-attacks against LN [22]. Or even if there is a=
n
> emergent technical consensus, it doesn't mean there is a real market
> interest for such covenant solutions. That said, I'm not sure if it's
> really a subject of concern when you're reasoning as a scientist/engineer
> and you value technical statements in terms of accuracy, systematic
> relevance and intrinsic interest.
>
> Overall, my motivation to kick-start such a process stays in the fact tha=
t
> covenants are required building blocks to enable scalable payments pools
> design like CoinPool. I believe payments pools are a) cool and b) a good
> shot at scaling Bitcoin as a payment system once we have reached
> scalability limits of Lightning, still under the same security model for
> users. However, as a community we might sense it's not the good timing fo=
r
> a covenant process. I'm really fine with that outcome as there are still
> holes to patch in LN to keep me busy enough for the coming years.
>
> Zooming out, I believe with any discussion about covenants or other soft
> forks, the hard part isn't about coming up with the best technical soluti=
on
> to a set of problems but in the iterative process where all voices are
> listened to reach (or not) consensus on what is actually meant by "best"
> and if the problems are accurate. The real physics of Bitcoin is the
> physics of people. It's a work of patience.
>
> Anyways, eager to collect feedbacks on what the ideal covenant
> specification process looks like. As usual, all opinions and mistakes are
> my own.
>
> Cheers,
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [1] https://bitcoinops.org/en/topics/op_checksigfromstack/
> [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [3]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/01=
9419.html
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198=
13.html
> [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
> [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019=
926.html
> [8]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015=
700.html
> [9]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.=
html
> [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198=
08.html
> [12]
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion=
_Controlled_Transactions
> [13]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.=
html
> [14]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00=
2448.html
> [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
> [16]
> https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
> [17] https://blog.bitmex.com/taproot-you-betcha/
> [18]
> https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spac=
echains
> [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
> [20] https://github.com/jamesob/mempool.work
> [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [22] https://blog.bitmex.com/txwithhold-smart-contracts/
>

--000000000000d13fec05ea73871e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>Following up my September&#39;s mail on the=
 setting of a new decentralized, open and neutral community process dedicat=
ed to covenants R&amp;D, a.k.a &quot;Bitcoin Contracting Primitives WG&quot=
;, few updates.<br><br>After collecting feedback on the adequate communicat=
ion channel, a low access bar and pseudonymous participation sounds to be r=
ecurring criterias. As such, I would like to propose using IRC on Libera Ch=
at.<br><br>Opened the following chan:<br><br>#bitcoin-contracting-primitive=
s-wg<br><br>If there are still strong likes for another communication chann=
el, we can still consider it.<br><br>For the 1st meeting date, I was thinki=
ng about the second week of November starting the 7th. About the day and ti=
me, we have the following list of Bitcoin open-source meetings happening ac=
ross the ecosystem:<br>- Bitcoin Core general developer meeting Thursday 19=
:00 UTC<br>- Bitcoin Core wallet developer meeting Friday 19:00 UTC (every =
second week)<br>- Bitcoin Core PR review club Wednesday 17:00 UTC<br>- Ligh=
tning developer meeting Monday 20:00 UTC (bi-weekly, modulo weird Australia=
n timezones details that I don&#39;t understand)<br>- Core Lightning develo=
per meeting Monday 20:00 UTC (every second week)<br>- LDK developer meeting=
 Monday 17:00 UTC (every second week)<br>- LND PR review club Thursday 17:0=
0 UTC (every second week)<br>- LDK PR review club Tuesday 18:00 UTC (every =
second week)<br>- DLC specs meeting Tuesday 19:00 CST (monthly)<br>- LSP sp=
ecs meeting Wednesday 10:00 UTC (every second week)<br><br>This is a best e=
ffort to collect all the open-source engineering meetings across the ecosys=
tem, though we might have more, feel free to point out the ones I&#39;m for=
getting.<br><br>Minding all those meetings happenings and all the time zone=
s, the usual times slots fitting most of the people are probably the ones b=
etween 16:00 UTC and 21:00 UTC.<br><br>Looking forward to collecting what w=
ould be a good time slot for the happening of Bitcoin Contracting primitive=
s WG.<br><br>For the meeting frequency, I think we can start with a monthly=
 frequency, then in function of the pace and sustained interest move to bi-=
weekly. No agenda, we&#39;ll see how things are evolving unconf style.<br><=
br>In the process to collect and document all the known contracting protoco=
l use-cases at:<br><a href=3D"https://github.com/ariard/bitcoin-contracting=
-primitives-wg">https://github.com/ariard/bitcoin-contracting-primitives-wg=
</a><br><br>So far I&#39;ve bookmarked the following list:<br>- vaults<br>-=
 payment pools<br>- channel factories<br>- drivechains<br>- eltoo channels<=
br>- decentralized mining pools<br>- scalable stateful contracts (e.g DLCs)=
<br>- congestion control redux<br>- non-interactive channels setups<br>- st=
ate channels<br><br>Though we&#39;re likely to see more emerge with time, f=
eel free to point to the ones I&#39;m forgetting.<br><br>Recently, during a=
 panel at a Bitcoin conference, I&#39;ve been asked why such a primitives w=
orking group rather than a specialized WG on the use-case I&#39;m mostly in=
terested in (i.e payment pools). From my experience, the contracting primit=
ives or covenant you&#39;re designing is more likely to be a function of th=
e use-case properties you&#39;ve in mind (e.g economic efficiency or flexib=
ility), however it might not generalize well to the other contracting use-c=
ases envisioned by a lot of other folks. One wishful thinking of setting up=
 this R&amp;D effort could yield one common contracting primitives toolchai=
n servicing all the known use-cases. Though this is only wishful thinking a=
nd we&#39;ll see what happens, in fine Bitcoin development is kinda like ja=
zz music, loosely structured, you launch the first few notes and then you l=
isten to what the other musicians keep going on.<br><br>Still open to more =
feedback on what the ideal Bitcoin contracting primitives WG would look lik=
e.<br><br>Cheers,<br>Antoine<br></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 20 juil. 2022 =C3=A0=C2=A016:4=
2, Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">antoine.ria=
rd@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr">Hi,<br><br>Discussions on covenan=
ts have been prolific and intense on this mailing list and within the wider=
 Bitcoin technical circles, I believe however without succeeding to reach c=
onsensus on any new set of contracting primitives satisfying the requiremen=
ts of known covenant-enabled use-cases. I think that&#39;s a fact to deplor=
e as covenants would not only offer vast extensions of the capabilities of =
Bitcoin as a system, i.e enabling new types of multi-party contract protoco=
ls. But also empowering Bitcoin on its fundamental value propositions of st=
ore of value (e.g by making vaults more flexible) and payment system (e.g b=
y making realistic channel factories/payment pools).<br><br>If we retain as=
 a covenant definition, a spending constraint restricting the transaction t=
o which the spent UTXO can be spent, and enabling to program contracts/prot=
ocols at the transaction-level instead of the script-level, the list of Scr=
ipt primitives proposed during the last years has grown large : ANYPREVOUT =
[0], CHECKSIGFROMSTACK [1], CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_=
VERIFY [3], TXHASH [4], PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delega=
tion [8], SIGHASH_GROUP [9], MERKLEBRANCHVERIFY [10] and more than I can&#3=
9;t remember. Of course, all the listed primitives are at different states =
of formalization, some already fully fleshed-out in BIPs, other still ideas=
 on whiteboard, yet they all extend the range of workable multi-party contr=
act protocols.<br><br>Indeed this range has grown wild. Without aiming to b=
e exhaustive (I&#39;m certainly missing some interesting proposals lost in =
the abyss of <a href=3D"http://bitcointalk.org" target=3D"_blank">bitcointa=
lk.org</a>), we can mention the following use-cases: multi-party stateful c=
ontracts [11], congestion trees [12], payment pools [13], &quot;eltoo&quot;=
 layered commitments [14], programmable vaults [15], multi-events contracts=
 [16], blockchain-as-oracle bets [17], spacechains [18], trustless collater=
al lending [19], ...<br><br>Minding all those facts, I would say the task o=
f technical evaluation of any covenant proposal sounds at least two fold. T=
here is first reasoning about the enabled protocols on a range of criterias=
 such as scalability, efficiency, simplicity, extensibility, robustness, da=
ta confidentiality, etc. Asking questions like what are the interactions be=
tween layers, if any ? Or how robust is the protocol, not just interactivit=
y failure between =C2=A0participant nodes but in the face of mempools spike=
s or internet disruption ? Or if the performance is still acceptable on sha=
red resources like blockspace or routing tables if everyone is using this p=
rotocol ? Or if the protocol minimizes regulatory attack surface or central=
ization vectors ?<br><br>Though once this step is achieved, there is still =
more reasoning work to evaluate how good a fit is a proposed Script primiti=
ve, the efficiency/simplicity/ease to use trade-offs, but also if there are=
 no functionality overlap or hard constraints on the use-cases design thems=
elves or evolvability w.rt future Script extensions or generalization of th=
e opcode operations.<br><br>Moreover, if you would like your evaluation of =
a covenant proposal to be complete, I don&#39;t believe you can squeeze the=
 implications with the mempool rules and combination with any consistent fe=
e-bumping strategy. To say things politely, those areas have been a quagmir=
e of vulnerabilities, attacks and defects for second-layers Bitcoin protoco=
ls during the last years [20].<br><br>Considering the abundant problem-spac=
e offered by covenants, I believe there is a reasonable groundwork to pursu=
e in building the use-cases understanding (e.g prototype, pseudo-specificat=
ion, documentation, ...) and building consensus on the framework of criteri=
as on which to evaluate them [21]. It might raise a really high bar for any=
 covenant proposal compared to previous softforks, however I think it would=
 adequately reflect the growth in Bitcoin complexity and funds at stakes du=
ring the last years.<br><br>Moving towards this outcome, I would like to pr=
opose a new covenant open specification process, in the same spirit as we h=
ave with the BOLTs or dlcspecs. We would have regular meetings (biweekly/mo=
nthly ?), an open agenda where topics of discussion can be pinned in advanc=
e and documentation artifacts would be built with time driven by consensus =
(e.g 1st phase could be to collect, pseudo-specify and find champion(s) for=
 known use-cases ?) and no timeframe. Starting date could be September / Oc=
tober / November (later, 2023 ?), giving time for anyone interested in such=
 a covenant process to allocate development and contribution bandwidth in f=
unction of their involvement interest. <br><br>Learning from the good but s=
pecially from the bad with setting up the L2 onchain support meetings last =
year, I think it would be better to keep the agenda open, loose and free as=
 much we can in a &quot;burn-the-roadmap&quot; spirit, avoiding to create a=
 sense of commitment or perceived signaling in the process participants tow=
ards any covenant solution. I would guess things to be experimental and evo=
lutionary and folks to spend the first meetings actually to express what th=
ey would like the covenant process to be about (and yes that means if you&#=
39;re a domain expert and you find the pace of things too slow sometimes, y=
ou have to learn to handle your own frustration...).<br><br>In a &quot;dece=
ntralize-everything&quot; fashion, I believe it would be good to have rotat=
ing meeting chairs and multiple covenant documentation archivists. I&#39;m =
super happy to spend the time and energy bootstrapping well such covenant p=
rocess effort, though as it&#39;s Bitcoin learn to decentralize yourself.<b=
r><br>I&#39;m really curious what the outcome of such a covenant process wo=
uld look like. We might end up concluding that complex covenants are too un=
safe by enabling sophisticated MEV-attacks against LN [22]. Or even if ther=
e is an emergent technical consensus, it doesn&#39;t mean there is a real m=
arket interest for such covenant solutions. That said, I&#39;m not sure if =
it&#39;s really a subject of concern when you&#39;re reasoning as a scienti=
st/engineer and you value technical statements in terms of accuracy, system=
atic relevance and intrinsic interest.<br><br>Overall, my motivation to kic=
k-start such a process stays in the fact that covenants are required buildi=
ng blocks to enable scalable payments pools design like CoinPool. I believe=
 payments pools are a) cool and b) a good shot at scaling Bitcoin as a paym=
ent system once we have reached scalability limits of Lightning, still unde=
r the same security model for users. However, as a community we might sense=
 it&#39;s not the good timing for a covenant process. I&#39;m really fine w=
ith that outcome as there are still holes to patch in LN to keep me busy en=
ough for the coming years.<br><br>Zooming out, I believe with any discussio=
n about covenants or other soft forks, the hard part isn&#39;t about coming=
 up with the best technical solution to a set of problems but in the iterat=
ive process where all voices are listened to reach (or not) consensus on wh=
at is actually meant by &quot;best&quot; and if the problems are accurate. =
The real physics of Bitcoin is the physics of people. It&#39;s a work of pa=
tience.<br><br>Anyways, eager to collect feedbacks on what the ideal covena=
nt specification process looks like. As usual, all opinions and mistakes ar=
e my own.<br><br>Cheers,<br>Antoine<br><br>[0] <a href=3D"https://github.co=
m/bitcoin/bips/blob/master/bip-0118.mediawiki" target=3D"_blank">https://gi=
thub.com/bitcoin/bips/blob/master/bip-0118.mediawiki</a><br>[1] <a href=3D"=
https://bitcoinops.org/en/topics/op_checksigfromstack/" target=3D"_blank">h=
ttps://bitcoinops.org/en/topics/op_checksigfromstack/</a><br>[2] <a href=3D=
"https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki" target=3D"=
_blank">https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki</a><=
br>[3] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
021-September/019419.html" target=3D"_blank">https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2021-September/019419.html</a><br>[4] <a href=3D"=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813=
.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoi=
n-dev/2022-January/019813.html</a><br>[5] <a href=3D"https://github.com/jl2=
012/bips/blob/vault/bip-0ZZZ.mediawiki" target=3D"_blank">https://github.co=
m/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki</a><br>[6] <a href=3D"https://m=
edium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298" target=3D"_bla=
nk">https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298</a=
><br>[7] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2022-February/019926.html" target=3D"_blank">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-February/019926.html</a><br>[8] <a href=3D"=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/01570=
0.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitco=
in-dev/2018-February/015700.html</a><br>[9] <a href=3D"https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2021-July/019243.html" target=3D"_blank=
">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.=
html</a><br>[10] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip=
-0116.mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/mas=
ter/bip-0116.mediawiki</a><br>[11] <a href=3D"https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-January/019808.html" target=3D"_blank">http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.htm=
l</a><br>[12] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-01=
19.mediawiki#Congestion_Controlled_Transactions" target=3D"_blank">https://=
github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlle=
d_Transactions</a><br>[13] <a href=3D"https://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2020-June/017964.html" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html</a><br>[14] =
<a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-J=
anuary/002448.html" target=3D"_blank">https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2020-January/002448.html</a><br>[15] <a href=3D"http:/=
/fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf" target=3D"_blank">http:=
//fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf</a><br>[16] <a href=3D"=
https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf" t=
arget=3D"_blank">https://github.com/ariard/talk-slides/blob/master/advanced=
-contracts.pdf</a><br>[17] <a href=3D"https://blog.bitmex.com/taproot-you-b=
etcha/" target=3D"_blank">https://blog.bitmex.com/taproot-you-betcha/</a><b=
r>[18] <a href=3D"https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acc=
ed61ca9f49a#spacechains" target=3D"_blank">https://gist.github.com/RubenSom=
sen/c9f0a92493e06b0e29acced61ca9f49a#spacechains</a> <br>[19] <a href=3D"ht=
tps://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef" target=
=3D"_blank">https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb83=
5fcef</a><br>[20] <a href=3D"https://github.com/jamesob/mempool.work" targe=
t=3D"_blank">https://github.com/jamesob/mempool.work</a><br>[21] <a href=3D=
"https://github.com/bitcoinops/bitcoinops.github.io/pull/806" target=3D"_bl=
ank">https://github.com/bitcoinops/bitcoinops.github.io/pull/806</a><br>[22=
] <a href=3D"https://blog.bitmex.com/txwithhold-smart-contracts/" target=3D=
"_blank">https://blog.bitmex.com/txwithhold-smart-contracts/</a><br></div>
</blockquote></div>

--000000000000d13fec05ea73871e--