path: root/86/d0585f8866c6329f22fd4a9a8f52a34a945961

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4D535C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jul 2023 05:34:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 132A660B9F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jul 2023 05:34:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 132A660B9F
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=Uvgh/GlI
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Z41kS9YUDrEC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jul 2023 05:34:11 +0000 (UTC)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com
 [IPv6:2607:f8b0:4864:20::d34])
 by smtp3.osuosl.org (Postfix) with ESMTPS id CC11E60B49
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jul 2023 05:34:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org CC11E60B49
Received: by mail-io1-xd34.google.com with SMTP id
 ca18e2360f4ac-78654448524so16794439f.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jul 2023 22:34:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1689831250; x=1692423250;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=TF+uPI8e2XnEnwyirvxeUh//dvHHheLEjNj5CCAUXLU=;
 b=Uvgh/GlIsyafgEY8dJsK3swgNYcBuTcCvNwJpmzMallp70SWcrGCayIzfSjh+b4RPN
 hjzbB4H07bGsyO/+4SQVXcAR+TrPSJFEsQVGu2KU4ust+Aen2cXHa69BAiEh7lqvIjkw
 R6MChFaqnDh2HZzgMLoBe4OFroK3WALw6D5l5f/NkyZxbqMOpXGm1caEGhxzlXdZ9vI/
 Dp+jK//V4A5odaOMvP7YPQfHr1+TPRtn1vw8yyjH5Y8p1AzXzxwxk5CgfvoA2Uyf0MY5
 ZMRmZwrft/tzLitkITWXbg4u0jhfnL+pEeSQLisOMGwWnazm4KBRKmuzUUqS+mPzw8Ao
 xf/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1689831250; x=1692423250;
 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=TF+uPI8e2XnEnwyirvxeUh//dvHHheLEjNj5CCAUXLU=;
 b=CHBIaXctMLx9y26SWAxBiE7WpL8KPNDNZHZwreAKpRqRf4j+iqvxxMLqAxyDKwPi2J
 zNXWaOrFDPtDQj7RAzFtxv2Ou59ZCtDHqrX63DNqMOIQDIu6i/VXHJSD7y6+mVYddkwh
 GKB5LVW2XAo7q6f5oOlhIpfWNT04/FLh3ClWpCL6OT9MhhUG3iRxAr6cBMj4Bd34IgM4
 qcnpEsJUG7p027rrK0yAXjs97P4IfrVKgLKNFHd1s62v4hYam9kqN5XvvX88nkbOhItQ
 gb9Wp3XEg3TB3+fm44zAftST7aSHAJ3xiu0s4FVKkZcaTxwV5kdapnGpy7bdGaebD6Ph
 ccQA==
X-Gm-Message-State: ABy/qLaoHah/MYeFtOHS6oaODfD4J39V/RT4RyqKlGrMzV164gUFUrBO
 0dijsD8hfJMm3hDebFKq+gkPFvWTmtA5D1cXrN7X6/xTg6c=
X-Google-Smtp-Source: APBJJlGKGJpO4tl9Vd5H6LtDX2d4/zs1jO9/Jbc3OCkY4Y5MsJGPeP1gNyWeN6L5jt+eBbYCuYc8f4/cdqsbPiuUu38=
X-Received: by 2002:a5e:9403:0:b0:784:314f:8d68 with SMTP id
 q3-20020a5e9403000000b00784314f8d68mr7966721ioj.1.1689831249659; Wed, 19 Jul
 2023 22:34:09 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+G=zhzHFTVLxLMgYeQ64srWA7GmfDrkdF+bc6q4+uTnCQ@mail.gmail.com>
 <CALeFGL0wzi0z13-H_t13fyrvy5cTo2j0f6qOL0-_zt8suMZU4A@mail.gmail.com>
In-Reply-To: <CALeFGL0wzi0z13-H_t13fyrvy5cTo2j0f6qOL0-_zt8suMZU4A@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 20 Jul 2023 06:33:58 +0100
Message-ID: <CALZpt+HMseR_n2HttBgaBQBVRgqO1TQVKy0n36VULvityTnWUA@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005dccde0600e47fd6"
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:34:13 -0000

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

