Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 26087C0032 for ; Thu, 20 Jul 2023 05:46:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 0D2C280BE8 for ; Thu, 20 Jul 2023 05:46:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0D2C280BE8 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=N7VRXAnz 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VoSdZi8aBnu for ; Thu, 20 Jul 2023 05:46:37 +0000 (UTC) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) by smtp1.osuosl.org (Postfix) with ESMTPS id A6CEF80BD5 for ; Thu, 20 Jul 2023 05:46:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A6CEF80BD5 Received: by mail-io1-xd30.google.com with SMTP id ca18e2360f4ac-78625caa702so15759639f.1 for ; Wed, 19 Jul 2023 22:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689831997; x=1692423997; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q7YUKrPRuD4nBSPpbGten3MPW939P59NSrKptDy6vlU=; b=N7VRXAnzdpnzrhNorXpXKqa1jmHondnyELcu1s/GD0Lex2CjX9RhB/gXDr5W9/tsH5 922cOatZ7F74cJjS9SGy2+atDqvpUuJzXy2qXqx4LEo98uZu+VA4Ud+w6ROQfRsMHsK7 e4VmDJm19agJNBqi6tSfuu5TpZeEu9Yq8FXMTFiMDSi/hZuhnsXA+O8bEhfuuoiLo6qf yVqHEXNi2x0YWzOAXxEoCY4B8sCUvgTW4EBZO2S1e4fDSObB4cTnNvSW/vdbmVkweUMP vLkubGTxK1rz0849OAUNnug78qkOH7tliCEY/xYr5kjsnT4djgOPlh0BTk8mjByD0p7e HHUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689831997; x=1692423997; 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=Q7YUKrPRuD4nBSPpbGten3MPW939P59NSrKptDy6vlU=; b=EllYDJ0YZyhjP4odWZURNWv6tDvMmUbseroIcU2NbVCsZV0bvFuShrdlcdPVXlTbHs GuR0pkrI8HhXGwqAu55PxIu+wuUUuTuYH13sFJGsbBElC1Vq+9JKsm3VsNVrCM0RO8kY Mre/UMaLPhScpJzT1kG5p+K1GbWvdt+JnWt3GC2rRZIM5agTquxhzRzCUWB4wHd/Z19W 0Ah25f6Yh5Aon93AbHxfPUWKqqJQiv1yMImWLjMZY9urh8eypgbdF93QH7howxPeVVZI 73fZ2aiqXYP4bIQ/6bjNR5y4NJg/68sUt0xNvF/q0MY2guDbgJPh+6lro2mSaaT7jHez OShA== X-Gm-Message-State: ABy/qLbm1yYGkwdbQjx7Ad/3EoEiHa/NY7Mb8f+m9KiMYP7EqDoGFMHQ l4n3jdsJvx2jttv/ygCXUl5WS9c0XACOAMi4CEQ8dvTiNX8= X-Google-Smtp-Source: APBJJlHuFoCBm1skdH2TlFt9pOlMu8bG68mrWoBaz/VTNNdC5PLla1FVNL9zUwLOj50IXCfXf7LNClsoNmTYFleP3XU= X-Received: by 2002:a5d:8904:0:b0:783:72b9:ed67 with SMTP id b4-20020a5d8904000000b0078372b9ed67mr1523782ion.10.1689831996557; Wed, 19 Jul 2023 22:46:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Thu, 20 Jul 2023 06:46:25 +0100 Message-ID: To: Greg Sanders Content-Type: multipart/alternative; boundary="000000000000e28ead0600e4ab69" X-Mailman-Approved-At: Thu, 20 Jul 2023 09:11:47 +0000 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 05:46:40 -0000 --000000000000e28ead0600e4ab69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, I'm very meeting your development approach with regards to starting smalls about consensus change primitives, and I think taproot has demonstrated some good historical process, which has good archives about 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 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 "the 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 of Simplicity for 2/small party channels. I remember a Russell O'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 was iirc "yes it has been designed with this constraint", it's a very open question 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 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]. 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-Interactiv= e-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 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, whatev= er > 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 discove= r > 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 Simplicit= y, > 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 >> advanced contracting capabilities. However, as I dive deeper into some o= f >> the more ambitious goals for LN development I am learning that a great d= eal >> 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 hav= e 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 sho= uld >> 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 necess= ary >> 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 ar= eas >> of focus on LN preclude you from splitting your attention and none of th= is >> 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 introduc= ed >>> the idea of a new community process to specify covenants [0]. This post= is >>> to resume the experiment so far and officially mark the process mainten= ance >>> as "up for grabs", as I won't actively pursue it further (after waverin= g 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 betwee= n >>> proposals if they could be composed or combined by their authors, open = the >>> 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 l= ast >>> year [1]: namely the lack of a "codified checklist" for consensus chang= es, >>> 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 th= e >>> same time). Other complementary initiatives have been undertaken during= the >>> same period, AJ with the bitcoin-inquisition fork where the community o= f >>> developers and contracting primitives of researchers on a consensus-ena= bled >>> 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-depth >>> discussions did happen on the repository and on the channel on things l= ike >>> "merkelized all the things" or "payment pools for miners payoffs". >>> >>> As I've been busy on the Lightning-side and other Bitcoin projects, I'v= e >>> not run an online meeting since the month of April, while still having = a >>> bunch of fruitful technical discussions with folks involved in the effo= rt >>> at conferences and elsewhere. I launched the effort as an experiment wi= th >>> the soft commitment to dedicate 20% of my time on it, after few success= ful >>> 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 robustnes= s. >>> 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 thi= nk >>> 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 background= 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) a= nd >>> Schnorr (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, an= d >>> small incremental changes might be good enough to have a lower technica= l >>> 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 tim= e >>> 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 neutrality= " >>> [5]. If folks wanna experiment in terms of payment pools deployment, Gr= eg >>> Maxwell's old joinpool can be used today (and somehow it's worthy of it= s >>> 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 proposal= s >>> 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 consen= sus >>> 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 Bitcoi= n >>> Contracting Primitives WG (or the bitcoin-inquisition fork or collabora= te >>> with Optech to organize industry-wise workshop on covenants at the imag= e 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 informati= on >>> or financial resources will anchor your individual work on the long-ter= m, >>> don't hesitate to reach out, I'll see what I can do with a disintereste= d >>> mind [7]. >>> >>> With humility, >>> Antoine >>> >>> [0] >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/02076= 3.html >>> [1] >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/0202= 33.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 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/0= 17614.html. >>> For the philosophical reasons of doing so, I invite you to read Foucaul= t's >>> famous essay "Le philosophe masque". >>> [6] Somehow I come to share Jeremy's thesis's "Product management is no= t >>> "my Job" it's yours" in matters of consensus changes. I believe we migh= t be >>> past the technical complexity threshold where even simple consensus cha= nges >>> 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 d= oubt >>> 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 >> > --000000000000e28ead0600e4ab69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

I'm very meeting your deve= lopment approach with regards to starting smalls about consensus change pri= mitives, and I think taproot has demonstrated some good historical process,= which has good archives about how development was conducted (e.g the commu= nity-wide taproot review of which the Bitcoin Contracting Primitives WG was= built on this experience [0]).

I don't know a= bout saying that the BOLTs (and its process) should=C2=A0be authoritative o= ver the running=C2=A0code of implementations. While it's definitely=C2= =A0a mark of some bar of technical review and inter-compatibility, I think = ultimately each BOLT has to be judged individually on its own technical mer= its. And I think we had a bunch of cases in the past when "the map is = not the territory". Even there are few areas of critical Lightning ope= rations 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-c= hain DLCs [1]).

