path: root/03/9ccd4e8f54b5bb2838152b36558e3a3dd81ee2

Return-Path: <gsanders87@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2468CC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jul 2023 06:12:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id DCB0A40198
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jul 2023 06:12:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DCB0A40198
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=PRqxRztr
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id rp0ZUJ-gdax3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jul 2023 06:12:10 +0000 (UTC)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [IPv6:2a00:1450:4864:20::532])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 305E5400D2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jul 2023 06:12:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 305E5400D2
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-51e2a6a3768so491482a12.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jul 2023 23:12:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1689833528; x=1690438328;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=0UpUWbSSGTlSWFdo/sqSoZhMlTswPNB0TGjqIC3dTz0=;
 b=PRqxRztr0bRtrV2DHpjNgaURyM9nPFSump/F6IEQgKUSkH3aGH9xl7eIQtJtWs/fnS
 0f6LebrkPVAzRo0qYoNmzIF3qs9ACqvqYcAEqois4oe7EK8Y9N6JWpelstreBPATfOT2
 0SjQklQVfsNU6TVaU8+PCQU3BlAEjTZ0n5Av1ZJYQomrhF3IrvSYlch2m7U+I4UIhOeD
 JDzmC809n1JCe57rPdiw9QAOur2LH0A8MUuF3ixEUIAd02UtnA6KTUwl3op57+QvVKRO
 hjUsbBULyUZQ+jWF8oU2AVQBryL0qT6DAf2fH6P5IZFaXAMDstI0HIhNNUs47IbHxdCC
 b9Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1689833528; x=1690438328;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=0UpUWbSSGTlSWFdo/sqSoZhMlTswPNB0TGjqIC3dTz0=;
 b=hongqppqO1qA6vqG/Yb2RB4to0JmhpB3DTBEFCAdCoAknyjXKAX33Gb2s0tu8aUtcB
 zf146hkVtGP0rrYGXwPS8cnJlt1jUwlAlBdarGXRTalpeeDsvXCcJWXDki/sa94dZPwP
 t/H15ZNwVOUjyyIY6ScqO0178RPMwr7Fr+XthNzCkj2neJpoTrY6R6mgc9TgRlKsAjiK
 MHtEZBBemnDtc2d2dO14RB2wtYjE/p0v6rKrQ4ZGZ8k51DPKrITr94QelCSPGy0/tW5c
 Wnaw+y8Yk6qN/hVtFkRhK+btyjis+a/V8mnZ3xPFJE525SvS/ft3AShcAh5lTcZV7cQW
 wh3A==
X-Gm-Message-State: ABy/qLbRuV1fJcGDrqHEjGr8lZaJ6/kSJKu7w8MFYwBVBwpKJ26TElUi
 Lju7yP5H/N4ryCqybhVIMQuQwKyRY76XUJVvoGpm6rbm
X-Google-Smtp-Source: APBJJlGnCB6F7ml4WoPlQV0JWrCdxTHZ+sLeCO5rXU28WSxumquPpk0jUq4ppUfyc78eiwKjlTqn1hQxKpdaBujH7u0=
X-Received: by 2002:a17:906:77c8:b0:99b:445d:45d0 with SMTP id
 m8-20020a17090677c800b0099b445d45d0mr2822650ejn.66.1689833527858; Wed, 19 Jul
 2023 23:12:07 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+G=zhzHFTVLxLMgYeQ64srWA7GmfDrkdF+bc6q4+uTnCQ@mail.gmail.com>
 <CALeFGL0wzi0z13-H_t13fyrvy5cTo2j0f6qOL0-_zt8suMZU4A@mail.gmail.com>
 <CAB3F3DsSjtXxA3X34ky7P=QSr3rEcG94dJ6k7sO543G0HvCv-A@mail.gmail.com>
 <CALZpt+E=0OEJzXdMWse0R+f5vuc0e-W4HTkZ_rdeAjstCU8OpQ@mail.gmail.com>