Hi Keagan,

On the claim that advanced contracting capabilities can improve the
Lightning Network, yes this is a claim I can back and why with Gleb we
published ideas about payment pools back in 2020, pointing out clearly the
limitations of 2-party payment channels in terms of privacy and scalability
dimensions [0]. There are few discussions on the same thread on trade-off
of hashchain covenants like CTV in terms of off-chain constructions, where
they can be evaluated on a bunch of dimensions like key management, fee
cost, liquidity counterparty interactivity and security risks among others.

I don't know if Bitcoin _needs_ covenant schemes to survive on the long
term though yes I'll join the appreciation than few covenants (notable ones
improving payment pools or channel factories and self-custody solutions)
are increasing the odds of success of Bitcoin survival on dimensions like
onboarding / transactional scaling and "non-first-party to self-sovereign
custody" shapes of solutions. On a theoretical proof that covenants are
formally needed, well one would have to reduce Bitcoin (and probably
Lightning and the mining ecosystem) to a workable game-theory, and define
this game to rely on practice assumptions to bound the dynamics of the
"real-world" context [1].

On the latest claim that Lightning of today *might* benefit from a covenant
primitive, it's hard to evaluate as the foundations of channel operations
are quite under intense re-works from taproot, schnorr and package relay
(affecting all the dimensions). Yet one might notice that "high-level"
Lightning is more isolated than those ongoing changes, and where covenant
primitives might be useful. I think there is a widely-known issue among the
DLC development community on the limitations of signatures compared to
CTV-like "hash-chain" in matters of financial engineering expressivity over
a wide outcome space [2], [3], [4]. We experimented in the past DLC
integration in LDK, though never so far to evaluate the practical
performance bounds of curve points addition on what what you can express as
advanced contracts (the original coinpool post points to the factorial
complexity bound for withdrawal of unknown order and therefore covenant
capabilities improves the issue, though here it's an issue of _any_ state
being dependent on an unknown combination of oracle-sourced events).

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.ht=
ml
[1] E.g the delicate difference between the "theory" and "practice" from
the viewpoint of physics, I would send back to Einstein's general theory
where few (anecdotic?) experiments have cast doubts on its validity, e.g
Miller's experiment in the 20s, and the echoes it had in scientific
epistemology during the XXth.
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808=
.html
[3] https://mailmanlists.org/pipermail/dlc-dev/2021-November/000091.html
[4]
https://github.com/bitcoinops/bitcoinops.github.io/pull/806#issuecomment-12=
32073574

Le mer. 19 juil. 2023 =C3=A0 19:29, Keagan McClelland <
keagan.mcclelland@gmail.com> a =C3=A9crit :

> Hi Antoine,
>
> Thank you for the effort you've put towards this. I generally agree that =
a
> smooth functioning Lightning Network is of greater importance than advanc=
ed
> contracting capabilities. However, as I dive deeper into some of the more
> ambitious goals for LN development I am learning that a great deal of
> complexity of some current lightning (LN) proposals can be handily
> discharged with CTV. While I am not intimately familiar with all of the
> other covenant schemes to the same level of technical proficiency, I have=
 a
