MIME-Version: 1.0
References: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
 <XSc7hh8TBcrQc8YsYbCj4dmf3YkdQwJAv50lIcAK7rMYH9gChkn_S3SkJFmATwCrD-klYeJ55FajcGQ1HVuY0msxyiah8rLbVlQG7sXkAmo=@protonmail.com>
In-Reply-To: <XSc7hh8TBcrQc8YsYbCj4dmf3YkdQwJAv50lIcAK7rMYH9gChkn_S3SkJFmATwCrD-klYeJ55FajcGQ1HVuY0msxyiah8rLbVlQG7sXkAmo=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sat, 23 Jul 2022 17:41:55 +0100
Message-ID: <CALZpt+HerfG6hfkPksN=0ih5pRP6m0qAnxH3au7h3gadnHPKdQ@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000093d3b305e47ba124"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Precedence: list

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

Hi Michael,

> One cautionary word from someone who is probably still feeling the
effects of burn out from the activation drama earlier in the year. No
process can guarantee community > consensus at the end of it especially if
some of those who we consider experts in this area only tentatively
participate. The personal attacks and ignoring of views counter >to those
who were pushing an activation attempt really should not be repeated.
(Especially if this process is seeking to include those who we consider
experts in this area > and don't want their participation to be perceived
as tacit approval of whatever is attempted next.)

I'm thinking such a covenant effort would be more a technical process
aiming to advance the state of covenant & contracting knowledge, collect
and document the use-cases, exchange engineering learnings from the
prototype, share the problem space, etc. In the same fashion we have the
BOLT one or even more remote the IETF working groups about a bunch of
Internet technology [0]. I think that Taproot/Schnorr has set a high
standard in terms of safety-first and careful Bitcoin engineering effort,
aggregating 8 years of thinking around MAST and friends but also exploring
other signature schemes like BLS. And I hope with covenants we aim for
higher standards, as if there is one learning from Taproot we could have
spent more time working out use-cases prototypes (e.g joinpools) and
standard libraries to mature, it could have save actual headache around
x-pubkeys [1]

In my perspective, activation is more a matter of release engineering and
community communications, and failing to a game-theory situation where
miners incentives are computed is more a hint of a social layer failure.
When we start to consider the moves and incentives of categories of Bitcoin
players (miners, users, exchanges, ...), I would say we failed to keep the
community as one and increase the safety risks for everyone's coins.

Minding that, and to maximize the participation in such a covenant
specification process, similar to the usual Chatham House rules in
engineering meetings, I believe it could be good to have a "No Activation -
No Timeframe" rule in such a covenant process, and defer any activation
discussion to a future process of its own.

> As long as this is understood and agreed by participants I can only see
positives coming out of this. But please let's not repeat the activation
drama from earlier in the year > because a process with a subset of those
who we would consider experts in this area come to a view and then try to
ram that view down everyone's throats by attempting > activation at the end
of it. Maybe this will result in community consensus on covenant
proposal(s) going forward but also maybe it won't. Either outcome is fine.
At the very > least research will progress and work will be carried out
that moves us in a positive direction

During the last LN Summit in Oakland, there was chit-chat on how long it
would take to get a mature version of Lightning, and the answer from a
seasoned FOSS developer was 25 years. Considering the heavy LN
problem-space, I think this was a wise take and I believe with covenants we
would have to think in that 10/20 years perspective if we aim for a
satisfying and complete covenant toolchain. It doesn't mean we are not
going to be able to deploy piece by piece, however there is a strong
emphasis to be done on the archiving part itself. Some of the process
stakeholders might still not be active in their engineering careers when
the issues should be weighted for consensus activation and transmission of
knowledge across generations of stakeholders is going to be an issue (as we
already see it in Bitcoin Core with some critical subsystems). And if there
is never community consensus on covenant proposals, that's fine. To me the
research would have been interesting in itself and I hope it will be the
same for other participants.

[0] https://datatracker.ietf.org/wg/
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020663.ht=
ml