In-Reply-To: <CALZpt+E=0OEJzXdMWse0R+f5vuc0e-W4HTkZ_rdeAjstCU8OpQ@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 20 Jul 2023 02:11:57 -0400
Message-ID: <CAB3F3Dus8ut7cYN5a=KZLkURCO2mXv6HEsWoTxPE0M4cdCjiZQ@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000285b420600e50735"
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 06:12:13 -0000

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

Hi antoine,

Simplicity was just a stand in for "functionally complete" handwave.

Cheers,
Greg

On Thu, Jul 20, 2023, 1:46 AM Antoine Riard <antoine.riard@gmail.com> wrote=
:

> Hi Greg,
>
> I'm very meeting your development approach with regards to starting small=
s
> about consensus change primitives, and I think taproot has demonstrated
> some good historical process, which has good archives about how developme=
nt
> was conducted (e.g the community-wide taproot review of which the Bitcoin
> Contracting Primitives WG was built on this experience [0]).
>
> I don't know about saying that the BOLTs (and its process) should be
> authoritative over the running code of implementations. While it's
> definitely a mark of some bar of technical review and inter-compatibility=
,
> I think ultimately each BOLT has to be judged individually on its own
> technical merits. And I think we had a bunch of cases in the past when "t=
he
> map is not the territory". Even there are few areas of critical Lightning
> operations which are not documented by the BOLTs to the best of my
> knowledge (such as fee-bumping and transactions broadcast reactions as it
> was for on-chain DLCs [1]).
>
> Lastly, there is a huge area of uncertainty about the technical fitness o=
f
> Simplicity for 2/small party channels. I remember a Russell O'connor
> presentation about Simplicity back in Paris (2017 or 2018 ?) and asking h=
im
> how it would work in a chain of transactions, while the answer was iirc
> "yes it has been designed with this constraint", it's a very open questio=
n
> when you have off-chain states which advances in independence from the
> on-chain state between a dynamic number of counterparties (kinda the
> interactivity issue for payment pools). Here I guess you would have to co=
me
> to a consensus to the model of logic followed for the analysis of such
> distributed systems e.g Leslie Lamport's temporal logic [2]. Additionally=
,
> the theoretical foundations on the Coq prover are still actively studied =
by
> Xavier Leroy at the College de France and some novel insights might be
> interesting for using formal verification in terms of Bitcoin consensus
> changes development (and I don't know if all the works and lessons have
> been translated from French to English).
>
> Best,
> Antoine
>
> [0] https://github.com/ajtowns/taproot-review
> [1]
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interact=
ive-Protocol.md
> [2] https://en.wikipedia.org/wiki/Temporal_logic_of_actions
>
> Le mer. 19 juil. 2023 =C3=A0 21:45, Greg Sanders <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 mor=
e
>> than CTV to get significant gains. And in the end, channels can only get=
 so
>> simple since we have many other BOLTs to deal with. And even then, you'r=
e
>> going to have to convince LN spec writers to include such changes, whate=
ver
>> they are, then get deployment.
>>
>> Step 1 is finding a primitive that seems interesting. It's important to
>> moderate enthusiasm for any primitive with reality, and probably by bein=
g
>> concrete by writing specs that use a primitive, and code it up to discov=
er
>> what we're overlooking. We're always overlooking something! In my humble
>> opinion these are step 2 and 3 of gathering mind-share.
>>
>> As a more productive tact, if we're thinking beyond 2/small party
>> channels, probably better to snap your fingers, pretend we have Simplici=
ty,
>> see what we can build, and work backwards from there to see if we can
>> accomplish this within the confines of bitcoin script?
>>
>> Cheers,
>> Greg
>>
>> On Wed, Jul 19, 2023 at 3:59=E2=80=AFPM Keagan McClelland via bitcoin-de=
v <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Antoine,
>>>
>>> Thank you for the effort you've put towards this. I generally agree tha=
t
>>> a smooth functioning Lightning Network is of greater importance than
>>> advanced contracting capabilities. However, as I dive deeper into some =
of
>>> the more ambitious goals for LN development I am learning that a great =
deal
>>> of complexity of some current lightning (LN) proposals can be handily
>>> discharged with CTV. While I am not intimately familiar with all of the
>>> other covenant schemes to the same level of technical proficiency, I ha=
ve a
>>> suspicion that a number of them, if not all of them, are capable of
>>> discharging the same flavor and amount of complexity as well. Others sh=
ould
>>> chime in if they can confirm this claim.
>>>
>>> I have been publicly on the record as supporting the addition of some
>>> covenant scheme into Bitcoin for some time and have long held on
>>> theoretical grounds that the addition of such a mechanism is both neces=
sary
>>> and inevitable if Bitcoin is to survive in the long term. However, as I=
've
>>> started to work more directly with the Lightning protocol, these
>>> theoretical and purely logical arguments became far more concrete and
>>> immediately beneficial.
>>>
>>> I say this primarily to challenge the idea that covenants are a
>>> distraction from lightning development. It may very well be that your a=
reas
>>> of focus on LN preclude you from splitting your attention and none of t=
his
>>> email should be interpreted as a criticism of you applying your efforts=
 in