> suspicion that a number of them, if not all of them, are capable of
> discharging the same flavor and amount of complexity as well. Others shou=
ld
> chime in if they can confirm this claim.
>
> I have been publicly on the record as supporting the addition of some
> covenant scheme into Bitcoin for some time and have long held on
> theoretical grounds that the addition of such a mechanism is both necessa=
ry
> and inevitable if Bitcoin is to survive in the long term. However, as I'v=
e
> started to work more directly with the Lightning protocol, these
> theoretical and purely logical arguments became far more concrete and
> immediately beneficial.
>
> I say this primarily to challenge the idea that covenants are a
> distraction from lightning development. It may very well be that your are=
as
> of focus on LN preclude you from splitting your attention and none of thi=
s
> email should be interpreted as a criticism of you applying your efforts i=
n
> the highest leverage manner you can manage. That said, I don't want
> observers of this thread to walk away with the impression that they are t=
wo
> independent efforts as covenants can significantly contribute to LN's
> maturity. When and how should they be prioritized? Unfortunately I don't
> feel able to comment on that at this time. All I know is that Lightning
> would almost certainly benefit substantially from having a covenant
> primitive.
>
> Cheers,
> Keags
>
> On Tue, Jul 18, 2023 at 3:40=E2=80=AFPM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi list,
>>
>> Last year amid the failure of the CTV speedy trial activation and intens=
e
>> conversations about a rainbow of covenant proposals, I introduced the id=
ea
>> of a new community process to specify covenants [0]. This post is to res=
ume
>> the experiment so far and officially mark the process maintenance as "up
>> for grabs", as I won't actively pursue it further (after wavering on suc=
h a
>> decision a bit during May / June).
>>
>> Few of the goals announced at that time were to build a consistent
>> framework to evaluate covenant proposals, see the common grounds between
>> proposals if they could be composed or combined by their authors, open t=
he
>> consensus  changes development process beyond the historical boundaries =
of
>> Bitcoin Core and maintain high-quality technical archive as a consensus
>> discussions have spawned half a decade from intellectual conception to
>> activation in average (at least for segwit, schnorr, taproot).
>>
>> Such effort was a speak-by-the-act answer to the issues in
>> consensus development changes pointed out by Jeremy Rubin in April of la=
st
>> year [1]: namely the lack of a "codified checklist" for consensus change=
s,
>> that "consensus is memoryless" and "bitcoin core is not bitcoin"
>> (independently of the technical concerns as I have as limited or
>> non-adequate primitive for vaults / payment pools I expressed during the
>> same time). Other complementary initiatives have been undertaken during =
the
>> same period, AJ with the bitcoin-inquisition fork where the community of
>> developers and contracting primitives of researchers on a consensus-enab=
led
>> fork of core [2]. And Dave Harding with the careful archiving of all
>> covenant proposals under the Optech umbrella [3].
>>
>> About the Bitcoin Contracting Primitives WG, a Github repository was
>> started and maintained to archive and document all the primitives (apo,
>> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
>> check_output_covenant_verify, inherited ids, anyamount, singletons,
>> op_vault) and the corresponding protocols (payment pools, vaults,
>> drivechains, trust-minimized mining pools payouts). We had a total of 6
>> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg f=
or
>> a number of more than 20 individual attendees representing most of the
>> parts of the community. I think (missing march logs). Numerous in-depth
>> discussions did happen on the repository and on the channel on things li=
ke
>> "merkelized all the things" or "payment pools for miners payoffs".
>>
>> As I've been busy on the Lightning-side and other Bitcoin projects, I've
>> not run an online meeting since the month of April, while still having a
>> bunch of fruitful technical discussions with folks involved in the effor=
t
>> at conferences and elsewhere. I launched the effort as an experiment wit=
h
>> the soft commitment to dedicate 20% of my time on it, after few successf=
ul
>> sessions I think such a process has an interest of its own, however it
>> comes with direct competition of my time to work on Lightning robustness=
.
>> Getting my hands dirty on low-level LDK development recently made me
>> realize we still have years of titan work to get a secure and reliable
>> Lightning Network.
>>
>> As such, between extended covenant capabilities for advanced contracts
>> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
>> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I thin=
k
>> the latter goal is more critical for Bitcoin existential survival, and
>> where on a personal title I'll allocate the best of my time and energy (=
and
>> somehow it match the "slow" technical activity on bitcoin-inquisition
>> mostly done by Lightning hands).
>>
>> This is my personal conclusion only on the state of Bitcoin technologica=
l
>> momentum, and this is quite tainted by my deep background in Lightning
>> development. If you've been working on covenant changes proposals, pleas=
e
>> don't take it as a discouragement, I think Taproot (privacy-preserving
>> script policies behind the taproot tree branches) and Schnorr (for nativ=
e
>> multi-sig) soft forks have shown how it can improve the building of
>> self-custody solutions by one or two order of magnitude, and small
>> incremental changes might be good enough to have a lower technical
>> consensus bar.
>>
>> On my side, I'll pursue pure R&D works on CoinPool, notably coming with
>> better solutions with the interactivity issue and mass-compression of
>> withdrawal and design exotic advanced Bitcoin contracts based on the
>> taproot annex, though more in a "l'art pour l'art" approach for the time
>> being [4]. Additionally, I might start to submit an in-depth security
>> review of consensus changes under pseudonyms, it has already been done i=
n
>> the past and somehow it's good practice in terms of "message neutrality"
>> [5]. If folks wanna experiment in terms of payment pools deployment, Gre=
g
>> Maxwell's old joinpool can be used today (and somehow it's worthy of its
>> own as a net advance for coinjoins).
>>
>> I'll honestly acknowledge towards the community, I might have
>> overpromised with the kickstart of this new process aiming to move the
>> frontlines in matters of Bitcoin consensus changes development process. =
On
>> the other hand, I think enough sessions of the working group have been
>> runned and enough marks of technical interests have been collected to
>> demonstrate the minimal value of such a process, so I would estimate my
>> open-source balance sheet towards the community to be in good standing ?
>> (open-minded question).
>>
>> I don't think Bitcoin fundamentally lacks compelling technical proposals
>> to advance the capabilities of Bitcoin Script today, nor the crowd of
>> seasoned and smart protocol developers to evaluate mature proposals
>> end-to-end and on multiple dimensions with a spirit of independence.
>> Rather, I believe what Bitcoin is lacking is a small crowd of technical
>> historians and archivist doing the work of assessing, collecting and
>> preserving consensus changes proposals and QA devs to ensure any consens=
us
>> change proposals has world-class battle-ground testing before to be
>> considered for deployment, ideally with the best standards of Bitcoin
>> decentralization and FOSS neutrality [6].
>>
>> If you would like to pursue the maintenance and nurturing of the Bitcoin
>> Contracting Primitives WG (or the bitcoin-inquisition fork or collaborat=
e
>> with Optech to organize industry-wise workshop on covenants at the image=
 of
>> what has been done in 2019 for Taproot), that you're willing to show
>> proof-of-work and you estimate that operational ground, legal informatio=
n
>> or financial resources will anchor your individual work on the long-term=
,
>> don't hesitate to reach out, I'll see what I can do with a disinterested
>> mind [7].
>>
>> With humility,
>> Antoine
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763=
.html
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/02023=
3.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0=
20921.html
>> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
>> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
>> remaining "Big Problems" is still pending on my visit to co-author Gleb
>> Naumenko in Ukraine, which has been postponed few times in light of the
>> conflict operational evolutions.
>> [5] See
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/01=
7614.html.
>> For the philosophical reasons of doing so, I invite you to read Foucault=
's
>> famous essay "Le philosophe masque".
>> [6] Somehow I come to share Jeremy's thesis's "Product management is not
>> "my Job" it's yours" in matters of consensus changes. I believe we might=
 be
