MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 18 Jul 2023 21:18:49 +0100
Message-ID: <CALZpt+G=zhzHFTVLxLMgYeQ64srWA7GmfDrkdF+bc6q4+uTnCQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000023ccbb0600c8a000"
Subject: [bitcoin-dev] On the experiment of the Bitcoin Contracting
 Primitives WG and marking this community process "up for grabs"
Precedence: list

--00000000000023ccbb0600c8a000
Content-Type: text/plain; charset="UTF-8"

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 idea
of a new community process to specify covenants [0]. This post is to resume
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 the
consensus  changes development process beyond the historical boundaries of
Bitcoin Core and maintain high-quality technical archive as a consensus
discussions have spawned half a decade from intellectual conception to
activation in average (at least for segwit, schnorr, taproot).

Such effort was a speak-by-the-act answer to the issues in
consensus development changes pointed out by Jeremy Rubin in April of last
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 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].

About the Bitcoin Contracting Primitives WG, a Github repository was
started and maintained to archive and document all the primitives (apo,
tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
check_output_covenant_verify, inherited ids, anyamount, singletons,
op_vault) and the corresponding protocols (payment pools, vaults,
drivechains, trust-minimized mining pools payouts). We had a total of 6
monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for
a number of more than 20 individual attendees representing most of the
parts of the community. I think (missing march logs). Numerous in-depth
discussions did happen on the repository and on the channel on things 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 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 successful
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 (and
somehow it match the "slow" technical activity on bitcoin-inquisition
mostly done by Lightning hands).