>>> the highest leverage manner you can manage. That said, I don't want
>>> observers of this thread to walk away with the impression that they are=
 two
>>> independent efforts as covenants can significantly contribute to LN's
>>> maturity. When and how should they be prioritized? Unfortunately I don'=
t
>>> feel able to comment on that at this time. All I know is that Lightning
>>> would almost certainly benefit substantially from having a covenant
>>> primitive.
>>>
>>> Cheers,
>>> Keags
>>>
>>> On Tue, Jul 18, 2023 at 3:40=E2=80=AFPM Antoine Riard via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Hi list,
>>>>
>>>> Last year amid the failure of the CTV speedy trial activation and
>>>> intense conversations about a rainbow of covenant proposals, I introdu=
ced
>>>> the idea of a new community process to specify covenants [0]. This pos=
t is
>>>> to resume the experiment so far and officially mark the process mainte=
nance
>>>> as "up for grabs", as I won't actively pursue it further (after waveri=
ng on
>>>> such a decision a bit during May / June).
>>>>
>>>> Few of the goals announced at that time were to build a consistent
>>>> framework to evaluate covenant proposals, see the common grounds betwe=
en
>>>> proposals if they could be composed or combined by their authors, open=
 the
>>>> consensus  changes development process beyond the historical boundarie=
s of
>>>> Bitcoin Core and maintain high-quality technical archive as a consensu=
s
>>>> discussions have spawned half a decade from intellectual conception to
>>>> activation in average (at least for segwit, schnorr, taproot).
>>>>
>>>> Such effort was a speak-by-the-act answer to the issues in
>>>> consensus development changes pointed out by Jeremy Rubin in April of =
last
>>>> year [1]: namely the lack of a "codified checklist" for consensus chan=
ges,
>>>> that "consensus is memoryless" and "bitcoin core is not bitcoin"
>>>> (independently of the technical concerns as I have as limited or
>>>> non-adequate primitive for vaults / payment pools I expressed during t=
he
>>>> same time). Other complementary initiatives have been undertaken durin=
g the
>>>> same period, AJ with the bitcoin-inquisition fork where the community =
of
>>>> developers and contracting primitives of researchers on a consensus-en=
abled
>>>> fork of core [2]. And Dave Harding with the careful archiving of all
>>>> covenant proposals under the Optech umbrella [3].
>>>>
>>>> About the Bitcoin Contracting Primitives WG, a Github repository was
>>>> started and maintained to archive and document all the primitives (apo=
,
>>>> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
>>>> check_output_covenant_verify, inherited ids, anyamount, singletons,
>>>> op_vault) and the corresponding protocols (payment pools, vaults,
>>>> drivechains, trust-minimized mining pools payouts). We had a total of =
6
>>>> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg=
 for