>> past the technical complexity threshold where even simple consensus chan=
ges
>> can be conducted from A to Z as a one man job or even by a group of 2/3
>> elite devs.
>> [7] I've been reached out multiple times and consistently by R&D
>> non-profits, plebs whales and VC firms who were interested to commit
>> resources to advance softforks and covenants in the Bitcoin space, no do=
ubt
>> when you're reliable and with a track record, folks are ready to offer y=
ou
>> opportunities to work full-time on consensus changes.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">Hi Keagan,<div><br></div><div>On the claim that advanced c=
ontracting capabilities can improve the Lightning Network, yes this is a cl=
aim I can back and why with Gleb we published ideas about payment pools bac=
k in 2020, pointing=C2=A0out clearly the limitations of 2-party payment cha=
nnels in terms of privacy and scalability dimensions [0]. There are few dis=
cussions on the same thread on trade-off of hashchain covenants like CTV in=
 terms of off-chain constructions, where they can be evaluated on a bunch o=
f dimensions=C2=A0like key management, fee cost, liquidity counterparty int=
eractivity and security risks among others.</div><div><br></div><div>I don&=
#39;t know if Bitcoin _needs_ covenant schemes to survive on the long term =
though yes I&#39;ll join the appreciation than few covenants (notable ones =
improving payment pools or channel factories and self-custody solutions) ar=
e increasing the odds of success of Bitcoin survival on dimensions like onb=
oarding / transactional scaling and &quot;non-first-party to self-sovereign=
 custody&quot; shapes of solutions. On a theoretical proof that covenants a=