Le sam. 23 juil. 2022 =C3=A0 15:25, Michael Folkson <
michaelfolkson@protonmail.com> a =C3=A9crit :

> Hi Antoine
>
> This looks great and I can certainly see progress being made in a number
> of directions on this. I thought you did a great job with the L2 onchain
> support workshops and I'm sure you'll do a great job moving this forward.
>
> One cautionary word from someone who is probably still feeling the effect=
s
> of burn out from the activation drama earlier in the year. No process can
> guarantee community consensus at the end of it especially if some of thos=
e
> who we consider experts in this area only tentatively participate. The
> personal attacks and ignoring of views counter to those who were pushing =
an
> activation attempt really should not be repeated. (Especially if this
> process is seeking to include those who we consider experts in this area
> and don't want their participation to be perceived as tacit approval of
> whatever is attempted next.)
>
> As long as this is understood and agreed by participants I can only see
> positives coming out of this. But please let's not repeat the activation
> drama from earlier in the year because a process with a subset of those w=
ho
> we would consider experts in this area come to a view and then try to ram
> that view down everyone's throats by attempting activation at the end of
> it. Maybe this will result in community consensus on covenant proposal(s)
> going forward but also maybe it won't. Either outcome is fine. At the ver=
y
> least research will progress and work will be carried out that moves us i=
n
> a positive direction.
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Wednesday, July 20th, 2022 at 21:42, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi,
>
> Discussions on covenants have been prolific and intense on this mailing
> list and within the wider Bitcoin technical circles, I believe however
> without succeeding to reach consensus on any new set of contracting
> primitives satisfying the requirements of known covenant-enabled use-case=
s.
> I think that's a fact to deplore as covenants would not only offer vast
> extensions of the capabilities of Bitcoin as a system, i.e enabling new
> types of multi-party contract protocols. But also empowering Bitcoin on i=
ts
> fundamental value propositions of store of value (e.g by making vaults mo=
re
> flexible) and payment system (e.g by making realistic channel
> factories/payment pools).
>
> If we retain as a covenant definition, a spending constraint restricting
> the transaction to which the spent UTXO can be spent, and enabling to
> program contracts/protocols at the transaction-level instead of the
> script-level, the list of Script primitives proposed during the last year=
s
> has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1],
> CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4],
> PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROU=
P
> [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, a=
ll
> the listed primitives are at different states of formalization, some
> already fully fleshed-out in BIPs, other still ideas on whiteboard, yet
> they all extend the range of workable multi-party contract protocols.
>
> Indeed this range has grown wild. Without aiming to be exhaustive (I'm
> certainly missing some interesting proposals lost in the abyss of
> bitcointalk.org), we can mention the following use-cases: multi-party
> stateful contracts [11], congestion trees [12], payment pools [13], "elto=
o"
> layered commitments [14], programmable vaults [15], multi-events contract=
s
> [16], blockchain-as-oracle bets [17], spacechains [18], trustless
> collateral lending [19], ...
>
> Minding all those facts, I would say the task of technical evaluation of
> any covenant proposal sounds at least two fold. There is first reasoning
> about the enabled protocols on a range of criterias such as scalability,
> efficiency, simplicity, extensibility, robustness, data confidentiality,
> etc. Asking questions like what are the interactions between layers, if a=
ny
> ? Or how robust is the protocol, not just interactivity failure between
> participant nodes but in the face of mempools spikes or internet disrupti=
on
> ? Or if the performance is still acceptable on shared resources like
> blockspace or routing tables if everyone is using this protocol ? Or if t=
he
> protocol minimizes regulatory attack surface or centralization vectors ?
>
> Though once this step is achieved, there is still more reasoning work to
> evaluate how good a fit is a proposed Script primitive, the
> efficiency/simplicity/ease to use trade-offs, but also if there are no
> functionality overlap or hard constraints on the use-cases design
> themselves or evolvability w.rt future Script extensions or generalizatio=
n
> of the opcode operations.
>
> Moreover, if you would like your evaluation of a covenant proposal to be
> complete, I don't believe you can squeeze the implications with the mempo=
ol
> rules and combination with any consistent fee-bumping strategy. To say
> things politely, those areas have been a quagmire of vulnerabilities,
> attacks and defects for second-layers Bitcoin protocols during the last
> years [20].
>
> Considering the abundant problem-space offered by covenants, I believe
> there is a reasonable groundwork to pursue in building the use-cases
> understanding (e.g prototype, pseudo-specification, documentation, ...) a=
nd
> building consensus on the framework of criterias on which to evaluate the=
m
> [21]. It might raise a really high bar for any covenant proposal compared
> to previous softforks, however I think it would adequately reflect the
> growth in Bitcoin complexity and funds at stakes during the last years.
>
> Moving towards this outcome, I would like to propose a new covenant open
> specification process, in the same spirit as we have with the BOLTs or
> dlcspecs. We would have regular meetings (biweekly/monthly ?), an open
> agenda where topics of discussion can be pinned in advance and
> documentation artifacts would be built with time driven by consensus (e.g
> 1st phase could be to collect, pseudo-specify and find champion(s) for
> known use-cases ?) and no timeframe. Starting date could be September /
> October / November (later, 2023 ?), giving time for anyone interested in
> such a covenant process to allocate development and contribution bandwidt=
h
> in function of their involvement interest.
>
> Learning from the good but specially from the bad with setting up the L2
> onchain support meetings last year, I think it would be better to keep th=
e
> agenda open, loose and free as much we can in a "burn-the-roadmap" spirit=
,
> avoiding to create a sense of commitment or perceived signaling in the
> process participants towards any covenant solution. I would guess things =
to
> be experimental and evolutionary and folks to spend the first meetings
> actually to express what they would like the covenant process to be about
> (and yes that means if you're a domain expert and you find the pace of
> things too slow sometimes, you have to learn to handle your own
> frustration...).
>
> In a "decentralize-everything" fashion, I believe it would be good to hav=
e
> rotating meeting chairs and multiple covenant documentation archivists. I=
'm
> super happy to spend the time and energy bootstrapping well such covenant
> process effort, though as it's Bitcoin learn to decentralize yourself.
>
> I'm really curious what the outcome of such a covenant process would look
> like. We might end up concluding that complex covenants are too unsafe by
> enabling sophisticated MEV-attacks against LN [22]. Or even if there is a=
n
> emergent technical consensus, it doesn't mean there is a real market
> interest for such covenant solutions. That said, I'm not sure if it's
> really a subject of concern when you're reasoning as a scientist/engineer
> and you value technical statements in terms of accuracy, systematic
> relevance and intrinsic interest.
>
> Overall, my motivation to kick-start such a process stays in the fact tha=
t
> covenants are required building blocks to enable scalable payments pools
> design like CoinPool. I believe payments pools are a) cool and b) a good
> shot at scaling Bitcoin as a payment system once we have reached
> scalability limits of Lightning, still under the same security model for
> users. However, as a community we might sense it's not the good timing fo=
r
> a covenant process. I'm really fine with that outcome as there are still
> holes to patch in LN to keep me busy enough for the coming years.
>
> Zooming out, I believe with any discussion about covenants or other soft
> forks, the hard part isn't about coming up with the best technical soluti=
on
> to a set of problems but in the iterative process where all voices are
> listened to reach (or not) consensus on what is actually meant by "best"
> and if the problems are accurate. The real physics of Bitcoin is the
> physics of people. It's a work of patience.
>
> Anyways, eager to collect feedbacks on what the ideal covenant
> specification process looks like. As usual, all opinions and mistakes are
> my own.
>
> Cheers,
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [1] https://bitcoinops.org/en/topics/op_checksigfromstack/
> [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [3]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/01=
9419.html
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198=
13.html
> [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
> [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019=
926.html
> [8]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015=
700.html
> [9]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.=
html
> [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198=
08.html
> [12]
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion=
_Controlled_Transactions
> [13]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.=
html
> [14]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00=
2448.html
> [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
> [16]
> https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
> [17] https://blog.bitmex.com/taproot-you-betcha/
> [18]
> https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spac=
echains
> [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
> [20] https://github.com/jamesob/mempool.work
> [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [22] https://blog.bitmex.com/txwithhold-smart-contracts/
>
>
>

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

<div dir=3D"ltr">Hi Michael,<div><br></div><div><span style=3D"font-family:=
Arial;font-size:14px">&gt;=C2=A0</span><span style=3D"font-family:Arial;fon=
t-size:14px">One cautionary word from someone who is probably still feeling=
 the effects of </span>burn out<span style=3D"font-family:Arial;font-size:1=
4px"> from the activation drama earlier in the year. No process can guarant=
ee community &gt; consensus at the end of </span>it especially<span style=
=3D"font-family:Arial;font-size:14px"> if some of those who we consider exp=
erts in this area only tentatively participate. The personal attacks and ig=
noring of views counter &gt;to those who were pushing an activation attempt=
 really should not be repeated. (Especially if this process is seeking to i=
nclude those who we consider experts in this area &gt; and don&#39;t want t=
heir participation to be perceived as tacit approval of whatever is attempt=
ed next.)</span></div><div><br></div><div>I&#39;m thinking such a covenant =
effort would be more a technical process aiming to advance the=C2=A0state o=
f covenant &amp; contracting knowledge, collect and document the use-cases,=
 exchange engineering learnings from the prototype, share the problem space=
, etc. In the same fashion we have the BOLT one or even more remote the IET=
F working groups about a bunch of Internet technology [0]. I think that Tap=
root/Schnorr has set a high standard in terms of safety-first and careful B=
itcoin engineering effort, aggregating 8 years of thinking around MAST and =
friends but also exploring other signature schemes like BLS. And I hope wit=
h covenants we aim for higher standards, as if there is one learning from T=
aproot we could have spent more time working out use-cases prototypes (e.g =
joinpools) and standard libraries to mature, it could have save actual head=
ache around x-pubkeys [1]=C2=A0</div><div><br></div><div>In my perspective,=
 activation is more a matter of release engineering and community communica=
tions, and failing to a game-theory situation where miners incentives are c=
omputed is more a hint of a social layer failure. When we start to consider=
 the moves and incentives of categories of Bitcoin players (miners, users, =
exchanges, ...), I would say we failed to keep the community as one and inc=
rease the safety risks for everyone&#39;s coins.</div><div><br></div><div>M=
inding that, and to maximize the participation in such a covenant specifica=
tion process, similar to the usual Chatham House rules in engineering meeti=
ngs, I believe it could be good to have a &quot;No Activation - No Timefram=
e&quot; rule in such a covenant process, and defer any activation discussio=
n to a future process of its own. =C2=A0</div><div><br></div><div>&gt;=C2=
=A0<span style=3D"font-family:Arial;font-size:14px">As long as this is unde=
rstood and agreed by participants I can only see positives coming out of th=
is. But please let&#39;s not repeat the activation drama from earlier in th=
e year &gt; because a process with a subset of those who we would consider =
experts in this area come to a view and then try to ram that view down ever=
yone&#39;s throats by attempting &gt; activation at the end of it. Maybe th=
is will result in community consensus on covenant proposal(s) going forward=
 but also maybe it won&#39;t. Either outcome is fine. At the very &gt; leas=
t research will progress and work will be carried out that moves us in a po=
sitive direction</span><br></div><div><span style=3D"font-family:Arial;font=
-size:14px"><br></span></div><div><span style=3D"font-family:Arial;font-siz=
e:14px">During the last LN Summit in Oakland, there was chit-chat on how lo=
ng it would take to get a mature version of Lightning, and the answer from =
a seasoned FOSS developer was 25 years. Considering the heavy LN problem-sp=
ace, I think this was a wise take and I believe with covenants we would hav=
e to think in that 10/20 years perspective if we aim for a satisfying and c=
omplete covenant toolchain. It doesn&#39;t mean we are not going to be able=
 to deploy piece by piece, however there is a strong emphasis to be done on=
 the archiving part itself. Some of the process stakeholders might still no=
t be active in their engineering careers when the issues should be weighted=
 for consensus activation and transmission of knowledge across generations =
of stakeholders is going to be an issue (as we already see it in Bitcoin Co=
re with some critical subsystems). And if there is never community consensu=
s on covenant proposals, that&#39;s fine. To me the research would have bee=
n interesting in itself and I hope it will be the same for other participan=
ts.=C2=A0</span></div><div><span style=3D"font-family:Arial;font-size:14px"=
><br></span></div><div><span style=3D"font-family:Arial;font-size:14px">[0]=
=C2=A0</span><a href=3D"https://datatracker.ietf.org/wg/">https://datatrack=
er.ietf.org/wg/</a></div>[1] =C2=A0<a href=3D"https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-July/020663.html">https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2022-July/020663.html</a></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0sam. 23 jui=
l. 2022 =C3=A0=C2=A015:25, Michael Folkson &lt;<a href=3D"mailto:michaelfol=
kson@protonmail.com">michaelfolkson@protonmail.com</a>&gt; a =C3=A9crit=C2=
=A0:<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 style=3D"font-family:Arial;font-size:14=
px">Hi Antoine</div><div style=3D"font-family:Arial;font-size:14px"><br></d=
iv><div style=3D"font-family:Arial;font-size:14px">This looks great and I c=
an certainly see progress being made in a number of directions on this. I t=
hought you did a great job with the L2 onchain support workshops and I&#39;=
m sure you&#39;ll do a great job moving this forward.</div><div style=3D"fo=
nt-family:Arial;font-size:14px"><br></div><div style=3D"font-family:Arial;f=
ont-size:14px">One cautionary word from someone who is probably still feeli=
ng the effects of burn out from the activation drama earlier in the year. N=
o process can guarantee community consensus at the end of it especially if =
some of those who we consider experts in this area only tentatively partici=
pate. The personal attacks and ignoring of views counter to those who were =
pushing an activation attempt really should not be repeated. (Especially if=
 this process is seeking to include those who we consider experts in this a=
rea and don&#39;t want their participation to be perceived as tacit approva=
l of whatever is attempted next.)</div><div style=3D"font-family:Arial;font=
-size:14px"><br></div><div style=3D"font-family:Arial;font-size:14px">As lo=
ng as this is understood and agreed by participants I can only see positive=
s coming out of this. But please let&#39;s not repeat the activation drama =
from earlier in the year because a process with a subset of those who we wo=
uld consider experts in this area come to a view and then try to ram that v=
iew down everyone&#39;s throats by attempting activation at the end of it. =
Maybe this will result in community consensus on covenant proposal(s) going=
 forward but also maybe it won&#39;t. Either outcome is fine. At the very l=
east research will progress and work will be carried out that moves us in a=
 positive direction.</div><div style=3D"font-family:Arial;font-size:14px"><=
br></div><div style=3D"font-family:Arial;font-size:14px">Thanks</div><div s=
tyle=3D"font-family:Arial;font-size:14px">Michael</div><div style=3D"font-f=
amily:Arial;font-size:14px"><br></div>
<div style=3D"font-family:Arial;font-size:14px">
    <div>
        <div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospac=
e,monospace"><span style=3D"font-size:14px">--<br>Michael Folkson<br>Email:=
 michaelfolkson at </span></span></span><a rel=3D"noreferrer nofollow noope=
ner" style=3D"line-height:normal;text-decoration:underline;font-family:SFMo=
no-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospace,monospace;f=
ont-size:14px;font-style:normal;font-weight:400;letter-spacing:normal;text-=
indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px" href=
=3D"http://protonmail.com/" target=3D"_blank">protonmail.com</a><span style=
=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:no=
rmal;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:=
0px;background-color:rgb(255,255,255);float:none;display:inline"><span styl=
e=3D"font-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,=
monospace,monospace"><span style=3D"font-size:14px"> </span></span></span><=
br></div><div style=3D"font-family:arial;font-size:14px"><span style=3D"col=
or:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;te=
xt-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;bac=
kground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fo=
nt-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospa=
ce,monospace"><span style=3D"font-size:14px">Keybase: michaelfolkson<br>PGP=
: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</span></span></span><br=
></div>
    </div>

            <div>

            </div>
</div>
<div style=3D"font-family:Arial;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Wednesday, July 20th, 2022 at 21:42, Antoine Riard via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr">Hi,<br><br>Discussions on covenants have been =
prolific and intense on this mailing list and within the wider Bitcoin tech=
nical circles, I believe however without succeeding to reach consensus on a=
ny new set of contracting primitives satisfying the requirements of known c=
ovenant-enabled use-cases. I think that&#39;s a fact to deplore as covenant=
s would not only offer vast extensions of the capabilities of Bitcoin as a =
system, i.e enabling new types of multi-party contract protocols. But also =
empowering Bitcoin on its fundamental value propositions of store of value =
(e.g by making vaults more flexible) and payment system (e.g by making real=
istic channel factories/payment pools).<br><br>If we retain as a covenant d=
efinition, a spending constraint restricting the transaction to which the s=
pent UTXO can be spent, and enabling to program contracts/protocols at the =
transaction-level instead of the script-level, the list of Script primitive=
s proposed during the last years has grown large : ANYPREVOUT [0], CHECKSIG=
FROMSTACK [1], CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], T=
XHASH [4], PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIG=
HASH_GROUP [9], MERKLEBRANCHVERIFY [10] and more than I can&#39;t remember.=
 Of course, all the listed primitives are at different states of formalizat=
ion, some already fully fleshed-out in BIPs, other still ideas on whiteboar=
d, yet they all extend the range of workable multi-party contract protocols=
.<br><br>Indeed this range has grown wild. Without aiming to be exhaustive =
(I&#39;m certainly missing some interesting proposals lost in the abyss of =
<a rel=3D"noreferrer nofollow noopener" href=3D"http://bitcointalk.org" tar=
get=3D"_blank">bitcointalk.org</a>), we can mention the following use-cases=
: multi-party stateful contracts [11], congestion trees [12], payment pools=
 [13], &quot;eltoo&quot; layered commitments [14], programmable vaults [15]=
, multi-events contracts [16], blockchain-as-oracle bets [17], spacechains =
[18], trustless collateral lending [19], ...<br><br>Minding all those facts=
, I would say the task of technical evaluation of any covenant proposal sou=
nds at least two fold. There is first reasoning about the enabled protocols=
 on a range of criterias such as scalability, efficiency, simplicity, exten=
sibility, robustness, data confidentiality, etc. Asking questions like what=
 are the interactions between layers, if any ? Or how robust is the protoco=
l, not just interactivity failure between  participant nodes but in the fac=
e of mempools spikes or internet disruption ? Or if the performance is stil=
l acceptable on shared resources like blockspace or routing tables if every=
one is using this protocol ? Or if the protocol minimizes regulatory attack=
 surface or centralization vectors ?<br><br>Though once this step is achiev=
ed, there is still more reasoning work to evaluate how good a fit is a prop=
osed Script primitive, the efficiency/simplicity/ease to use trade-offs, bu=
t also if there are no functionality overlap or hard constraints on the use=
-cases design themselves or evolvability w.rt future Script extensions or g=
eneralization of the opcode operations.<br><br>Moreover, if you would like =
your evaluation of a covenant proposal to be complete, I don&#39;t believe =
you can squeeze the implications with the mempool rules and combination wit=
h any consistent fee-bumping strategy. To say things politely, those areas =
have been a quagmire of vulnerabilities, attacks and defects for second-lay=
ers Bitcoin protocols during the last years [20].<br><br>Considering the ab=
undant problem-space offered by covenants, I believe there is a reasonable =
groundwork to pursue in building the use-cases understanding (e.g prototype=
, pseudo-specification, documentation, ...) and building consensus on the f=
ramework of criterias on which to evaluate them [21]. It might raise a real=
ly high bar for any covenant proposal compared to previous softforks, howev=
er I think it would adequately reflect the growth in Bitcoin complexity and=
 funds at stakes during the last years.<br><br>Moving towards this outcome,=
 I would like to propose a new covenant open specification process, in the =
same spirit as we have with the BOLTs or dlcspecs. We would have regular me=
etings (biweekly/monthly ?), an open agenda where topics of discussion can =
be pinned in advance and documentation artifacts would be built with time d=
riven by consensus (e.g 1st phase could be to collect, pseudo-specify and f=
ind champion(s) for known use-cases ?) and no timeframe. Starting date coul=
d be September / October / November (later, 2023 ?), giving time for anyone=
 interested in such a covenant process to allocate development and contribu=
tion bandwidth in function of their involvement interest. <br><br>Learning =
from the good but specially from the bad with setting up the L2 onchain sup=
port meetings last year, I think it would be better to keep the agenda open=
, loose and free as much we can in a &quot;burn-the-roadmap&quot; spirit, a=
voiding to create a sense of commitment or perceived signaling in the proce=
ss participants towards any covenant solution. I would guess things to be e=
xperimental and evolutionary and folks to spend the first meetings actually=
 to express what they would like the covenant process to be about (and yes =
that means if you&#39;re a domain expert and you find the pace of things to=
o slow sometimes, you have to learn to handle your own frustration...).<br>=
<br>In a &quot;decentralize-everything&quot; fashion, I believe it would be=
 good to have rotating meeting chairs and multiple covenant documentation a=
rchivists. I&#39;m super happy to spend the time and energy bootstrapping w=
ell such covenant process effort, though as it&#39;s Bitcoin learn to decen=
tralize yourself.<br><br>I&#39;m really curious what the outcome of such a =
covenant process would look like. We might end up concluding that complex c=
ovenants are too unsafe by enabling sophisticated MEV-attacks against LN [2=
2]. Or even if there is an emergent technical consensus, it doesn&#39;t mea=
n there is a real market interest for such covenant solutions. That said, I=
&#39;m not sure if it&#39;s really a subject of concern when you&#39;re rea=
soning as a scientist/engineer and you value technical statements in terms =
of accuracy, systematic relevance and intrinsic interest.<br><br>Overall, m=
y motivation to kick-start such a process stays in the fact that covenants =
are required building blocks to enable scalable payments pools design like =
CoinPool. I believe payments pools are a) cool and b) a good shot at scalin=
g Bitcoin as a payment system once we have reached scalability limits of Li=
ghtning, still under the same security model for users. However, as a commu=
nity we might sense it&#39;s not the good timing for a covenant process. I&=
#39;m really fine with that outcome as there are still holes to patch in LN=
 to keep me busy enough for the coming years.<br><br>Zooming out, I believe=
 with any discussion about covenants or other soft forks, the hard part isn=
&#39;t about coming up with the best technical solution to a set of problem=
s but in the iterative process where all voices are listened to reach (or n=
ot) consensus on what is actually meant by &quot;best&quot; and if the prob=
lems are accurate. The real physics of Bitcoin is the physics of people. It=
&#39;s a work of patience.<br><br>Anyways, eager to collect feedbacks on wh=
at the ideal covenant specification process looks like. As usual, all opini=
ons and mistakes are my own.<br><br>Cheers,<br>Antoine<br><br>[0] <a rel=3D=
"noreferrer nofollow noopener" href=3D"https://github.com/bitcoin/bips/blob=
/master/bip-0118.mediawiki" target=3D"_blank">https://github.com/bitcoin/bi=
ps/blob/master/bip-0118.mediawiki</a><br>[1] <a rel=3D"noreferrer nofollow =
noopener" href=3D"https://bitcoinops.org/en/topics/op_checksigfromstack/" t=
arget=3D"_blank">https://bitcoinops.org/en/topics/op_checksigfromstack/</a>=
<br>[2] <a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/=
bitcoin/bips/blob/master/bip-0119.mediawiki" target=3D"_blank">https://gith=
ub.com/bitcoin/bips/blob/master/bip-0119.mediawiki</a><br>[3] <a rel=3D"nor=
eferrer nofollow noopener" href=3D"https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2021-September/019419.html" target=3D"_blank">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html</a><b=
r>[4] <a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2022-January/019813.html" target=3D"_bla=
nk">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/01=
9813.html</a><br>[5] <a rel=3D"noreferrer nofollow noopener" href=3D"https:=
//github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki" target=3D"_blank">h=
ttps://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki</a><br>[6] <a r=
el=3D"noreferrer nofollow noopener" href=3D"https://medium.com/blockstream/=
cat-and-schnorr-tricks-i-faf1b59bd298" target=3D"_blank">https://medium.com=
/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298</a><br>[7] <a rel=3D"nor=
eferrer nofollow noopener" href=3D"https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2022-February/019926.html" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html</a><br>=
[8] <a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2018-February/015700.html" target=3D"_blan=
k">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/01=
5700.html</a><br>[9] <a rel=3D"noreferrer nofollow noopener" href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html" ta=
rget=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
1-July/019243.html</a><br>[10] <a rel=3D"noreferrer nofollow noopener" href=
=3D"https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki" target=
=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki<=
/a><br>[11] <a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html" target=
=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Ja=
nuary/019808.html</a><br>[12] <a rel=3D"noreferrer nofollow noopener" href=
=3D"https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congesti=
on_Controlled_Transactions" target=3D"_blank">https://github.com/bitcoin/bi=
ps/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions</a><br=
>[13] <a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2020-June/017964.html" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.h=
tml</a><br>[14] <a rel=3D"noreferrer nofollow noopener" href=3D"https://lis=
ts.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html" ta=
rget=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightning-dev/2=
020-January/002448.html</a><br>[15] <a rel=3D"noreferrer nofollow noopener"=
 href=3D"http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf" target=
=3D"_blank">http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf</a><br=
>[16] <a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/ar=
iard/talk-slides/blob/master/advanced-contracts.pdf" target=3D"_blank">http=
s://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf</a><br=
>[17] <a rel=3D"noreferrer nofollow noopener" href=3D"https://blog.bitmex.c=
om/taproot-you-betcha/" target=3D"_blank">https://blog.bitmex.com/taproot-y=
ou-betcha/</a><br>[18] <a rel=3D"noreferrer nofollow noopener" href=3D"http=
s://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechain=
s" target=3D"_blank">https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29=
acced61ca9f49a#spacechains</a> <br>[19] <a rel=3D"noreferrer nofollow noope=
ner" href=3D"https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb8=
35fcef" target=3D"_blank">https://gist.github.com/RubenSomsen/bf08664b3d174=
551ab7361ffb835fcef</a><br>[20] <a rel=3D"noreferrer nofollow noopener" hre=
f=3D"https://github.com/jamesob/mempool.work" target=3D"_blank">https://git=
hub.com/jamesob/mempool.work</a><br>[21] <a rel=3D"noreferrer nofollow noop=
ener" href=3D"https://github.com/bitcoinops/bitcoinops.github.io/pull/806" =
target=3D"_blank">https://github.com/bitcoinops/bitcoinops.github.io/pull/8=
06</a><br>[22] <a rel=3D"noreferrer nofollow noopener" href=3D"https://blog=
.bitmex.com/txwithhold-smart-contracts/" target=3D"_blank">https://blog.bit=
mex.com/txwithhold-smart-contracts/</a><br></div>

        </blockquote><br>
    </div></blockquote></div>

--00000000000093d3b305e47ba124--