Lastly, there is a huge area of un= certainty about the technical fitness of Simplicity for 2/small party chann= els. I remember a Russell O'connor presentation about Simplicity back i= n Paris (2017 or 2018 ?) and asking him how it would work in a chain of tra= nsactions, while the answer was iirc "yes it has been designed with th= is constraint", it's a very open question when you have off-chain = states which advances in independence from the on-chain state between a dyn= amic number of counterparties (kinda the interactivity issue for payment po= ols). Here I guess you would have to come to a consensus to the model of lo= gic followed for the analysis of such distributed systems e.g Leslie Lampor= t's temporal logic [2]. Additionally, the theoretical foundations on th= e Coq prover are still actively studied by Xavier Leroy at the College de F= rance and some novel insights might be interesting for using formal verific= ation in terms of Bitcoin consensus changes development (and I don't kn= ow if all the works and lessons have been translated from French to English= ).

Best,
Antoine

[0]=C2=A0https://gi= thub.com/ajtowns/taproot-review

Le=C2=A0mer. 19 juil. 2023 =C3=A0=C2=A021:45, Gre= g Sanders <gsanders87@gmail.com<= /a>> a =C3=A9crit=C2=A0:
Hell= o Keagen,

Most of the complexity of LN cannot be resolve= d with covenants. Of the things that can be simplified in my experience, yo= u're going to need more than CTV to get significant gains. And in the e= nd, 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 t= o include such changes, whatever they are, then get deployment.
<= br>
Step 1 is finding a primitive that seems interesting. It'= s important to moderate enthusiasm for any primitive with reality, and prob= ably by being concrete by writing specs that use a primitive, and code it u= p to discover what we're overlooking. We're always overlooking some= thing! In my humble opinion these=C2=A0are step=C2=A02 and 3 of gathering m= ind-share.

