Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 13184 bytes --]

Hi all,

Following up my September's mail on the setting of a new decentralized,
open and neutral community process dedicated to covenants R&D, a.k.a
"Bitcoin Contracting Primitives WG", few updates.

After collecting feedback on the adequate communication channel, a low
access bar and pseudonymous participation sounds to be recurring criterias.
As such, I would like to propose using IRC on Libera Chat.

Opened the following chan:

#bitcoin-contracting-primitives-wg

If there are still strong likes for another communication channel, we can
still consider it.

For the 1st meeting date, I was thinking about the second week of November
starting the 7th. About the day and time, we have the following list of
Bitcoin open-source meetings happening across the ecosystem:
- Bitcoin Core general developer meeting Thursday 19:00 UTC
- Bitcoin Core wallet developer meeting Friday 19:00 UTC (every second week)
- Bitcoin Core PR review club Wednesday 17:00 UTC
- Lightning developer meeting Monday 20:00 UTC (bi-weekly, modulo weird
Australian timezones details that I don't understand)
- Core Lightning developer meeting Monday 20:00 UTC (every second week)
- LDK developer meeting Monday 17:00 UTC (every second week)
- LND PR review club Thursday 17:00 UTC (every second week)
- LDK PR review club Tuesday 18:00 UTC (every second week)
- DLC specs meeting Tuesday 19:00 CST (monthly)
- LSP specs meeting Wednesday 10:00 UTC (every second week)

This is a best effort to collect all the open-source engineering meetings
across the ecosystem, though we might have more, feel free to point out the
ones I'm forgetting.

Minding all those meetings happenings and all the time zones, the usual
times slots fitting most of the people are probably the ones between 16:00
UTC and 21:00 UTC.

Looking forward to collecting what would be a good time slot for the
happening of Bitcoin Contracting primitives WG.

For the meeting frequency, I think we can start with a monthly frequency,
then in function of the pace and sustained interest move to bi-weekly. No
agenda, we'll see how things are evolving unconf style.

In the process to collect and document all the known contracting protocol
use-cases at:
https://github.com/ariard/bitcoin-contracting-primitives-wg

So far I've bookmarked the following list:
- vaults
- payment pools
- channel factories
- drivechains
- eltoo channels
- decentralized mining pools
- scalable stateful contracts (e.g DLCs)
- congestion control redux
- non-interactive channels setups
- state channels

Though we're likely to see more emerge with time, feel free to point to the
ones I'm forgetting.

Recently, during a panel at a Bitcoin conference, I've been asked why such
a primitives working group rather than a specialized WG on the use-case I'm
mostly interested in (i.e payment pools). From my experience, the
contracting primitives or covenant you're designing is more likely to be a
function of the use-case properties you've in mind (e.g economic efficiency
or flexibility), however it might not generalize well to the other
contracting use-cases envisioned by a lot of other folks. One wishful
thinking of setting up this R&D effort could yield one common contracting
primitives toolchain servicing all the known use-cases. Though this is only
wishful thinking and we'll see what happens, in fine Bitcoin development is
kinda like jazz music, loosely structured, you launch the first few notes
and then you listen to what the other musicians keep going on.

Still open to more feedback on what the ideal Bitcoin contracting
primitives WG would look like.

Cheers,
Antoine

Le mer. 20 juil. 2022 à 16:42, Antoine Riard <antoine.riard@gmail.com> a
écrit :

> 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/
>

[-- Attachment #2: Type: text/html, Size: 15858 bytes --]