>>>> a number of more than 20 individual attendees representing most of the
>>>> parts of the community. I think (missing march logs). Numerous in-dept=
h
>>>> discussions did happen on the repository and on the channel on things =
like
>>>> "merkelized all the things" or "payment pools for miners payoffs".
>>>>
>>>> As I've been busy on the Lightning-side and other Bitcoin projects,
>>>> I've not run an online meeting since the month of April, while still h=
aving
>>>> a bunch of fruitful technical discussions with folks involved in the e=
ffort
>>>> at conferences and elsewhere. I launched the effort as an experiment w=
ith
>>>> the soft commitment to dedicate 20% of my time on it, after few succes=
sful
>>>> sessions I think such a process has an interest of its own, however it
>>>> comes with direct competition of my time to work on Lightning robustne=
ss.
>>>> Getting my hands dirty on low-level LDK development recently made me
>>>> realize we still have years of titan work to get a secure and reliable
>>>> Lightning Network.
>>>>
>>>> As such, between extended covenant capabilities for advanced contracts
>>>> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
>>>> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I th=
ink
>>>> the latter goal is more critical for Bitcoin existential survival, and
>>>> where on a personal title I'll allocate the best of my time and energy=
 (and
>>>> somehow it match the "slow" technical activity on bitcoin-inquisition
>>>> mostly done by Lightning hands).
>>>>
>>>> This is my personal conclusion only on the state of Bitcoin
>>>> technological momentum, and this is quite tainted by my deep backgroun=
d in
>>>> Lightning development. If you've been working on covenant changes
>>>> proposals, please don't take it as a discouragement, I think Taproot
>>>> (privacy-preserving script policies behind the taproot tree branches) =
and
>>>> Schnorr (for native multi-sig) soft forks have shown how it can improv=
e the
>>>> building of self-custody solutions by one or two order of magnitude, a=
nd
>>>> small incremental changes might be good enough to have a lower technic=
al
>>>> consensus bar.
>>>>
>>>> On my side, I'll pursue pure R&D works on CoinPool, notably coming wit=
h
>>>> better solutions with the interactivity issue and mass-compression of
>>>> withdrawal and design exotic advanced Bitcoin contracts based on the
>>>> taproot annex, though more in a "l'art pour l'art" approach for the ti=
me
>>>> being [4]. Additionally, I might start to submit an in-depth security
>>>> review of consensus changes under pseudonyms, it has already been done=
 in
>>>> the past and somehow it's good practice in terms of "message neutralit=
y"
>>>> [5]. If folks wanna experiment in terms of payment pools deployment, G=
reg
>>>> Maxwell's old joinpool can be used today (and somehow it's worthy of i=
ts
>>>> own as a net advance for coinjoins).
>>>>
>>>> I'll honestly acknowledge towards the community, I might have
>>>> overpromised with the kickstart of this new process aiming to move the
>>>> frontlines in matters of Bitcoin consensus changes development process=
. On
>>>> the other hand, I think enough sessions of the working group have been
>>>> runned and enough marks of technical interests have been collected to
>>>> demonstrate the minimal value of such a process, so I would estimate m=
y
>>>> open-source balance sheet towards the community to be in good standing=
 ?
>>>> (open-minded question).
>>>>
>>>> I don't think Bitcoin fundamentally lacks compelling technical
>>>> proposals to advance the capabilities of Bitcoin Script today, nor the
>>>> crowd of seasoned and smart protocol developers to evaluate mature
>>>> proposals end-to-end and on multiple dimensions with a spirit of
>>>> independence. Rather, I believe what Bitcoin is lacking is a small cro=
wd of
>>>> technical historians and archivist doing the work of assessing, collec=
ting
>>>> and preserving consensus changes proposals and QA devs to ensure any
>>>> consensus change proposals has world-class battle-ground testing befor=
e to
>>>> be considered for deployment, ideally with the best standards of Bitco=
in
>>>> decentralization and FOSS neutrality [6].
>>>>
>>>> If you would like to pursue the maintenance and nurturing of the
>>>> Bitcoin Contracting Primitives WG (or the bitcoin-inquisition fork or
>>>> collaborate with Optech to organize industry-wise workshop on covenant=
s at
>>>> the image of what has been done in 2019 for Taproot), that you're will=
ing
>>>> to show proof-of-work and you estimate that operational ground, legal
>>>> information or financial resources will anchor your individual work on=
 the
