Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2468CC0032 for ; Thu, 20 Jul 2023 06:12:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id DCB0A40198 for ; Thu, 20 Jul 2023 06:12:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DCB0A40198 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=PRqxRztr 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp0ZUJ-gdax3 for ; Thu, 20 Jul 2023 06:12:10 +0000 (UTC) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by smtp2.osuosl.org (Postfix) with ESMTPS id 305E5400D2 for ; Thu, 20 Jul 2023 06:12:10 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 305E5400D2 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-51e2a6a3768so491482a12.0 for ; Wed, 19 Jul 2023 23:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689833528; x=1690438328; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0UpUWbSSGTlSWFdo/sqSoZhMlTswPNB0TGjqIC3dTz0=; b=PRqxRztr0bRtrV2DHpjNgaURyM9nPFSump/F6IEQgKUSkH3aGH9xl7eIQtJtWs/fnS 0f6LebrkPVAzRo0qYoNmzIF3qs9ACqvqYcAEqois4oe7EK8Y9N6JWpelstreBPATfOT2 0SjQklQVfsNU6TVaU8+PCQU3BlAEjTZ0n5Av1ZJYQomrhF3IrvSYlch2m7U+I4UIhOeD JDzmC809n1JCe57rPdiw9QAOur2LH0A8MUuF3ixEUIAd02UtnA6KTUwl3op57+QvVKRO hjUsbBULyUZQ+jWF8oU2AVQBryL0qT6DAf2fH6P5IZFaXAMDstI0HIhNNUs47IbHxdCC b9Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689833528; x=1690438328; 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=0UpUWbSSGTlSWFdo/sqSoZhMlTswPNB0TGjqIC3dTz0=; b=hongqppqO1qA6vqG/Yb2RB4to0JmhpB3DTBEFCAdCoAknyjXKAX33Gb2s0tu8aUtcB zf146hkVtGP0rrYGXwPS8cnJlt1jUwlAlBdarGXRTalpeeDsvXCcJWXDki/sa94dZPwP t/H15ZNwVOUjyyIY6ScqO0178RPMwr7Fr+XthNzCkj2neJpoTrY6R6mgc9TgRlKsAjiK MHtEZBBemnDtc2d2dO14RB2wtYjE/p0v6rKrQ4ZGZ8k51DPKrITr94QelCSPGy0/tW5c Wnaw+y8Yk6qN/hVtFkRhK+btyjis+a/V8mnZ3xPFJE525SvS/ft3AShcAh5lTcZV7cQW wh3A== X-Gm-Message-State: ABy/qLbRuV1fJcGDrqHEjGr8lZaJ6/kSJKu7w8MFYwBVBwpKJ26TElUi Lju7yP5H/N4ryCqybhVIMQuQwKyRY76XUJVvoGpm6rbm X-Google-Smtp-Source: APBJJlGnCB6F7ml4WoPlQV0JWrCdxTHZ+sLeCO5rXU28WSxumquPpk0jUq4ppUfyc78eiwKjlTqn1hQxKpdaBujH7u0= X-Received: by 2002:a17:906:77c8:b0:99b:445d:45d0 with SMTP id m8-20020a17090677c800b0099b445d45d0mr2822650ejn.66.1689833527858; Wed, 19 Jul 2023 23:12:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Thu, 20 Jul 2023 02:11:57 -0400 Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="000000000000285b420600e50735" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2023 06:12:13 -0000 --000000000000285b420600e50735 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi antoine, Simplicity was just a stand in for "functionally complete" handwave. Cheers, Greg On Thu, Jul 20, 2023, 1:46 AM Antoine Riard wrote= : > Hi Greg, > > I'm very meeting your development approach with regards to starting small= s > about consensus change primitives, and I think taproot has demonstrated > some good historical process, which has good archives about how developme= nt > was conducted (e.g the community-wide taproot review of which the Bitcoin > Contracting Primitives WG was built on this experience [0]). > > I don't know about saying that the BOLTs (and its process) should be > authoritative over the running code of implementations. While it's > definitely a mark of some bar of technical review and inter-compatibility= , > I think ultimately each BOLT has to be judged individually on its own > technical merits. And I think we had a bunch of cases in the past when "t= he > map is not the territory". Even there are few areas of critical Lightning > operations which are not documented by the BOLTs to the best of my > knowledge (such as fee-bumping and transactions broadcast reactions as it > was for on-chain DLCs [1]). > > Lastly, there is a huge area of uncertainty about the technical fitness o= f > Simplicity for 2/small party channels. I remember a Russell O'connor > presentation about Simplicity back in Paris (2017 or 2018 ?) and asking h= im > how it would work in a chain of transactions, while the answer was iirc > "yes it has been designed with this constraint", it's a very open questio= n > when you have off-chain states which advances in independence from the > on-chain state between a dynamic number of counterparties (kinda the > interactivity issue for payment pools). Here I guess you would have to co= me > to a consensus to the model of logic followed for the analysis of such > distributed systems e.g Leslie Lamport's temporal logic [2]. Additionally= , > the theoretical foundations on the Coq prover are still actively studied = by > Xavier Leroy at the College de France and some novel insights might be > interesting for using formal verification in terms of Bitcoin consensus > changes development (and I don't know if all the works and lessons have > been translated from French to English). > > Best, > Antoine > > [0] https://github.com/ajtowns/taproot-review > [1] > https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interact= ive-Protocol.md > [2] https://en.wikipedia.org/wiki/Temporal_logic_of_actions > > Le mer. 19 juil. 2023 =C3=A0 21:45, Greg Sanders a > =C3=A9crit : > >> 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 mor= e >> 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'r= e >> going to have to convince LN spec writers to include such changes, whate= ver >> 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 bein= g >> concrete by writing specs that use a primitive, and code it up to discov= er >> 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 Simplici= ty, >> 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-de= v < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> Hi Antoine, >>> >>> Thank you for the effort you've put towards this. I generally agree tha= t >>> a smooth functioning Lightning Network is of greater importance than >>> advanced 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 ha= ve 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 sh= ould >>> 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 neces= sary >>> and inevitable if Bitcoin is to survive in the long term. However, as I= 've >>> 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 a= reas >>> of focus on LN preclude you from splitting your attention and none of t= his >>> email should be interpreted as a criticism of you applying your efforts= in >>> 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= two >>> 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 >>>> intense conversations about a rainbow of covenant proposals, I introdu= ced >>>> the idea of a new community process to specify covenants [0]. This pos= t is >>>> to resume the experiment so far and officially mark the process mainte= nance >>>> as "up for grabs", as I won't actively pursue it further (after waveri= ng on >>>> such 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 betwe= en >>>> proposals if they could be composed or combined by their authors, open= the >>>> consensus changes development process beyond the historical boundarie= s of >>>> Bitcoin Core and maintain high-quality technical archive as a consensu= s >>>> 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 = last >>>> year [1]: namely the lack of a "codified checklist" for consensus chan= ges, >>>> 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 t= he >>>> same time). Other complementary initiatives have been undertaken durin= g the >>>> same period, AJ with the bitcoin-inquisition fork where the community = of >>>> developers and contracting primitives of researchers on a consensus-en= abled >>>> 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= for >>>> a number of more than 20 individual attendees representing most of the >>>> parts of the community. I think (missing march logs). Numerous in-dept= h >>>> discussions did happen on the repository and on the channel on things = like >>>> "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 h= aving >>>> a bunch of fruitful technical discussions with folks involved in the e= ffort >>>> at conferences and elsewhere. I launched the effort as an experiment w= ith >>>> the soft commitment to dedicate 20% of my time on it, after few succes= sful >>>> 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 robustne= ss. >>>> 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 th= ink >>>> 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 >>>> technological momentum, and this is quite tainted by my deep backgroun= d in >>>> Lightning development. If you've been working on covenant changes >>>> proposals, please don't take it as a discouragement, I think Taproot >>>> (privacy-preserving script policies behind the taproot tree branches) = and >>>> Schnorr (for native multi-sig) soft forks have shown how it can improv= e the >>>> building of self-custody solutions by one or two order of magnitude, a= nd >>>> small incremental changes might be good enough to have a lower technic= al >>>> consensus bar. >>>> >>>> On my side, I'll pursue pure R&D works on CoinPool, notably coming wit= h >>>> 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 ti= me >>>> being [4]. Additionally, I might 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 neutralit= y" >>>> [5]. If folks wanna experiment in terms of payment pools deployment, G= reg >>>> Maxwell's old joinpool can be used today (and somehow it's worthy of i= ts >>>> 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 m= y >>>> 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 cro= wd of >>>> technical historians and archivist doing the work of assessing, collec= ting >>>> and preserving consensus changes proposals and QA devs to ensure any >>>> consensus change proposals has world-class battle-ground testing befor= e to >>>> be considered for deployment, ideally with the best standards of Bitco= in >>>> 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 >>>> collaborate with Optech to organize industry-wise workshop on covenant= s at >>>> the image of what has been done in 2019 for Taproot), that you're will= ing >>>> to show proof-of-work and you estimate that operational ground, legal >>>> 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]. >>>> >>>> With humility, >>>> Antoine >>>> >>>> [0] >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/0207= 63.html >>>> [1] >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020= 233.html >>>> [2] >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September= /020921.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 Gle= b >>>> Naumenko in Ukraine, which has been postponed few times in light of th= e >>>> conflict operational evolutions. >>>> [5] See >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/= 017614.html. >>>> For the philosophical reasons of doing so, I invite you to read Foucau= lt'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 changes can be conducted from A to Z as a one man job or eve= n 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 = doubt >>>> when you're reliable and with a track record, folks are ready to offer= you >>>> 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 >>> >> --000000000000285b420600e50735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi antoine,

= Simplicity was just a stand in for "functionally complete" handwa= ve.=C2=A0

Cheers,
<= div dir=3D"auto">Greg

On Thu, Jul 20, 2023, 1:46 AM Antoine Riard <= antoine.riard@gmail.com> = wrote:
Hi Greg,
I'm very meeting your development approach with regard= s to starting smalls about consensus change primitives, and I think taproot= has demonstrated some good historical process, which has good archives abo= ut how development was conducted (e.g the community-wide taproot review of = which the Bitcoin Contracting Primitives WG was built on this experience [0= ]).

I don't know about saying that the BOLTs (= and its process) should=C2=A0be authoritative over the running=C2=A0code of= implementations. While it's definitely=C2=A0a mark of some bar of tech= nical review and inter-compatibility, I think ultimately each BOLT has to b= e judged individually on its own technical merits. And I think we had a bun= ch of cases in the past when "the map is not the territory". Even= there are few areas of critical Lightning operations which are not documen= ted by the BOLTs to the best of my knowledge (such as fee-bumping and trans= actions broadcast reactions as it was for on-chain DLCs [1]).
Lastly, there is a huge area of uncertainty about the technical= fitness of Simplicity for 2/small party channels. I remember a Russell O&#= 39;connor presentation about Simplicity back in Paris (2017 or 2018 ?) and = asking him how it would work in a chain of transactions, while the answer w= as iirc "yes it has been designed with this constraint", it's= a very open question when you have off-chain states which advances in inde= pendence from the on-chain state between a dynamic number of counterparties= (kinda the interactivity issue for payment pools). Here I guess you would = have to come to a consensus to the model of logic followed for the analysis= of such distributed systems e.g Leslie Lamport's temporal logic [2]. A= dditionally, the theoretical foundations on the Coq prover are still active= ly studied by Xavier Leroy at the College de France and some novel insights= might be interesting for using formal verification in terms of Bitcoin con= sensus changes development (and I don't know if all the works and lesso= ns have been translated from French to English).

B= est,
Antoine

<= div>[2]=C2=A0https://en.wikipedia.org/wiki/Te= mporal_logic_of_actions

Le=C2=A0mer. 19 juil. 2023 =C3=A0=C2=A021:= 45, Greg Sanders <gsanders87@gmail.com> a =C3=A9crit=C2=A0:
=
Hello Keagen,

Mo= st 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 tha= n CTV to get significant gains. And in the end, channels can only get so si= mple 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, whateve= r they are, then get deployment.

Step 1 is finding= a primitive that seems interesting. It's important to moderate enthusi= asm for any primitive with reality, and probably by being concrete by writi= ng specs that use a primitive, and code it up to discover what we're ov= erlooking. We're always overlooking something! In my humble opinion the= se=C2=A0are step=C2=A02 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 acco= mplish this within the confines of bitcoin script?=C2=A0

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 t= owards this. I generally agree that a smooth functioning Lightning Network = is of greater importance than advanced contracting capabilities. However, a= s 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 fam= iliar 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 wel= l. Others should chime in if they can confirm this claim.

I have been publicly on the record as supporting the addition of so= me covenant scheme into Bitcoin for some time and have long held on theoret= ical grounds that the addition of such a mechanism is both necessary and in= evitable if Bitcoin is=C2=A0to survive in the long term. However, as I'= ve started to work more directly with the Lightning protocol, these theoret= ical 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 ve= ry well be 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 yo= u applying your efforts in the highest leverage manner you=C2=A0can manage.= That said, I don't want observers of this thread to walk away with the= impression that they are two independent efforts as covenants can signific= antly contribute to LN's maturity. When and how should they be prioriti= zed? Unfortunately I don't feel able to comment on that at this time. A= ll I know is that Lightning would almost certainly benefit substantially fr= om having a covenant primitive.

Cheers,
= Keags

On Tue, Jul 18, 2023 at 3:40=E2=80=AFPM Antoine Riard via bitcoi= n-dev <bitcoin-dev@lists.linuxfoundation.org>= ; wrote:
Hi list,

=
Last year amid the failure of the CTV speedy trial activation and inte= nse conversations about a rainbow of covenant proposals, I introduced the i= dea of a new community process to specify covenants [0]. This post is to re= sume the experiment so far and officially mark the process maintenance as &= quot;up for grabs", as I won't actively pursue it further (after w= avering=C2=A0on such 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 pr= oposals if they could be composed or combined=C2=A0by their authors, open t= he consensus=C2=A0 changes development process beyond the historical bounda= ries of Bitcoin Core and maintain=C2=A0high-quality technical archive as a = consensus discussions have spawned half a decade from intellectual concepti= on to activation in average (at least for segwit, schnorr, taproot).
<= div>
Such effort was a speak-by-the-act answer to the issues = in consensus=C2=A0development changes pointed out by Jeremy Rubin in April = of last year [1]: namely the lack of a "codified checklist" for c= onsensus changes, that "consensus is memoryless" and "bitcoi= n core is not bitcoin" (independently of the technical concerns as I h= ave as limited or non-adequate primitive for vaults / payment pools I expre= ssed during the same time). Other complementary initiatives have been under= taken during the same period, AJ with the bitcoin-inquisition fork where th= e community of developers and contracting primitives of researchers on a co= nsensus-enabled fork of core [2]. And Dave Harding with the careful archivi= ng of all covenant proposals under the Optech umbrella [3].

<= /div>
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, che= ck_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 th= e Libera chat #bitcoin-contracting-primitives-wg for 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 like "merkelized all the thin= gs" or "payment pools for miners payoffs".

As I've been busy on the Lightning-side and other Bitcoin proje= cts, I've not run an online meeting since the month of April, while sti= ll having a bunch of fruitful technical discussions with folks involved in = the effort at conferences and elsewhere. I launched the effort as an experi= ment with the soft commitment to dedicate 20% of my time on it, after few s= uccessful sessions I think such a process has an interest of its own, howev= er it comes with direct competition of my time to work on Lightning robustn= ess. Getting my hands dirty on low-level LDK development recently made me r= ealize we still have years of titan work to get a secure and reliable Light= ning Network.

As such, between extended covenant c= apabilities 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 think the latter goal is more critical for Bitcoin = existential survival, and where on a personal title I'll allocate the b= est of my time and energy (and somehow it match the "slow" techni= cal activity on bitcoin-inquisition mostly done by Lightning hands).
<= div>
This is my personal conclusion only on the state of Bitc= oin technological momentum, and this is quite tainted by my deep background= in Lightning development. If you've been working on covenant changes p= roposals, please don't take it as a discouragement, I think Taproot (pr= ivacy-preserving script policies behind the taproot tree branches) and Schn= orr (for native multi-sig) soft forks have shown how it can improve the bui= lding of self-custody solutions by one or two order of magnitude, and small= incremental changes might be good enough to have a lower technical consens= us bar.

On my side, I'll pursue pure R&D w= orks on CoinPool, notably coming with better solutions with the interactivi= ty issue and mass-compression of withdrawal and design exotic advanced Bitc= oin 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 pse= udonyms, it has already been done in the past and somehow it's good pra= ctice in terms of "message neutrality" [5]. If folks wanna experi= ment in terms of payment pools deployment, Greg 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 towa= rds the community, I might have overpromised with the kickstart of this new= process aiming to move the frontlines in matters of Bitcoin consensus chan= ges 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 wo= uld estimate my open-source balance sheet towards the community to be in go= od 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 sm= art protocol developers to evaluate mature proposals end-to-end and on mult= iple dimensions with a spirit of independence. Rather, I believe what Bitco= in is lacking is a small crowd of technical historians and archivist doing = the work of assessing, collecting and preserving consensus changes proposal= s and QA devs to ensure any consensus change proposals has world-class batt= le-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 collaborate with Optech to organize industry-wise workshop on covenants = at the image of what has been done in 2019 for Taproot), that you're wi= lling to show proof-of-work and you estimate that operational ground, legal= 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 wit= h a disinterested mind [7].

With humility,
Antoine

[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.
[5] See=C2= =A0https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.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 "m= y Job" it's yours" in matters of consensus changes. I believe= we might be past the technical complexity threshold where even simple cons= ensus changes can be conducted from A to Z as a one man job or even by a gr= oup of 2/3 elite devs.
[7] I've been reached out multiple tim= es and consistently by R&D non-profits, plebs whales and VC firms who w= ere interested to commit resources=C2=A0to advance softforks and covenants = in the Bitcoin space, no doubt when you're reliable and with a track re= cord, folks are ready to offer you opportunities to work full-time on conse= nsus changes.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000285b420600e50735--