MIME-Version: 1.0
References: <CALZpt+G=zhzHFTVLxLMgYeQ64srWA7GmfDrkdF+bc6q4+uTnCQ@mail.gmail.com>
In-Reply-To: <CALZpt+G=zhzHFTVLxLMgYeQ64srWA7GmfDrkdF+bc6q4+uTnCQ@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Wed, 19 Jul 2023 12:29:24 -0600
Message-ID: <CALeFGL0wzi0z13-H_t13fyrvy5cTo2j0f6qOL0-_zt8suMZU4A@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000abca890600db36b4"
Subject: Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting
 Primitives WG and marking this community process "up for grabs"
Precedence: list

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

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 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 should
chime in if they can confirm this claim.

I have been publicly on the record as supporting the addition of some
covenant scheme into Bitcoin for some time and have long held on
theoretical grounds that the addition of such a mechanism is both necessary
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 areas of focus on
LN preclude you from splitting your attention and none of this 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 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 "up
> for grabs", as I won't actively pursue it further (after wavering 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 between
> proposals if they could be composed or combined by their authors, open th=
e
> consensus  changes development process beyond the historical boundaries o=
f
> 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 las=
t
> year [1]: namely the lack of a "codified checklist" for consensus 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 during the
> same time). Other complementary initiatives have been undertaken during t=
he
> same period, AJ with the bitcoin-inquisition fork where the community of
> developers and contracting primitives of researchers on a consensus-enabl=
ed
> 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 fo=
r
> 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 lik=
e
> "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 effort
> at conferences and elsewhere. I launched the effort as an experiment with
> the soft commitment to dedicate 20% of my time on it, after few successfu=
l
> 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 think
> 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 (a=
nd
> 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) and 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, 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 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, Greg
> Maxwell's old joinpool can be used today (and somehow it's worthy of its
> own as a net advance for coinjoins).
>
> I'll honestly acknowledge towards the community, I might have overpromise=
d
> 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 th=
e
> minimal value of such a process, so I would estimate my open-source balan=
ce
> sheet towards the community to be in good standing ? (open-minded questio=
n).
>
> 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 consensu=
s
> 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 collaborate
> with Optech to organize industry-wise workshop on covenants at the image =
of
> what has been done in 2019 for Taproot), that you're willing 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/020763.=
html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233=
.html
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/02=
0921.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/017=
614.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 chang=
es
> 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 dou=
bt
> when you're reliable and with a track record, folks are ready to offer yo=
u
> 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
>

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

<div dir=3D"ltr">Hi Antoine,<div><br></div><div>Thank you for the effort yo=
u&#39;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&#39;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&#39;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&#39;s maturity. When and how should th=
ey be prioritized? Unfortunately I don&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi list,<div><b=
r></div><div>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 maintena=
nce as &quot;up for grabs&quot;, as I won&#39;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 con=
sistent framework to evaluate covenant proposals, see the common grounds be=
tween proposals if they could be composed or combined=C2=A0by their authors=
, open the consensus=C2=A0 changes development process beyond the historica=
l boundaries of Bitcoin Core and maintain=C2=A0high-quality technical archi=
ve as a consensus discussions have spawned half a decade from intellectual =
conception 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 i=
n April of last year [1]: namely the lack of a &quot;codified checklist&quo=
t; for consensus changes, that &quot;consensus is memoryless&quot; and &quo=
t;bitcoin core is not bitcoin&quot; (independently of the technical concern=
s as I have as limited or non-adequate primitive for vaults / payment pools=
 I expressed during the same time). Other complementary initiatives have be=
en undertaken during the same period, AJ with the bitcoin-inquisition fork =
where the community of developers and contracting primitives of researchers=
 on a consensus-enabled fork of core [2]. And Dave Harding with the careful=
 archiving of all covenant proposals under the Optech umbrella [3].</div><d=