This is my personal conclusion only on the state of Bitcoin technological
momentum, and this is quite tainted by my deep background in Lightning
development. If you've been working on covenant changes proposals, please
don't take it as a discouragement, I think Taproot (privacy-preserving
script policies behind the taproot tree branches) 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 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 consensus 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/020921.html
[3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
[4] Version 0.2 of the CoinPool whitepaper addressing most of the remaining
"Big Problems" is still pending on my visit to co-author Gleb Naumenko in
Ukraine, which has been postponed few times in light of the conflict
operational evolutions.
[5] See
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.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 changes
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 doubt
when you're reliable and with a track record, folks are ready to offer you
opportunities to work full-time on consensus changes.

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

<div dir=3D"ltr">Hi list,<div><br></div><div>Last year amid the failure of =
the CTV speedy trial activation and intense conversations about a rainbow o=
f covenant proposals, I introduced the idea of a new community process to s=
pecify covenants [0]. This post is to resume the experiment so far and offi=
cially mark the process maintenance as &quot;up for grabs&quot;, as I won&#=
39;t actively pursue it further (after wavering=C2=A0on such a decision a b=
it during May / June).</div><div><br></div><div>Few of the goals announced =
at that time were to build a consistent framework to evaluate covenant prop=
osals, see the common grounds between proposals if they could be composed o=
r combined=C2=A0by their authors, open the consensus=C2=A0 changes developm=
ent process beyond the historical boundaries of Bitcoin Core and maintain=
=C2=A0high-quality technical archive as a consensus discussions have spawne=
d half a decade from intellectual conception to activation in average (at l=
east for segwit, schnorr, taproot).</div><div><br></div><div>Such effort wa=
s a speak-by-the-act answer to the issues in consensus=C2=A0development cha=
nges pointed out by Jeremy Rubin in April of last year [1]: namely the lack=
 of a &quot;codified checklist&quot; for consensus changes, that &quot;cons=
ensus is memoryless&quot; and &quot;bitcoin core is not bitcoin&quot; (inde=
pendently of the technical concerns as I have as limited or non-adequate pr=
imitive 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 con=
tracting primitives of researchers on a consensus-enabled fork of core [2].=
 And Dave Harding with the careful archiving of all covenant proposals unde=
r the Optech umbrella [3].</div><div><br></div><div>About the Bitcoin Contr=
acting Primitives WG, a Github repository was started and maintained to arc=
hive and document all the primitives (apo, tluv, ctv, the taproot annex, si=
ghash_group, CSFS, cat, txhash, evict, check_output_covenant_verify, inheri=
ted 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-contractin=
g-primitives-wg for a number of more than 20 individual attendees represent=
ing most of the parts of the community. I think (missing march logs). Numer=
ous in-depth discussions did happen on the repository and on the channel on=
 things like &quot;merkelized all the things&quot; or &quot;payment pools f=
or miners payoffs&quot;.</div><div><br></div><div>As I&#39;ve been busy on =
the Lightning-side and other Bitcoin projects, I&#39;ve not run an online m=
eeting since the month of April, while still having a bunch of fruitful tec=
hnical discussions with folks involved in the effort at conferences and els=
ewhere. I launched the effort as an experiment with the soft commitment to =
dedicate 20% of my time on it, after few successful sessions I think such a=
 process has an interest of its own, however it comes with direct competiti=
on of my time to work on Lightning robustness. Getting my hands dirty on lo=
w-level LDK development recently made me realize we still have years of tit=
an work to get a secure and reliable Lightning Network.</div><div><br></div=
><div>As such, between extended covenant capabilities for advanced contract=
s 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 o=
n a personal title I&#39;ll allocate the best of my time and energy (and so=
mehow it match the &quot;slow&quot; technical activity on bitcoin-inquisiti=
on mostly done by Lightning hands).</div><div><br></div><div>This is my per=
sonal conclusion only on the state of Bitcoin technological momentum, and t=
his is quite tainted by my deep background in Lightning development. If you=
&#39;ve been working on covenant changes proposals, please don&#39;t take i=
t as a discouragement, I think Taproot (privacy-preserving script policies =
behind the taproot tree branches) and Schnorr (for native multi-sig) soft f=
orks have shown how it can improve the building of self-custody solutions b=
y one or two order of magnitude, and small incremental changes might be goo=
d 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 interactivity issue and mass-compression of =
withdrawal and design exotic advanced Bitcoin contracts based on the taproo=
t 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 secu=
rity review of consensus changes under pseudonyms, it has already been done=
 in the past and somehow it&#39;s good practice in terms of &quot;message n=
eutrality&quot; [5]. If folks wanna experiment in terms of payment pools de=
ployment, 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></d=
iv><div>I&#39;ll honestly acknowledge towards the community, I might have o=
verpromised with the kickstart of this new process aiming to move the front=
lines in matters of Bitcoin consensus changes development process. On the o=
ther hand, I think enough sessions of the working group have been runned an=
d 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 questi=
on).</div><div><br></div><div>I don&#39;t think Bitcoin fundamentally lacks=
 compelling technical proposals to advance the capabilities of Bitcoin Scri=
pt today, nor the crowd of seasoned and smart protocol developers to evalua=
te 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 conse=
nsus change proposals has world-class battle-ground testing before to be co=
nsidered for deployment, ideally with the best standards of Bitcoin decentr=
alization and FOSS neutrality [6].</div><div><br></div><div>If you would li=
ke to pursue the maintenance and nurturing of the Bitcoin Contracting Primi=
tives WG (or the bitcoin-inquisition fork or collaborate with Optech to org=
anize industry-wise workshop on covenants at the image of what has been don=
e in 2019 for Taproot), that you&#39;re willing to show proof-of-work and y=
ou estimate that operational ground, legal information or financial resourc=
es will anchor your individual work on the long-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><d=
iv>[0]=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-=
dev/2022-July/020763.html">https://lists.linuxfoundation.org/pipermail/bitc=
oin-dev/2022-July/020763.html</a></div><div>[1]=C2=A0<a href=3D"https://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html">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">https://lists.linuxfoundation.org/=
pipermail/bitcoin-dev/2022-September/020921.html</a></div><div>[3]=C2=A0<a =
href=3D"https://github.com/bitcoinops/bitcoinops.github.io/pull/806">https:=
//github.com/bitcoinops/bitcoinops.github.io/pull/806</a></div><div>[4] Ver=
sion 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 ope=
rational evolutions.</div><div>[5] See=C2=A0<a href=3D"https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2020-February/017614.html">https://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html</a>. =
For the philosophical reasons of doing so, I invite you to read Foucault=
9;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 &qu=
ot;my Job&quot; it&#39;s yours&quot; in matters of consensus changes. I bel=
ieve 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 even by =
a group of 2/3 elite devs.</div><div>[7] I&#39;ve been reached out multiple=
 times and consistently by R&amp;D non-profits, plebs whales and VC firms w=
ho were interested to commit resources=C2=A0to advance softforks and covena=
nts in the Bitcoin space, no doubt when you&#39;re reliable and with a trac=
k record, folks are ready to offer you opportunities to work full-time on c=
onsensus changes.</div></div>

--00000000000023ccbb0600c8a000--