re formally needed, well one would have to reduce Bitcoin (and probably Lig=
htning and the mining ecosystem) to a workable game-theory, and define this=
 game to rely on practice assumptions to bound the dynamics of the &quot;re=
al-world&quot; context [1].</div><div><br></div><div>On the latest claim th=
at Lightning of today *might* benefit from a covenant primitive, it&#39;s h=
ard to evaluate as the foundations of channel operations are quite under in=
tense re-works from taproot, schnorr and package relay (affecting all the d=
imensions). Yet one might notice that &quot;high-level&quot; Lightning is m=
ore isolated than those ongoing changes, and where covenant primitives migh=
t be useful. I think there is a widely-known issue among the DLC developmen=
t community on the limitations of signatures compared to CTV-like &quot;has=
h-chain&quot; in matters of financial engineering expressivity over a wide =
outcome space [2], [3], [4]. We experimented in the past DLC integration in=
 LDK, though never so far to evaluate the practical performance bounds of c=
urve points addition on what what you can express as advanced contracts (th=
e original coinpool post points to the factorial complexity bound for withd=
rawal of unknown order and therefore covenant capabilities improves the iss=
ue, though here it&#39;s an issue of _any_ state being dependent on an unkn=
own combination of oracle-sourced events).</div><div><br></div><div>Best,</=
div><div>Antoine</div><div><br></div><div>[0]=C2=A0<a href=3D"https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html">https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html</a></d=
iv><div>[1] E.g the delicate difference between the &quot;theory&quot; and =
&quot;practice&quot; from the viewpoint of physics, I would send back to Ei=
nstein&#39;s general theory where few (anecdotic?) experiments have cast do=
ubts on its validity, e.g Miller&#39;s experiment in the 20s, and the echoe=
s it had in scientific epistemology during the XXth.</div><div>[2]=C2=A0<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Januar=
y/019808.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-January/019808.html</a></div><div>[3]=C2=A0<a href=3D"https://mailmanlists=
.org/pipermail/dlc-dev/2021-November/000091.html">https://mailmanlists.org/=
pipermail/dlc-dev/2021-November/000091.html</a></div><div>[4]=C2=A0<a href=
=3D"https://github.com/bitcoinops/bitcoinops.github.io/pull/806#issuecommen=
t-1232073574">https://github.com/bitcoinops/bitcoinops.github.io/pull/806#i=
ssuecomment-1232073574</a></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 19 juil. 2023 =C3=A0=C2=A019:2=
9, Keagan McClelland &lt;<a href=3D"mailto:keagan.mcclelland@gmail.com">kea=
gan.mcclelland@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">Hi Antoine,<div><br></div><div>Thank you for the effor=
t you&#39;ve put towards this. I generally agree that a smooth functioning =
Lightning Network is of greater importance than advanced contracting capabi=
lities. 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 curre=
nt lightning (LN) proposals can be handily discharged with CTV. While I am =
not intimately familiar with all of the other covenant schemes to the same =
level of technical proficiency, I have a suspicion that a number of them, i=
f not all of them, are capable of discharging the same flavor and amount of=
 complexity as well. Others should chime in if they can confirm this claim.=
</div><div><br></div><div>I have been publicly on the record as supporting =
the addition of some covenant scheme into Bitcoin for some time and have lo=
ng held on theoretical grounds that the addition of such a mechanism is bot=
h necessary and inevitable if Bitcoin is=C2=A0to survive in the long term. =
However, as I&#39;ve started to work more directly with the Lightning proto=
col, these theoretical and purely logical arguments became far more concret=
e and immediately beneficial.</div><div><br></div><div>I say this primarily=
 to challenge the idea that covenants are a distraction from lightning deve=