iv><br></div><div>About the Bitcoin Contracting Primitives WG, a Github rep=
ository was started and maintained to archive and document all the primitiv=
es (apo, tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, ev=
ict, 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 meetin=
gs on the Libera chat #bitcoin-contracting-primitives-wg for a number of mo=
re than 20 individual attendees representing most of the parts of the commu=
nity. I think (missing march logs). Numerous in-depth discussions did happe=
n on the repository 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 Bitco=
in projects, I&#39;ve not run an online meeting since the month of April, w=
hile still having a bunch of fruitful technical discussions with folks invo=
lved in the effort at conferences and elsewhere. I launched the effort as a=
n experiment with the soft commitment to dedicate 20% of my time on it, aft=
er few successful sessions I think such a process has an interest of its ow=
n, however it comes with direct competition of my time to work on Lightning=
 robustness. Getting my hands dirty on low-level LDK development recently m=
ade me realize we still have years of titan work to get a secure and reliab=
le Lightning Network.</div><div><br></div><div>As such, between extended co=
venant capabilities for advanced contracts coming as a reality for Bitcoin =
_or_ LN working smoothly at scale with 50-100M UTXO-sharing users on it dur=
ing 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 alloca=
te the best of my time and energy (and somehow it match the &quot;slow&quot=
; technical activity on bitcoin-inquisition mostly done by Lightning hands)=
.</div><div><br></div><div>This is my personal conclusion only on the state=
 of Bitcoin technological momentum, and this is quite tainted by my deep ba=
ckground in Lightning development. If you&#39;ve been working on covenant c=
hanges proposals, please don&#39;t take it as a discouragement, I think Tap=
root (privacy-preserving script policies behind the taproot tree branches) =
and 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, a=
nd small incremental 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 works on CoinPool, notably coming with better solutions with the int=
eractivity issue and mass-compression of withdrawal and design exotic advan=
ced Bitcoin 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 u=
nder pseudonyms, it has already been done in the past and somehow it&#39;s =
good practice in terms of &quot;message neutrality&quot; [5]. If folks wann=
a experiment in terms of payment pools deployment, Greg Maxwell&#39;s old j=
oinpool 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 acknowle=
dge towards the community, I might have overpromised with the kickstart of =
this new process aiming to move the frontlines in matters of Bitcoin consen=
sus changes development process. On the other hand, I think enough sessions=
 of the working group have been runned and enough marks of technical intere=
sts 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).</div><div><br></div><div>I do=
n&#39;t think Bitcoin fundamentally lacks compelling technical proposals to=
 advance the capabilities of Bitcoin Script today, nor the crowd of seasone=
d and smart protocol developers to evaluate mature proposals end-to-end and=
 on multiple dimensions with a spirit of independence. Rather, I believe wh=
at Bitcoin is lacking is a small crowd of technical historians and archivis=
t doing the work of assessing, collecting and preserving consensus changes =
proposals and QA devs to ensure any consensus change proposals has world-cl=
ass battle-ground testing before to be considered for deployment, ideally w=
ith the best standards of Bitcoin decentralization and FOSS neutrality [6].=
</div><div><br></div><div>If you would like to pursue the maintenance and n=
urturing of the Bitcoin Contracting Primitives WG (or the bitcoin-inquisiti=
on fork or collaborate with Optech to organize industry-wise workshop on co=
venants at the image of what has been done in 2019 for Taproot), that you&#=
39;re willing to show proof-of-work and you estimate that operational groun=
d, legal information or financial resources will anchor your individual wor=
k on the long-term, don&#39;t hesitate to reach out, I&#39;ll see what I ca=
n 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://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html" target=
=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Ju=
ly/020763.html</a></div><div>[1]=C2=A0<a href=3D"https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2022-April/020233.html" target=3D"_blank">htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html=
</a></div><div>[2]=C2=A0<a href=3D"https://lists.linuxfoundation.org/piperm=
ail/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.githu=
b.io/pull/806" target=3D"_blank">https://github.com/bitcoinops/bitcoinops.g=
ithub.io/pull/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] S=
ee=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2020-February/017614.html" target=3D"_blank">https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2020-February/017614.html</a>. For the philosophi=
cal 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 Jere=
my&#39;s thesis&#39;s &quot;Product management is not &quot;my Job&quot; it=
&#39;s yours&quot; in matters of consensus changes. I believe we might be p=
ast the technical complexity threshold where even simple consensus changes =
can be conducted from A to Z as a one man job or even by a group of 2/3 eli=
te devs.</div><div>[7] I&#39;ve been reached out multiple times and consist=
ently 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 ar=
e 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>

--000000000000abca890600db36b4--