MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 20 Jul 2022 16:42:42 -0400
Message-ID: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000278ffa05e442a563"
Subject: [bitcoin-dev] On a new community process to specify covenants
Precedence: list

--000000000000278ffa05e442a563
Content-Type: text/plain; charset="UTF-8"

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-cases.
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 its
fundamental value propositions of store of value (e.g by making vaults more
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 years
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_GROUP
[9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all
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], "eltoo"
layered commitments [14], programmable vaults [15], multi-events contracts
[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 any
? Or how robust is the protocol, not just interactivity failure between
 participant nodes but in the face of mempools spikes or internet
disruption ? Or if the performance is still acceptable on shared resources
like blockspace or routing tables if everyone is using this protocol ? Or
if the 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 generalization
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 mempool
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, ...) and
building consensus on the framework of criterias on which to evaluate them
[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 bandwidth
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 the
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 have
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 an
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 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 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 for
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 solution
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/019419.html
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.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/019926.html
[8]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.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/019808.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/002448.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#spacechains
[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/

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

<div dir=3D"ltr">Hi,<br><br>Discussions on covenants have been prolific and=
 intense on this mailing list and within the wider Bitcoin technical circle=
s, I believe however without succeeding to reach consensus on any new set o=
f contracting primitives satisfying the requirements of known covenant-enab=
led use-cases. I think that&#39;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 B=
itcoin on its fundamental value propositions of store of value (e.g by maki=
ng vaults more flexible) and payment system (e.g by making realistic channe=
l factories/payment pools).<br><br>If we retain as a covenant definition, a=
 spending constraint restricting the transaction to which the spent UTXO ca=
n be spent, and enabling to program contracts/protocols at the transaction-=
level instead of the script-level, the list of Script primitives proposed d=
uring the last years has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1=
], CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], P=
USHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP [=
9], MERKLEBRANCHVERIFY [10] and more than I can&#39;t remember. Of course, =
all the listed primitives are at different states of formalization, some al=
ready fully fleshed-out in BIPs, other still ideas on whiteboard, yet they =
all extend the range of workable multi-party contract protocols.<br><br>Ind=
eed this range has grown wild. Without aiming to be exhaustive (I&#39;m cer=
tainly missing some interesting proposals lost in the abyss of <a href=3D"h=
ttp://bitcointalk.org">bitcointalk.org</a>), we can mention the following u=
se-cases: multi-party stateful contracts [11], congestion trees [12], payme=
nt pools [13], &quot;eltoo&quot; layered commitments [14], programmable vau=
lts [15], multi-events contracts [16], blockchain-as-oracle bets [17], spac=
echains [18], trustless collateral lending [19], ...<br><br>Minding all tho=
se facts, I would say the task of technical evaluation of any covenant prop=
osal sounds at least two fold. There is first reasoning about the enabled p=
rotocols on a range of criterias such as scalability, efficiency, simplicit=
y, extensibility, robustness, data confidentiality, etc. Asking questions l=
ike what are the interactions between layers, if any ? Or how robust is the=
 protocol, not just interactivity failure between =C2=A0participant nodes b=
ut in the face of mempools spikes or internet disruption ? Or if the perfor=
mance is still acceptable on shared resources like blockspace or routing ta=
bles if everyone is using this protocol ? Or if the protocol minimizes regu=
latory attack surface or centralization vectors ?<br><br>Though once this s=
tep 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 t=
rade-offs, but also if there are no functionality overlap or hard constrain=
ts on the use-cases design themselves or evolvability w.rt future Script ex=
tensions or generalization of the opcode operations.<br><br>Moreover, if yo=
u 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 co=
mbination with any consistent fee-bumping strategy. To say things politely,=
 those areas have been a quagmire of vulnerabilities, attacks and defects f=
or second-layers Bitcoin protocols during the last years [20].<br><br>Consi=
dering 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, ...) and building conse=
nsus on the framework of criterias on which to evaluate them [21]. It might=
 raise a really high bar for any covenant proposal compared to previous sof=
tforks, however I think it would adequately reflect the growth in Bitcoin c=
omplexity and funds at stakes during the last years.<br><br>Moving towards =
this outcome, I would like to propose a new covenant open specification pro=
cess, in the same spirit as we have with the BOLTs or dlcspecs. We would ha=
ve regular meetings (biweekly/monthly ?), an open agenda where topics of di=
scussion can be pinned in advance and documentation artifacts would be buil=
t 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. Start=
ing date could be September / October / November (later, 2023 ?), giving ti=
me for anyone interested in such a covenant process to allocate development=
 and contribution bandwidth in function of their involvement interest. <br>=
<br>Learning from the good but specially from the bad with setting up the L=
2 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 &quot;burn-the-roadmap&qu=
ot; spirit, avoiding to create a sense of commitment or perceived signaling=
 in the process participants towards any covenant solution. I would guess t=
hings to be experimental and evolutionary and folks to spend the first meet=
ings actually to express what they would like the covenant process to be ab=
out (and yes that means if you&#39;re a domain expert and you find the pace=
 of things too slow sometimes, you have to learn to handle your own frustra=
tion...).<br><br>In a &quot;decentralize-everything&quot; fashion, I believ=
e it would be good to have rotating meeting chairs and multiple covenant do=
cumentation archivists. I&#39;m super happy to spend the time and energy bo=
otstrapping well such covenant process effort, though as it&#39;s Bitcoin l=
earn to decentralize yourself.<br><br>I&#39;m really curious what the outco=
me of such a covenant process would look like. We might end up concluding t=
hat complex covenants are too unsafe by enabling sophisticated MEV-attacks =
against LN [22]. Or even if there is an emergent technical consensus, it do=
esn&#39;t mean 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 y=
ou&#39;re reasoning as a scientist/engineer and you value technical stateme=
nts in terms of accuracy, systematic relevance and intrinsic interest.<br><=
br>Overall, my motivation to kick-start such a process stays in the fact th=
at covenants are required building blocks to enable scalable payments pools=
 design like CoinPool. I believe payments pools are a) cool and b) a good s=