lopment. It may very well be that your areas of focus on LN preclude you fr=
om splitting your attention and none of this email should be interpreted as=
 a criticism of you applying your efforts in the highest leverage manner yo=
u=C2=A0can manage. That said, I don&#39;t want observers of this thread to =
walk away with the impression that they are two independent efforts as cove=
nants can significantly contribute to LN&#39;s maturity. When and how shoul=
d they be prioritized? Unfortunately I don&#39;t feel able to comment on th=
at at this time. All I know is that Lightning would almost certainly benefi=
t substantially from having a covenant primitive.</div><div><br></div><div>=
Cheers,</div><div>Keags</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Jul 18, 2023 at 3:40=E2=80=AFPM Antoi=
ne Riard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi list,<div><br></div><d=
iv>Last year amid the failure of the CTV speedy trial activation and intens=
e conversations about a rainbow of covenant proposals, I introduced the ide=
a of a new community process to specify covenants [0]. This post is to resu=
me the experiment so far and officially mark the process maintenance as &qu=
ot;up for grabs&quot;, as I won&#39;t actively pursue it further (after wav=
ering=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 fr=
amework to evaluate covenant proposals, see the common grounds between prop=
osals if they could be composed or combined=C2=A0by their authors, open the=
 consensus=C2=A0 changes development process beyond the historical boundari=
es of Bitcoin Core and maintain=C2=A0high-quality technical archive as a co=
nsensus discussions have spawned half a decade from intellectual conception=
 to activation in average (at least for segwit, schnorr, taproot).</div><di=
v><br></div><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 &quot;codified checklist&quot; for con=
sensus changes, that &quot;consensus is memoryless&quot; and &quot;bitcoin =
core is not bitcoin&quot; (independently of the technical concerns as I hav=
e as limited or non-adequate primitive for vaults / payment pools I express=
ed during the same time). Other complementary initiatives have been underta=
ken during the same period, AJ with the bitcoin-inquisition fork where the =
community of developers and contracting primitives of researchers on a cons=
ensus-enabled fork of core [2]. And Dave Harding with the careful archiving=
 of all covenant proposals under the Optech umbrella [3].</div><div><br></d=
iv><div>About the Bitcoin Contracting Primitives WG, a Github repository wa=
s started and maintained to archive and document all the primitives (apo, t=
luv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict, check=
_output_covenant_verify, inherited ids, anyamount, singletons, op_vault) an=
d the corresponding protocols (payment pools, vaults, drivechains, trust-mi=
nimized 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 th=
ink (missing march logs). Numerous in-depth discussions did happen on the r=
epository and on the channel on things like &quot;merkelized all the things=
&quot; or &quot;payment pools for miners payoffs&quot;.</div><div><br></div=
><div>As I&#39;ve been busy on the Lightning-side and other Bitcoin project=
s, I&#39;ve not run an online meeting since the month of April, while still=
 having a bunch of fruitful technical discussions with folks involved in th=
e effort at conferences and elsewhere. I launched the effort as an experime=
nt with the soft commitment to dedicate 20% of my time on it, after few suc=
cessful 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 rea=
lize we still have years of titan work to get a secure and reliable Lightni=
ng Network.</div><div><br></div><div>As such, between extended covenant cap=
abilities for advanced contracts coming as a reality for Bitcoin _or_ LN wo=
rking smoothly at scale with 50-100M UTXO-sharing users on it during the ne=
xt 5-7 years cycle, I think the latter goal is more critical for Bitcoin ex=
istential survival, and where on a personal title I&#39;ll allocate the bes=
t of my time and energy (and somehow it match the &quot;slow&quot; technica=
l activity on bitcoin-inquisition mostly done by Lightning hands).</div><di=
v><br></div><div>This is my personal conclusion only on the state of Bitcoi=
n technological momentum, and this is quite tainted by my deep background i=
n Lightning development. If you&#39;ve been working on covenant changes pro=
posals, please don&#39;t take it as a discouragement, I think Taproot (priv=
acy-preserving script policies behind the taproot tree branches) and Schnor=
r (for native multi-sig) soft forks have shown how it can improve the build=
ing of self-custody solutions by one or two order of magnitude, and small i=
ncremental changes might be good enough to have a lower technical consensus=
 bar.</div><div><br></div><div>On my side, I&#39;ll pursue pure R&amp;D wor=
