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 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.)
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.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://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-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/
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