>>>> long-term, don't hesitate to reach out, I'll see what I can do with a
>>>> disinterested mind [7].
>>>>
>>>> With humility,
>>>> Antoine
>>>>
>>>> [0]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/0207=
63.html
>>>> [1]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020=
233.html
>>>> [2]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September=
/020921.html
>>>> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
>>>> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
>>>> remaining "Big Problems" is still pending on my visit to co-author Gle=
b
>>>> Naumenko in Ukraine, which has been postponed few times in light of th=
e
>>>> conflict operational evolutions.
>>>> [5] See
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/=
017614.html.
>>>> For the philosophical reasons of doing so, I invite you to read Foucau=
lt's
>>>> famous essay "Le philosophe masque".
>>>> [6] Somehow I come to share Jeremy's thesis's "Product management is
>>>> not "my Job" it's yours" in matters of consensus changes. I believe we
>>>> might be past the technical complexity threshold where even simple
>>>> consensus changes can be conducted from A to Z as a one man job or eve=
n by
>>>> a group of 2/3 elite devs.
>>>> [7] I've been reached out multiple times and consistently by R&D
>>>> non-profits, plebs whales and VC firms who were interested to commit
>>>> resources to advance softforks and covenants in the Bitcoin space, no =
doubt
>>>> when you're reliable and with a track record, folks are ready to offer=
 you
>>>> opportunities to work full-time on consensus changes.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>

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

<div dir=3D"auto">Hi antoine,<div dir=3D"auto"><br></div><div dir=3D"auto">=
Simplicity was just a stand in for &quot;functionally complete&quot; handwa=
ve.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Cheers,</div><=
div dir=3D"auto">Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Thu, Jul 20, 2023, 1:46 AM Antoine Riard &lt;=
<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Greg,<di=
v><br></div><div>I&#39;m very meeting your development approach with regard=
s to starting smalls about consensus change primitives, and I think taproot=
 has demonstrated some good historical process, which has good archives abo=
ut how development was conducted (e.g the community-wide taproot review of =
which the Bitcoin Contracting Primitives WG was built on this experience [0=
]).</div><div><br></div><div>I don&#39;t know about saying that the BOLTs (=
and its process) should=C2=A0be authoritative over the running=C2=A0code of=
 implementations. While it&#39;s definitely=C2=A0a mark of some bar of tech=
nical review and inter-compatibility, I think ultimately each BOLT has to b=
e judged individually on its own technical merits. And I think we had a bun=
ch of cases in the past when &quot;the map is not the territory&quot;. Even=
 there are few areas of critical Lightning operations which are not documen=
ted by the BOLTs to the best of my knowledge (such as fee-bumping and trans=
actions broadcast reactions as it was for on-chain DLCs [1]).</div><div><br=
></div><div>Lastly, there is a huge area of uncertainty about the technical=
 fitness of Simplicity for 2/small party channels. I remember a Russell O&#=
39;connor presentation about Simplicity back in Paris (2017 or 2018 ?) and =
asking him how it would work in a chain of transactions, while the answer w=
as iirc &quot;yes it has been designed with this constraint&quot;, it&#39;s=
 a very open question when you have off-chain states which advances in inde=
pendence from the on-chain state between a dynamic number of counterparties=
 (kinda the interactivity issue for payment pools). Here I guess you would =
have to come to a consensus to the model of logic followed for the analysis=
 of such distributed systems e.g Leslie Lamport&#39;s temporal logic [2]. A=
dditionally, the theoretical foundations on the Coq prover are still active=
ly studied by Xavier Leroy at the College de France and some novel insights=
 might be interesting for using formal verification in terms of Bitcoin con=