As a more productive tact, if we're= thinking beyond 2/small party channels, probably better to snap your finge= rs, pretend we have Simplicity, see what we can build, and work backwards f= rom there to see if we can accomplish this within the confines of bitcoin s= cript?=C2=A0

Cheers,
Greg
On Wed, J= ul 19, 2023 at 3:59=E2=80=AFPM Keagan McClelland via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
=
Hi Antoine,

Thank you for the effort yo= u've put towards this. I generally agree that a smooth functioning Ligh= tning Network is of greater importance than advanced contracting capabiliti= es. 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 l= ightning (LN) proposals can be handily discharged with CTV. While I am not = intimately familiar with all of the other covenant schemes to the same leve= l of technical proficiency, I have a suspicion that a number of them, if no= t all of them, are capable of discharging the same flavor and amount of com= plexity as well. Others should 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 h= eld on theoretical grounds that the addition of such a mechanism is both ne= cessary and inevitable if Bitcoin is=C2=A0to survive in the long term. Howe= ver, as I've started to work more directly with the Lightning protocol,= these theoretical and purely logical arguments became far more concrete an= d immediately beneficial.

I say this primarily to = challenge the idea that covenants are a distraction from lightning developm= ent. It may very well be that your areas of focus on LN preclude you from s= plitting your attention and none of this email should be interpreted as a c= riticism of you 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 covenant= s can significantly contribute to LN's maturity. When and how should th= ey be prioritized? Unfortunately I don't feel able to comment on that a= t this time. All I know is that Lightning would almost certainly benefit su= bstantially from having a covenant primitive.

Chee= rs,
Keags

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

La= st year amid the failure of the CTV speedy trial activation and intense con= versations about a rainbow of covenant proposals, I introduced the idea of = a new community process to specify covenants [0]. This post is to resume th= e experiment so far and officially mark the process maintenance as "up= for grabs", as I won't actively pursue it further (after wavering= =C2=A0on such a decision a bit during May / June).

Few of the goals announced at that time were to build a consistent framewo= rk to evaluate covenant proposals, see the common grounds between proposals= if they could be composed or combined=C2=A0by their authors, open the cons= ensus=C2=A0 changes development process beyond the historical boundaries of= Bitcoin Core and maintain=C2=A0high-quality technical archive as a consens= us discussions have spawned half a decade from intellectual conception to a= ctivation in average (at least for segwit, schnorr, taproot).
Such effort was a speak-by-the-act answer to the issues in cons= ensus=C2=A0development changes pointed out by Jeremy Rubin in April of last= year [1]: namely the lack of a "codified checklist" for consensu= s changes, 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 du= ring the same time). Other complementary initiatives have been undertaken d= uring the same period, AJ with the bitcoin-inquisition fork where the commu= nity of developers and contracting primitives of researchers on a consensus= -enabled fork of core [2]. And Dave Harding with the careful archiving of a= ll covenant proposals under the Optech umbrella [3].