hot at scaling Bitcoin as a payment system once we have reached scalability=
 limits of Lightning, still under the same security model for users. Howeve=
r, as a community we might sense it&#39;s not the good timing for a covenan=
t process. I&#39;m really fine with that outcome as there are still holes t=
o patch in LN to keep me busy enough for the coming years.<br><br>Zooming o=
ut, 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 s=
et of problems but in the iterative process where all voices are listened t=
o reach (or not) consensus on what is actually meant by &quot;best&quot; an=
d if the problems 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 fe=
edbacks on what the ideal covenant specification process looks like. As usu=
al, all opinions and mistakes are my own.<br><br>Cheers,<br>Antoine<br><br>=
[0] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0118.mediawi=
ki">https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki</a><br>[=
1] <a href=3D"https://bitcoinops.org/en/topics/op_checksigfromstack/">https=
://bitcoinops.org/en/topics/op_checksigfromstack/</a><br>[2] <a href=3D"htt=
ps://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki">https://github=
.com/bitcoin/bips/blob/master/bip-0119.mediawiki</a><br>[3] <a href=3D"http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.h=
tml">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September=
/019419.html</a><br>[4] <a href=3D"https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2022-January/019813.html">https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2022-January/019813.html</a><br>[5] <a href=3D"https=
://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki">https://github.com=
/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki</a><br>[6] <a href=3D"https://me=
dium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298">https://medium.=
com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298</a><br>[7] <a href=3D=
"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/0199=
26.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Febru=
ary/019926.html</a><br>[8] <a href=3D"https://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2018-February/015700.html">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2018-February/015700.html</a><br>[9] <a href=3D"=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.ht=
ml">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/01924=
3.html</a><br>[10] <a href=3D"https://github.com/bitcoin/bips/blob/master/b=
ip-0116.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0116.med=
iawiki</a><br>[11] <a href=3D"https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2022-January/019808.html">https://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2022-January/019808.html</a><br>[12] <a href=3D"https://g=
ithub.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled=
_Transactions">https://github.com/bitcoin/bips/blob/master/bip-0119.mediawi=
ki#Congestion_Controlled_Transactions</a><br>[13] <a href=3D"https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html</a><br>=
[14] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2=
020-January/002448.html">https://lists.linuxfoundation.org/pipermail/lightn=
ing-dev/2020-January/002448.html</a><br>[15] <a href=3D"http://fc17.ifca.ai=
/bitcoin/papers/bitcoin17-final28.pdf">http://fc17.ifca.ai/bitcoin/papers/b=
itcoin17-final28.pdf</a><br>[16] <a href=3D"https://github.com/ariard/talk-=
slides/blob/master/advanced-contracts.pdf">https://github.com/ariard/talk-s=
lides/blob/master/advanced-contracts.pdf</a><br>[17] <a href=3D"https://blo=
g.bitmex.com/taproot-you-betcha/">https://blog.bitmex.com/taproot-you-betch=
a/</a><br>[18] <a href=3D"https://gist.github.com/RubenSomsen/c9f0a92493e06=
b0e29acced61ca9f49a#spacechains">https://gist.github.com/RubenSomsen/c9f0a9=
2493e06b0e29acced61ca9f49a#spacechains</a> <br>[19] <a href=3D"https://gist=
.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef">https://gist.gith=
ub.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef</a><br>[20] <a href=3D"=
https://github.com/jamesob/mempool.work">https://github.com/jamesob/mempool=
.work</a><br>[21] <a href=3D"https://github.com/bitcoinops/bitcoinops.githu=
b.io/pull/806">https://github.com/bitcoinops/bitcoinops.github.io/pull/806<=
/a><br>[22] <a href=3D"https://blog.bitmex.com/txwithhold-smart-contracts/"=
>https://blog.bitmex.com/txwithhold-smart-contracts/</a><br></div>

--000000000000278ffa05e442a563--