sensus changes development (and I don&#39;t know if all the works and lesso=
ns have been translated from French to English).</div><div><br></div><div>B=
est,</div><div>Antoine</div><div><br></div><div>[0]=C2=A0<a href=3D"https:/=
/github.com/ajtowns/taproot-review" target=3D"_blank" rel=3D"noreferrer">ht=
tps://github.com/ajtowns/taproot-review</a></div><div>[1]=C2=A0<a href=3D"h=
ttps://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive=
-Protocol.md" target=3D"_blank" rel=3D"noreferrer">https://github.com/discr=
eetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protocol.md</a></div><=
div>[2]=C2=A0<a href=3D"https://en.wikipedia.org/wiki/Temporal_logic_of_act=
ions" target=3D"_blank" rel=3D"noreferrer">https://en.wikipedia.org/wiki/Te=
mporal_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, Greg Sanders &lt;<a href=3D"mailto:gsanders87@gmail.com" target=3D"_bla=
nk" rel=3D"noreferrer">gsanders87@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr">Hello Keagen,<div><br></div><div>Mo=
st of the complexity of LN cannot be resolved with covenants. Of the things=
 that can be simplified in my experience, you&#39;re going to need more tha=
n CTV to get significant gains. And in the end, channels can only get so si=
mple since we have many other BOLTs to deal with. And even then, you&#39;re=
 going to have to convince LN spec writers to include such changes, whateve=
r they are, then get deployment.</div><div><br></div><div>Step 1 is finding=
 a primitive that seems interesting. It&#39;s important to moderate enthusi=
asm for any primitive with reality, and probably by being concrete by writi=
ng specs that use a primitive, and code it up to discover what we&#39;re ov=
erlooking. We&#39;re always overlooking something! In my humble opinion the=
se=C2=A0are step=C2=A02 and 3 of gathering mind-share.</div><div><br></div>=
<div>As a more productive tact, if we&#39;re thinking beyond 2/small party =
channels, probably better to snap your fingers, pretend we have Simplicity,=
 see what we can build, and work backwards from there to see if we can acco=
mplish this within the confines of bitcoin script?=C2=A0</div><div><br></di=
v><div>Cheers,</div><div>Greg</div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 19, 2023 at 3:59=E2=80=AFPM =
Keagan McClelland via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">Hi Antoine,<div><br></div><div>Thank you for the effort you&#39;ve put t=
owards this. I generally agree that a smooth functioning Lightning Network =
is of greater importance than advanced contracting capabilities. However, a=
s I dive deeper into some of the more ambitious goals for LN development I =
am learning that a great deal of complexity of some current lightning (LN) =
proposals can be handily discharged with CTV. While I am not intimately fam=
iliar with all of the other covenant schemes to the same level of technical=
 proficiency, I have a suspicion that a number of them, if not all of them,=
 are capable of discharging the same flavor and amount of complexity as wel=
l. Others should chime in if they can confirm this claim.</div><div><br></d=
iv><div>I have been publicly on the record as supporting the addition of so=
me covenant scheme into Bitcoin for some time and have long held on theoret=
ical grounds that the addition of such a mechanism is both necessary and in=
evitable if Bitcoin is=C2=A0to survive in the long term. However, as I&#39;=
ve started to work more directly with the Lightning protocol, these theoret=
ical and purely logical arguments became far more concrete and immediately =
beneficial.</div><div><br></div><div>I say this primarily to challenge the =
idea that covenants are a distraction from lightning development. It may ve=
ry well be that your areas of focus on LN preclude you from splitting your =
attention and none of this email should be interpreted as a criticism of yo=
u applying your efforts in the highest leverage manner you=C2=A0can manage.=
 That said, I don&#39;t want observers of this thread to walk away with the=
 impression that they are two independent efforts as covenants can signific=