About the Bitcoin Contracting Primitives WG, a Github repository was sta= rted and maintained to archive and document all the primitives (apo, tluv, = ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict, check_outp= ut_covenant_verify, inherited ids, anyamount, singletons, op_vault) and the= corresponding protocols (payment pools, vaults, drivechains, trust-minimiz= ed mining pools payouts). We had a total of 6 monthly meetings on the Liber= a chat #bitcoin-contracting-primitives-wg for a number of more than 20 indi= vidual attendees representing most of the parts of the community. I think (= missing march logs). Numerous in-depth discussions did happen on the reposi= tory 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&= #39;ve not run an online meeting since the month of April, while still havi= ng a bunch of fruitful technical discussions with folks involved in the eff= ort at conferences and elsewhere. I launched the effort as an experiment wi= th 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 c= omes with direct competition of my time to work on Lightning robustness. Ge= tting 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 Ne= twork.

As such, between extended covenant capabili= ties 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 existen= tial survival, and where on a personal title I'll allocate the best of = my time and energy (and somehow it match the "slow" technical act= ivity on bitcoin-inquisition mostly done by Lightning hands).
This is my personal conclusion only on the state of Bitcoin tec= hnological momentum, and this is quite tainted by my deep background in Lig= htning development. If you've been working on covenant changes proposal= s, please don't take it as a discouragement, I think Taproot (privacy-p= reserving script policies behind the taproot tree branches) and Schnorr (fo= r native multi-sig) soft forks have shown how it can improve the building o= f self-custody solutions by one or two order of magnitude, and small increm= ental 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 issu= e and mass-compression of withdrawal and design exotic advanced Bitcoin con= tracts based on the taproot annex, though more in a "l'art pour l&= #39;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 in the past and somehow it's good practice i= n terms of "message neutrality" [5]. If folks wanna experiment 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 coi= njoins).

I'll honestly acknowledge towards the= community, I might have overpromised with the kickstart of this new proces= s aiming to move the frontlines in matters of Bitcoin consensus changes dev= elopment process. On the other hand, I think enough sessions of the working= group have been runned and enough marks of technical interests have been c= ollected to demonstrate the minimal value of such a process, so I would est= imate my open-source balance sheet towards the community to be in good stan= ding ? (open-minded question).

I don't think B= itcoin fundamentally lacks compelling technical proposals to advance the ca= pabilities of Bitcoin Script today, nor the crowd of seasoned and smart pro= tocol developers to evaluate mature proposals end-to-end and on multiple di= mensions with a spirit of independence. Rather, I believe what Bitcoin is l= acking is a small crowd of technical historians and archivist doing the wor= k of assessing, collecting and preserving consensus changes proposals and Q= A devs to ensure any consensus change proposals has world-class battle-grou= nd testing before to be considered for deployment, ideally with the best st= andards 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 coll= aborate 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 t= o show proof-of-work and you estimate that operational ground, legal inform= ation or financial resources will anchor your individual work on the long-t= erm, don't hesitate to reach out, I'll see what I can do with a dis= interested mind [7].

With humility,
Anto= ine

[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 l= ight of the conflict operational evolutions.
[5] See=C2=A0https://lists.linuxfoundation.org/pipermail/b= itcoin-dev/2020-February/017614.html. For the philosophical reasons of = doing so, I invite you to read Foucault's famous essay "Le philoso= phe masque".
[6] Somehow I come to share Jeremy's thesis= 's "Product management is not "my Job" it's yours&qu= ot; in matters of consensus changes. I believe we might be past the technic= al complexity threshold where even simple consensus changes can be conducte= d from A to Z as a one man job or even by a group of 2/3 elite devs.
<= 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 commit reso= urces=C2=A0to advance softforks and covenants in the Bitcoin space, no doub= t when you're reliable and with a track record, folks are ready to offe= r you opportunities to work full-time on consensus changes.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e28ead0600e4ab69--