ks on CoinPool, notably coming with better solutions with the interactivity=
 issue and mass-compression of withdrawal and design exotic advanced Bitcoi=
n contracts based on the taproot annex, though more in a &quot;l&#39;art po=
ur l&#39;art&quot; approach for the time being [4]. Additionally, I might s=
tart to submit an in-depth security review of consensus changes under pseud=
onyms, it has already been done in the past and somehow it&#39;s good pract=
ice in terms of &quot;message neutrality&quot; [5]. If folks wanna experime=
nt in terms of payment pools deployment, Greg Maxwell&#39;s old joinpool ca=
n be used today (and somehow it&#39;s worthy of its own as a net advance fo=
r coinjoins).</div><div><br></div><div>I&#39;ll honestly acknowledge toward=
s the community, I might have overpromised with the kickstart of this new p=
rocess aiming to move the frontlines in matters of Bitcoin consensus change=
s development process. On the other hand, I think enough sessions of the wo=
rking group have been runned and enough marks of technical interests have b=
een collected to demonstrate the minimal value of such a process, so I woul=
d estimate my open-source balance sheet towards the community to be in good=
 standing ? (open-minded question).</div><div><br></div><div>I don&#39;t th=
ink Bitcoin fundamentally lacks compelling technical proposals to advance t=
he capabilities of Bitcoin Script today, nor the crowd of seasoned and smar=
t protocol developers to evaluate mature proposals end-to-end and on multip=
le dimensions with a spirit of independence. Rather, I believe what Bitcoin=
 is lacking is a small crowd of technical historians and archivist doing th=
e work of assessing, collecting and preserving consensus changes proposals =
and QA devs to ensure any consensus change proposals has world-class battle=
-ground testing before to be considered for deployment, ideally with the be=
st standards of Bitcoin decentralization and FOSS neutrality [6].</div><div=
><br></div><div>If you would like to pursue the maintenance and nurturing o=
f 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&#39;re will=
ing to show proof-of-work and you estimate that operational ground, legal i=
nformation or financial resources will anchor your individual work on the l=
ong-term, don&#39;t hesitate to reach out, I&#39;ll see what I can do with =
a disinterested mind [7].</div><div><br></div><div>With humility,</div><div=
>Antoine</div><div><br></div><div>[0]=C2=A0<a href=3D"https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2022-July/020763.html" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.h=
tml</a></div><div>[1]=C2=A0<a href=3D"https://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2022-April/020233.html" target=3D"_blank">https://lists.=
linuxfoundation.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.linuxfound=
ation.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/8=
06" target=3D"_blank">https://github.com/bitcoinops/bitcoinops.github.io/pu=
ll/806</a></div><div>[4] Version 0.2 of the CoinPool whitepaper addressing =
most of the remaining &quot;Big Problems&quot; 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.</div><div>[5] See=C2=A0<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Februa=
ry/017614.html" target=3D"_blank">https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2020-February/017614.html</a>. For the philosophical reasons=
 of doing so, I invite you to read Foucault&#39;s famous essay &quot;Le phi=
losophe masque&quot;.</div><div>[6] Somehow I come to share Jeremy&#39;s th=
esis&#39;s &quot;Product management is not &quot;my Job&quot; it&#39;s your=
s&quot; in matters of consensus changes. I believe we might be past the tec=
hnical complexity threshold where even simple consensus changes can be cond=
ucted from A to Z as a one man job or even by a group of 2/3 elite devs.</d=
iv><div>[7] I&#39;ve been reached out multiple times and consistently by R&=
amp;D non-profits, plebs whales and VC firms who were interested to commit =
resources=C2=A0to advance softforks and covenants in the Bitcoin space, no =
doubt when you&#39;re reliable and with a track record, folks are ready to =
offer you opportunities to work full-time on consensus changes.</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--0000000000005dccde0600e47fd6--