antly contribute to LN&#39;s maturity. When and how should they be prioriti=
zed? Unfortunately I don&#39;t feel able to comment on that at this time. A=
ll I know is that Lightning would almost certainly benefit substantially fr=
om having a covenant primitive.</div><div><br></div><div>Cheers,</div><div>=
Keags</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Tue, Jul 18, 2023 at 3:40=E2=80=AFPM Antoine Riard via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; 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>Last year amid the failure of the CTV speedy trial activation and inte=
nse conversations about a rainbow of covenant proposals, I introduced the i=
dea of a new community process to specify covenants [0]. This post is to re=
sume the experiment so far and officially mark the process maintenance as &=
quot;up for grabs&quot;, as I won&#39;t actively pursue it further (after w=
avering=C2=A0on such a decision a bit during May / June).</div><div><br></d=
iv><div>Few of the goals announced at that time were to build a consistent =
framework to evaluate covenant proposals, see the common grounds between pr=
oposals if they could be composed or combined=C2=A0by their authors, open t=
he consensus=C2=A0 changes development process beyond the historical bounda=
ries of Bitcoin Core and maintain=C2=A0high-quality technical archive as a =
consensus discussions have spawned half a decade from intellectual concepti=
on to activation in average (at least for segwit, schnorr, taproot).</div><=
div><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 c=
onsensus changes, that &quot;consensus is memoryless&quot; and &quot;bitcoi=
n core is not bitcoin&quot; (independently of the technical concerns as I h=
ave as limited or non-adequate primitive for vaults / payment pools I expre=
ssed during the same time). Other complementary initiatives have been under=
taken during the same period, AJ with the bitcoin-inquisition fork where th=
e community of developers and contracting primitives of researchers on a co=
nsensus-enabled fork of core [2]. And Dave Harding with the careful archivi=
ng of all covenant proposals under the Optech umbrella [3].</div><div><br><=
/div><div>About the Bitcoin Contracting Primitives WG, a Github repository =
was started and maintained to archive and document all the primitives (apo,=
 tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict, che=
ck_output_covenant_verify, inherited ids, anyamount, singletons, op_vault) =
and the corresponding protocols (payment pools, vaults, drivechains, trust-=
minimized mining pools payouts). We had a total of 6 monthly meetings on th=
e Libera chat #bitcoin-contracting-primitives-wg for a number of more than =
20 individual attendees representing most of the parts of the community. I =
think (missing march logs). Numerous in-depth discussions did happen on the=
 repository and on the channel on things like &quot;merkelized all the thin=
gs&quot; or &quot;payment pools for miners payoffs&quot;.</div><div><br></d=
iv><div>As I&#39;ve been busy on the Lightning-side and other Bitcoin proje=
cts, I&#39;ve not run an online meeting since the month of April, while sti=
ll having a bunch of fruitful technical discussions with folks involved in =
the effort at conferences and elsewhere. I launched the effort as an experi=
ment with the soft commitment to dedicate 20% of my time on it, after few s=
uccessful sessions I think such a process has an interest of its own, howev=
er it comes with direct competition of my time to work on Lightning robustn=
ess. Getting my hands dirty on low-level LDK development recently made me r=
ealize we still have years of titan work to get a secure and reliable Light=
ning Network.</div><div><br></div><div>As such, between extended covenant c=
apabilities for advanced contracts coming as a reality for Bitcoin _or_ LN =
working smoothly at scale with 50-100M UTXO-sharing users on it during the =
next 5-7 years cycle, I think the latter goal is more critical for Bitcoin =
existential survival, and where on a personal title I&#39;ll allocate the b=
est of my time and energy (and somehow it match the &quot;slow&quot; techni=
cal activity on bitcoin-inquisition mostly done by Lightning hands).</div><=
div><br></div><div>This is my personal conclusion only on the state of Bitc=
oin technological momentum, and this is quite tainted by my deep background=
 in Lightning development. If you&#39;ve been working on covenant changes p=
roposals, please don&#39;t take it as a discouragement, I think Taproot (pr=
ivacy-preserving script policies behind the taproot tree branches) and Schn=
orr (for native multi-sig) soft forks have shown how it can improve the bui=
lding of self-custody solutions by one or two order of magnitude, and small=
 incremental changes might be good enough to have a lower technical consens=
