diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2023-07-20 06:46:25 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-07-20 05:46:40 +0000 |
| commit | b67575be2928c69083637824529817a6b23eb07f (patch) | |
| tree | 08dfeaef005f4540ceb2727a7d20f092e16b46c9 | |
| parent | a8ba1fe461f90efb8e9c2ee39ccd0545d2790bc5 (diff) | |
| download | pi-bitcoindev-b67575be2928c69083637824529817a6b23eb07f.tar.gz pi-bitcoindev-b67575be2928c69083637824529817a6b23eb07f.zip | |
Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"
| -rw-r--r-- | 23/923d4e7b32b3f34b71cff1de04e31716ad2390 | 671 |
1 files changed, 671 insertions, 0 deletions
diff --git a/23/923d4e7b32b3f34b71cff1de04e31716ad2390 b/23/923d4e7b32b3f34b71cff1de04e31716ad2390 new file mode 100644 index 000000000..c0bb6b111 --- /dev/null +++ b/23/923d4e7b32b3f34b71cff1de04e31716ad2390 @@ -0,0 +1,671 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 26087C0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CALZpt+G=zhzHFTVLxLMgYeQ64srWA7GmfDrkdF+bc6q4+uTnCQ@mail.gmail.com> + <CALeFGL0wzi0z13-H_t13fyrvy5cTo2j0f6qOL0-_zt8suMZU4A@mail.gmail.com> + <CAB3F3DsSjtXxA3X34ky7P=QSr3rEcG94dJ6k7sO543G0HvCv-A@mail.gmail.com> +In-Reply-To: <CAB3F3DsSjtXxA3X34ky7P=QSr3rEcG94dJ6k7sO543G0HvCv-A@mail.gmail.com> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Thu, 20 Jul 2023 06:46:25 +0100 +Message-ID: <CALZpt+E=0OEJzXdMWse0R+f5vuc0e-W4HTkZ_rdeAjstCU8OpQ@mail.gmail.com> +To: Greg Sanders <gsanders87@gmail.com> +Content-Type: multipart/alternative; boundary="000000000000e28ead0600e4ab69" +X-Mailman-Approved-At: Thu, 20 Jul 2023 09:11:47 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting + Primitives WG and marking this community process "up for grabs" +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: 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 <gsanders87@gmail.com> 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 + +<div dir=3D"ltr">Hi Greg,<div><br></div><div>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]).</div><div><br></div><div>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]).</div><div><br></div><div>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= +).</div><div><br></div><div>Best,</div><div>Antoine</div><div><br></div><di= +v>[0]=C2=A0<a href=3D"https://github.com/ajtowns/taproot-review">https://gi= +thub.com/ajtowns/taproot-review</a></div><div>[1]=C2=A0<a href=3D"https://g= +ithub.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protoco= +l.md">https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Inte= +ractive-Protocol.md</a></div><div>[2]=C2=A0<a href=3D"https://en.wikipedia.= +org/wiki/Temporal_logic_of_actions">https://en.wikipedia.org/wiki/Temporal_= +logic_of_actions</a></div></div><br><div class=3D"gmail_quote"><div dir=3D"= +ltr" class=3D"gmail_attr">Le=C2=A0mer. 19 juil. 2023 =C3=A0=C2=A021:45, Gre= +g Sanders <<a href=3D"mailto:gsanders87@gmail.com">gsanders87@gmail.com<= +/a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid= +;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hell= +o Keagen,<div><br></div><div>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.</div><div><= +br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>Cheers,</div><div>Greg</div></div><br= +><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, J= +ul 19, 2023 at 3:59=E2=80=AFPM Keagan McClelland via bitcoin-dev <<a hre= +f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi= +n-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class= +=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= +rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">= +<div dir=3D"ltr">Hi Antoine,<div><br></div><div>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.</di= +v><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Chee= +rs,</div><div>Keags</div></div><br><div class=3D"gmail_quote"><div dir=3D"l= +tr" class=3D"gmail_attr">On Tue, Jul 18, 2023 at 3:40=E2=80=AFPM Antoine Ri= +ard via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation= +.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote= +:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= +8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204= +,204,204);padding-left:1ex"><div dir=3D"ltr">Hi list,<div><br></div><div>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).</div><div><br></div><div= +>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).</div><div><br= +></div><div>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].</div><div><br></div><d= +iv>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".</div><div><br></div><div= +>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.</div><div><br></div><div>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).</div><div><br= +></div><div>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.= +</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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].</div><div><br>= +</div><div>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].</div><div><br></div><div>With humility,</div><div>Anto= +ine</div><div><br></div><div>[0]=C2=A0<a href=3D"https://lists.linuxfoundat= +ion.org/pipermail/bitcoin-dev/2022-July/020763.html" target=3D"_blank">http= +s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html</= +a></div><div>[1]=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermai= +l/bitcoin-dev/2022-April/020233.html" target=3D"_blank">https://lists.linux= +foundation.org/pipermail/bitcoin-dev/2022-April/020233.html</a></div><div>[= +2]=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/= +2022-September/020921.html" target=3D"_blank">https://lists.linuxfoundation= +.org/pipermail/bitcoin-dev/2022-September/020921.html</a></div><div>[3]=C2= +=A0<a href=3D"https://github.com/bitcoinops/bitcoinops.github.io/pull/806" = +target=3D"_blank">https://github.com/bitcoinops/bitcoinops.github.io/pull/8= +06</a></div><div>[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.</div><div>[5] See=C2=A0<a href= +=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/0= +17614.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/b= +itcoin-dev/2020-February/017614.html</a>. For the philosophical reasons of = +doing so, I invite you to read Foucault's famous essay "Le philoso= +phe masque".</div><div>[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><= +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.</div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div> + +--000000000000e28ead0600e4ab69-- + |