us bar.</div><div><br></div><div>On my side, I&#39;ll pursue pure R&amp;D w=
orks on CoinPool, notably coming with better solutions with the interactivi=
ty issue and mass-compression of withdrawal and design exotic advanced Bitc=
oin contracts based on the taproot annex, though more in a &quot;l&#39;art =
pour l&#39;art&quot; approach for the time being [4]. Additionally, I might=
 start to submit an in-depth security review of consensus changes under pse=
udonyms, it has already been done in the past and somehow it&#39;s good pra=
ctice in terms of &quot;message neutrality&quot; [5]. If folks wanna experi=
ment in terms of payment pools deployment, Greg Maxwell&#39;s old joinpool =
can be used today (and somehow it&#39;s worthy of its own as a net advance =
for coinjoins).</div><div><br></div><div>I&#39;ll honestly acknowledge towa=
rds the community, I might have overpromised with the kickstart of this new=
 process aiming to move the frontlines in matters of Bitcoin consensus chan=
ges development process. On the other hand, I think enough sessions of the =
working group have been runned and enough marks of technical interests have=
 been collected to demonstrate the minimal value of such a process, so I wo=
uld estimate my open-source balance sheet towards the community to be in go=
od standing ? (open-minded question).</div><div><br></div><div>I don&#39;t =
think Bitcoin fundamentally lacks compelling technical proposals to advance=
 the capabilities of Bitcoin Script today, nor the crowd of seasoned and sm=
art protocol developers to evaluate mature proposals end-to-end and on mult=
iple dimensions with a spirit of independence. Rather, I believe what Bitco=
in is lacking is a small crowd of technical historians and archivist doing =
the work of assessing, collecting and preserving consensus changes proposal=
s and QA devs to ensure any consensus change proposals has world-class batt=
le-ground testing before to be considered for deployment, ideally with the =
best standards of Bitcoin decentralization and FOSS neutrality [6].</div><d=
iv><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 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 wi=
lling to show proof-of-work and you estimate that operational ground, legal=
 information or financial resources will anchor your individual work on the=
 long-term, don&#39;t hesitate to reach out, I&#39;ll see what I can do wit=
h a disinterested mind [7].</div><div><br></div><div>With humility,</div><d=
iv>Antoine</div><div><br></div><div>[0]=C2=A0<a href=3D"https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-July/020763.html" target=3D"_blan=
k" rel=3D"noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-d=
ev/2022-July/020763.html</a></div><div>[1]=C2=A0<a href=3D"https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html" target=3D"_=
blank" rel=3D"noreferrer">https://lists.linuxfoundation.org/pipermail/bitco=
in-dev/2022-April/020233.html</a></div><div>[2]=C2=A0<a href=3D"https://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html" ta=
rget=3D"_blank" rel=3D"noreferrer">https://lists.linuxfoundation.org/piperm=
ail/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" rel=3D"noreferrer">https://github.com/bitcoinops/bitcoinops.github.=
io/pull/806</a></div><div>[4] Version 0.2 of the CoinPool whitepaper addres=
sing 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 t=
imes in light of the conflict operational evolutions.</div><div>[5] See=C2=
=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-=
February/017614.html" target=3D"_blank" rel=3D"noreferrer">https://lists.li=
nuxfoundation.org/pipermail/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 philosophe masque&quot;.</div><div>[6] Somehow I come=
 to share Jeremy&#39;s thesis&#39;s &quot;Product management is not &quot;m=
y Job&quot; it&#39;s yours&quot; in matters of consensus changes. I believe=
 we might be past the technical complexity threshold where even simple cons=
ensus changes can be conducted from A to Z as a one man job or even by a gr=
oup of 2/3 elite devs.</div><div>[7] I&#39;ve been reached out multiple tim=
es and consistently by R&amp;D non-profits, plebs whales and VC firms who w=
ere interested to commit resources=C2=A0to advance softforks and covenants =
in the Bitcoin space, no doubt when you&#39;re reliable and with a track re=
cord, folks are ready to offer you opportunities to work full-time on conse=
nsus changes.</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/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" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>

--000000000000285b420600e50735--