On a new community process to specify covenants

>  Certain human/organizational limitations prevent things being said in
> logged channels that sometimes can be shared in person.  Sometimes
> people break through misunderstandings in person, through either
> informal mingling or the use of Chatham House rules.  So I would also
> advocate restarting the Scaling Bitcoin conferences, twice a year.

> I perceived a lot of "Oh, well it's also fine to just wait and see
> what comes" in the prior discussions.  The idea that we should reopen
> this discussion presumes that it is better to not wait, because having
> even imperfect covenant designs will cause the ecosystem to explore
> what use cases to allocate developer interest in (as long as the fees
> are not too far off - yeah I'm looking at you, CSFS).  Because of
> this, I also propose asking some of the more advanced scripting
> technologists to reveal what of their work is currently science, what
> is engineering, and what is product-oriented with understandable
> delivery dates.  I think that if more people understood the answers to
> these questions then there would be more room for incremental
> exploration of the space.

> +1  I'd participate.
>
> Certain human/organizational limitations prevent things being said in
> logged channels that sometimes can be shared in person.  Sometimes
> people break through misunderstandings in person, through either
> informal mingling or the use of Chatham House rules.  So I would also
> advocate restarting the Scaling Bitcoin conferences, twice a year.
>
> One request for the agenda:
> I perceived a lot of "Oh, well it's also fine to just wait and see
> what comes" in the prior discussions.  The idea that we should reopen
> this discussion presumes that it is better to not wait, because having
> even imperfect covenant designs will cause the ecosystem to explore
> what use cases to allocate developer interest in (as long as the fees
> are not too far off - yeah I'm looking at you, CSFS).  Because of
> this, I also propose asking some of the more advanced scripting
> technologists to reveal what of their work is currently science, what
> is engineering, and what is product-oriented with understandable
> delivery dates.  I think that if more people understood the answers to
> these questions then there would be more room for incremental
> exploration of the space.
>

> One cautionary word from someone who is probably still feeling the

> As long as this is understood and agreed by participants I can only see

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

> Hi Michael,
>
> 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]

> 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], ...
>

> On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> 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], ...
>
> The big question you missed is whether capabilities are in scope for a covenants proposal. In particular, vaults work a lot better when payments to them are immediately locked up in the vault rather than it having to do a step to accept them first.

> Hi Antoine,
> Claiming Taproot history, as best practice or a standard methodology in bitcoin development, is just too much. Bitcoin development methodology is an open problem, given the contemporary escalation/emergence of challenges, history is not  entitled to be hard coded as standard.
>
> Schnorr/MAST development history, is a good subject for case study, but it is not guaranteed that the outcome to be always the same as your take.
>
> I'd suggest instead of inventing a multi-decades-lifecycle based methodology (which is weird by itself, let alone installing it as a standard for bitcoin projects), being open-mind  enough for examining more agile approaches and their inevitable effect on the course of discussions,

> ------- Original Message -------
> On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Hi Michael,
>
>
> 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]
>
> Hi Antoine,
> Claiming Taproot history, as best practice or a standard methodology in
> bitcoin development, is just too much. Bitcoin development methodology is
> an open problem, given the contemporary escalation/emergence of challenges,
> history is not  entitled to be hard coded as standard.
>
> Schnorr/MAST development history, is a good subject for case study, but it
> is not guaranteed that the outcome to be always the same as your take.
>
> I'd suggest instead of inventing a multi-decades-lifecycle based
> methodology (which is weird by itself, let alone installing it as a
> standard for bitcoin projects), being open-mind  enough for examining more
> agile approaches and their inevitable effect on the course of discussions,
>
> Cheers,
>
>
>

> Good morning alia, Antoine, and list,
>
> > Hi Antoine,
> > Claiming Taproot history, as best practice or a standard methodology in
> bitcoin development, is just too much. Bitcoin development methodology is
> an open problem, given the contemporary escalation/emergence of challenges,
> history is not  entitled to be hard coded as standard.
> >
> > Schnorr/MAST development history, is a good subject for case study, but
> it is not guaranteed that the outcome to be always the same as your take.
> >
> > I'd suggest instead of inventing a multi-decades-lifecycle based
> methodology (which is weird by itself, let alone installing it as a
> standard for bitcoin projects), being open-mind  enough for examining more
> agile approaches and their inevitable effect on the course of discussions,
>
> A thing I have been mulling is how to prototype such mechanisms more
> easily.
>
> A "reasonably standard" approach was pioneered in Elements Alpha, where an
> entire federated sidechain is created and then used as a testbed for new
> mechanisms, such as SegWit and `OP_CHECKSIGFROMSTACK`.
> However, obviously the cost is fairly large, as you need an entire
> federated sidechain.
>
> It does have the nice advantage that you can use "real" coins, with real
> value (subject to the federation being trustworthy, admittedly) in order to
> convincingly show a case for real-world use.
>
> As I pointed out in [Smart Contracts Unchained](
> https://zmnscpxj.github.io/bitcoin/unchained.html), an alternative to
> using a blockchain would be to use federated individual coin outpoints.
>
> A thing I have been pondering is to create a generic contracting platform
> with a richer language, which itself is just used to implement a set of
> `OP_` SCRIPT opcodes.
> This is similar to my [Microcode proposal](
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020158.html)
> earlier this year.
> Thus, it would be possible to prototype new `OP_` codes, or change the
> behavior of existing `OP_` codes (e.g. `SIGHASH_NOINPUT` would be a change
> in behavior of existing `OP_CHECKSIG` and `OP_CHECKMULTISIG`), by having a
> translation from `OP_` codes to the richer language.
> Then you could prototype a new SCRIPT `OP_` code by providing your own
> translation of the new `OP_` code and a SCRIPT that uses that `OP_` code,
> and using Smart Contract Unchained to use a real funds outpoint.
>
> Again, we can compare the Bitcoin consensus layer to a form of hardware:
> yes, we *could* patch it and change it, but that requires a ***LOT*** of
> work and the new software has to be redeployed by everyone, so it is,
> practically speaking, hardware.
> Microcode helps this by adding a softer layer without compromising the
> existing hard layer.
>
> So... what I have been thinking of is creating some kind of smart
> contracts unchained platform that allows prototyping new `OP_` codes using
> a microcode mechanism.
>
> Regards,
> ZmnSCPxj
>

> On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> 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], ...
>>
>
> The big question you missed is whether capabilities are in scope for a
> covenants proposal. In particular, vaults work a lot better when payments
> to them are immediately locked up in the vault rather than it having to do
> a step to accept them first.
>

> What would be the canonical definition and examples of capabilities in the
> Bitcoin context ?
>

> On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard <antoine.riard@gmail•com>
> wrote:
>
>> What would be the canonical definition and examples of capabilities in
>> the Bitcoin context ?
>>
>
> Payments into vaults which can only be accepted by that vault and are
> guaranteed to be subject to the vault's restrictions (the vault has a
> capability)
>
> Oracles whose validity can be verified on chain (so transactions can
> depend on what they say. The oracle has a capability)
>
> Colored coins whose validity can be verified on chain (the colored coins
> have a capability)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> place for this kind of thing to happen. I also agree with Ryan Grant's
> comment about in-person cut-through (ie cut through the BS and resolve
> misunderstandings). Perhaps every 3 IRC meetings or so, an in-person

> can be organized in various locations to facilitate that kind of cut
> through.

> I would imagine the phases the group could go through is:
> 1. Define the phases (these phases). This list of 6 phases could be a
> starting point, but its probably best to open the floor to whether this
> feels like a reasonable approach and if more phases are needed or if some
> aren't.
> 2. Define and prioritize the motivations (ie the various features and
> functionality we want out of covenants, like the ones you listed). By
> prioritize, I mostly mean figure out which motivations are most motivating
> to people and rate them by strength of motivation (rather than a ranked
> list).
> 3. Define and prioritize the relevant constraints. These are things to
> avoid in any covenant implementation. Constraints that have been brought

> in the past are things like preventing the possibility of infinite

> recursion, full enumeration, preventing dynamic state, etc. By prioritize
> here, it might be useful to categorize them into categories like "no
> tolerance", "some tolerance", "no reservations". Eg it might turn out most
> people don't have any tolerance for infinite recursion, but don't mind
> non-full enumeration.
> 4. Other criteria? These are other criteria we might want to evaluate
> proposals according to. And some kind of way to prioritize them / evaluate
> them against each other as trade offs.
> 5. Evaluate the proposals based on motivations, constraints, and other
> criteria. This phase shouldn't involve comparing them to each other.
> 6. Produce a set of conclusions/opinions on which proposals are worth
> pursuing further. This would be the phase where proposals are compared.

> Each phase would probably span over more than one meeting. I imagine each
> phase basically consisting of discussing each individual nominated item

> motivations, constraints, other criteria, or proposals) sequentially. The
> consensus reached at the end of each phase would be considered of course a
> group consensus of those who participated, not a global consensus, not a
> "bitcoin community consensus". After each phase, the results of that phase
> would be published more widely to get broader community feedback. These
> results would include what the major opinions are, what level of consensus
> each major opinion has, what the reasons/justifications behind each

> are, and various detailed opinions from individuals. It would be

> great to have detailed evaluations of each proposal published by various
> people so anyone can go back and understand their thought process (as
> opposed to a list of names attached to basically a thumbs up or thumbs
> down). Think like a supreme court decision kind of thing.

> The process doesn't need to be complete after phase 6. Any previous phase
> could be revisited, but after a phase is revisited, the phases after it
> should probably be also revisited in order - or at least until its decided
> a previous phase needs to be revisited again. Each iteration would

> consensus more about each phase. I would imagine the group might loop
> through phases 2, 3, and 4 a couple times (since constraints might

> with motivating features). It might be likely that in phase 5 while
> evaluating proposals, people realize that there are additional criteria
> that should be added and can propose going back to step 4 to do that.
> Hopefully we would get to the point where the motivations and constraints
> and relatively solid consensuses and iterations can loop through phases 5
> and 6 until the set of proposals the group thinks is worth pursuing  is
> narrowed down (ideally to 1 or 2).

> @Antoine
> I very much like your proposal of an open decentralized process for
> investigating the problem and solution spaces. IRC sounds like a reasonable
> place for this kind of thing to happen. I also agree with Ryan Grant's
> comment about in-person cut-through (ie cut through the BS and resolve
> misunderstandings). Perhaps every 3 IRC meetings or so, an in-person meetup
> can be organized in various locations to facilitate that kind of cut
> through.
>
> I would imagine the phases the group could go through is:
> 1. Define the phases (these phases). This list of 6 phases could be a
> starting point, but its probably best to open the floor to whether this
> feels like a reasonable approach and if more phases are needed or if some
> aren't.
> 2. Define and prioritize the motivations (ie the various features and
> functionality we want out of covenants, like the ones you listed). By
> prioritize, I mostly mean figure out which motivations are most motivating
> to people and rate them by strength of motivation (rather than a ranked
> list).
> 3. Define and prioritize the relevant constraints. These are things to
> avoid in any covenant implementation. Constraints that have been brought up
> in the past are things like preventing the possibility of infinite covenant
> recursion, full enumeration, preventing dynamic state, etc. By prioritize
> here, it might be useful to categorize them into categories like "no
> tolerance", "some tolerance", "no reservations". Eg it might turn out most
> people don't have any tolerance for infinite recursion, but don't mind
> non-full enumeration.
> 4. Other criteria? These are other criteria we might want to evaluate
> proposals according to. And some kind of way to prioritize them / evaluate
> them against each other as trade offs.
> 5. Evaluate the proposals based on motivations, constraints, and other
> criteria. This phase shouldn't involve comparing them to each other.
> 6. Produce a set of conclusions/opinions on which proposals are worth
> pursuing further. This would be the phase where proposals are compared.
>
> Each phase would probably span over more than one meeting. I imagine each
> phase basically consisting of discussing each individual nominated item (ie
> motivations, constraints, other criteria, or proposals) sequentially. The
> consensus reached at the end of each phase would be considered of course a
> group consensus of those who participated, not a global consensus, not a
> "bitcoin community consensus". After each phase, the results of that phase
> would be published more widely to get broader community feedback. These
> results would include what the major opinions are, what level of consensus
> each major opinion has, what the reasons/justifications behind each opinion
> are, and various detailed opinions from individuals. It would be especially
> great to have detailed evaluations of each proposal published by various
> people so anyone can go back and understand their thought process (as
> opposed to a list of names attached to basically a thumbs up or thumbs
> down). Think like a supreme court decision kind of thing.
>
> The process doesn't need to be complete after phase 6. Any previous phase
> could be revisited, but after a phase is revisited, the phases after it
> should probably be also revisited in order - or at least until its decided
> a previous phase needs to be revisited again. Each iteration would solidify
> consensus more about each phase. I would imagine the group might loop
> through phases 2, 3, and 4 a couple times (since constraints might conflict
> with motivating features). It might be likely that in phase 5 while
> evaluating proposals, people realize that there are additional criteria
> that should be added and can propose going back to step 4 to do that.
> Hopefully we would get to the point where the motivations and constraints
> and relatively solid consensuses and iterations can loop through phases 5
> and 6 until the set of proposals the group thinks is worth pursuing  is
> narrowed down (ideally to 1 or 2).
>
>
>
>
>
>
> On Tue, Jul 26, 2022 at 11:47 AM Bram Cohen via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard <antoine.riard@gmail•com>
>> wrote:
>>
>>> What would be the canonical definition and examples of capabilities in
>>> the Bitcoin context ?
>>>
>>
>> Payments into vaults which can only be accepted by that vault and are
>> guaranteed to be subject to the vault's restrictions (the vault has a
>> capability)
>>
>> Oracles whose validity can be verified on chain (so transactions can
>> depend on what they say. The oracle has a capability)
>>
>> Colored coins whose validity can be verified on chain (the colored coins
>> have a capability)
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

>  I would like to note it's real work for the organizers in terms of time

>  I would be even cautious about something restrained like "group

>  I believe the covenant problem space might be solved in an evolutionary

> Hi Billy,
>
> Thanks for your interest in a covenant working group.
>
> > place for this kind of thing to happen. I also agree with Ryan Grant's
> > comment about in-person cut-through (ie cut through the BS and resolve
> > misunderstandings). Perhaps every 3 IRC meetings or so, an in-person
> meetup
> > can be organized in various locations to facilitate that kind of cut
> > through.
>
> I really appreciate in-person cut-through to resolve misunderstandings and
> accelerate the information synchronization across the stakeholders of a
> problem space. However, I would like to note it's real work for the
> organizers in terms of time and energy: finding a common date making
> consensus, an acceptable host country (i.e respecting the travel policy of
> the widest, e.g organizing Scaling in Israel in 2019 was an issue for some
> passport holders), a standard meeting location, seeking event sponsors,
> communicating all those infos well ahead to ease everyone travels, ensuring
> coffees & foods suiting many different diets, collecting topics of
> discussions, etc. Further, even assuming travel support, it can still be a
> prohibitive cost for a lot of participants, e.g if you have to request
> months ahead to the host country authorities a dedicated visa for the
> opportunity. I did a bit of in-person meetings organizing in the past, I'm
> clearly not interested in doing it anymore, though it would be cool if
> someone would like to do it for covenants in the future.
>
> > I would imagine the phases the group could go through is:
> > 1. Define the phases (these phases). This list of 6 phases could be a
> > starting point, but its probably best to open the floor to whether this
> > feels like a reasonable approach and if more phases are needed or if some
> > aren't.
> > 2. Define and prioritize the motivations (ie the various features and
> > functionality we want out of covenants, like the ones you listed). By
> > prioritize, I mostly mean figure out which motivations are most
> motivating
> > to people and rate them by strength of motivation (rather than a ranked
> > list).
> > 3. Define and prioritize the relevant constraints. These are things to
> > avoid in any covenant implementation. Constraints that have been brought
> up
> > in the past are things like preventing the possibility of infinite
> covenant
> > recursion, full enumeration, preventing dynamic state, etc. By prioritize
> > here, it might be useful to categorize them into categories like "no
> > tolerance", "some tolerance", "no reservations". Eg it might turn out
> most
> > people don't have any tolerance for infinite recursion, but don't mind
> > non-full enumeration.
> > 4. Other criteria? These are other criteria we might want to evaluate
> > proposals according to. And some kind of way to prioritize them /
> evaluate
> > them against each other as trade offs.
> > 5. Evaluate the proposals based on motivations, constraints, and other
> > criteria. This phase shouldn't involve comparing them to each other.
> > 6. Produce a set of conclusions/opinions on which proposals are worth
> > pursuing further. This would be the phase where proposals are compared.
>
> Yes, I think overall a lot is making sense. Though it's good to keep
> things as loose and see how it evaluates with time and new information
> showing up.
>
> About 2., I think one more thing to define is the list of use-cases, I
> would abstract out features and functionality from use-cases. E.g, I think
> with the TLUV proposal, the taproot output editing feature enables both
> "dynamic-amount" vault and scaling payment pools.
>
> About 3., I think this is going to be the hard part. Collecting all the
> constraints and evaluating the risk tolerance of as-much-as-we-can
> community stakeholders in face of known and plausible risks. E.g, again
> with TLUV, I think it would make from now on the taproot internal pubkey
> and tree of alternative scripts a kind of "dynamic state".
>
> About 4. I've quickly come to mind as additional criterias economic
> simulations of any feature, privacy advantages, toolchain implementations
> complexity, evolvability and composability with future features.
>
> About 6. I agree I think it's good to withhold comparison further down in
> the pipe we can, even if there is I would say some criteria-learning
> heuristics by mirroring features against another.
>
> > Each phase would probably span over more than one meeting. I imagine each
> > phase basically consisting of discussing each individual nominated item
> (ie
> > motivations, constraints, other criteria, or proposals) sequentially. The
> > consensus reached at the end of each phase would be considered of course
> a
> > group consensus of those who participated, not a global consensus, not a
> > "bitcoin community consensus". After each phase, the results of that
> phase
> > would be published more widely to get broader community feedback. These
> > results would include what the major opinions are, what level of
> consensus
> > each major opinion has, what the reasons/justifications behind each
> opinion
> > are, and various detailed opinions from individuals. It would be
> especially
> > great to have detailed evaluations of each proposal published by various
> > people so anyone can go back and understand their thought process (as
> > opposed to a list of names attached to basically a thumbs up or thumbs
> > down). Think like a supreme court decision kind of thing.
>
> Yeah, again I don't see meetings as bounded in time rather happening
> regularly as we have with LN ones. I guess it's going to take at least a
> good year for working group participants to take habits and familiarity
> with the problem space and reach consensus on the process itself. Further,
> I would be even cautious about something restrained like "group consensus"
> in Bitcoin FOSS. At best, it's just a snapshot of people's understanding of
> the technical issues in state X at time T, and that can evaluate quickly in
> function of new findings or issues arising. I think it's more interesting
> to seek a lack of consensus in the sense of opposite opinions or blocking
> arguments. I wouldn't disqualify thumbs up or thumbs down per se, there are
> marks of interest in a specific proposal, though I lean to agree that I
> find more interesting too laid-out evaluations and thought processes.
>
> > The process doesn't need to be complete after phase 6. Any previous phase
> > could be revisited, but after a phase is revisited, the phases after it
> > should probably be also revisited in order - or at least until its
> decided
> > a previous phase needs to be revisited again. Each iteration would
> solidify
> > consensus more about each phase. I would imagine the group might loop
> > through phases 2, 3, and 4 a couple times (since constraints might
> conflict
> > with motivating features). It might be likely that in phase 5 while
> > evaluating proposals, people realize that there are additional criteria
> > that should be added and can propose going back to step 4 to do that.
> > Hopefully we would get to the point where the motivations and constraints
> > and relatively solid consensuses and iterations can loop through phases 5
> > and 6 until the set of proposals the group thinks is worth pursuing  is
> > narrowed down (ideally to 1 or 2).
>
> For sure, in the function of new feedback arising it's good to constantly
> reevaluate proposals. Hopefully, I think any looping should make proposals
> more formalized and accurate. We might also have the "easy" covenants
> moving faster than the "hard" ones across the phases. I believe the
> covenant problem space might be solved in an evolutionary way, layer by
> layer akin to how LN moves forward.
>
> Le mer. 3 août 2022 à 11:37, Billy Tetrud <billy.tetrud@gmail•com> a
> écrit :
>
>> @Antoine
>> I very much like your proposal of an open decentralized process for
>> investigating the problem and solution spaces. IRC sounds like a reasonable
>> place for this kind of thing to happen. I also agree with Ryan Grant's
>> comment about in-person cut-through (ie cut through the BS and resolve
>> misunderstandings). Perhaps every 3 IRC meetings or so, an in-person meetup
>> can be organized in various locations to facilitate that kind of cut
>> through.
>>
>> I would imagine the phases the group could go through is:
>> 1. Define the phases (these phases). This list of 6 phases could be a
>> starting point, but its probably best to open the floor to whether this
>> feels like a reasonable approach and if more phases are needed or if some
>> aren't.
>> 2. Define and prioritize the motivations (ie the various features and
>> functionality we want out of covenants, like the ones you listed). By
>> prioritize, I mostly mean figure out which motivations are most motivating
>> to people and rate them by strength of motivation (rather than a ranked
>> list).
>> 3. Define and prioritize the relevant constraints. These are things to
>> avoid in any covenant implementation. Constraints that have been brought up
>> in the past are things like preventing the possibility of infinite covenant
>> recursion, full enumeration, preventing dynamic state, etc. By prioritize
>> here, it might be useful to categorize them into categories like "no
>> tolerance", "some tolerance", "no reservations". Eg it might turn out most
>> people don't have any tolerance for infinite recursion, but don't mind
>> non-full enumeration.
>> 4. Other criteria? These are other criteria we might want to evaluate
>> proposals according to. And some kind of way to prioritize them / evaluate
>> them against each other as trade offs.
>> 5. Evaluate the proposals based on motivations, constraints, and other
>> criteria. This phase shouldn't involve comparing them to each other.
>> 6. Produce a set of conclusions/opinions on which proposals are worth
>> pursuing further. This would be the phase where proposals are compared.
>>
>> Each phase would probably span over more than one meeting. I imagine each
>> phase basically consisting of discussing each individual nominated item (ie
>> motivations, constraints, other criteria, or proposals) sequentially. The
>> consensus reached at the end of each phase would be considered of course a
>> group consensus of those who participated, not a global consensus, not a
>> "bitcoin community consensus". After each phase, the results of that phase
>> would be published more widely to get broader community feedback. These
>> results would include what the major opinions are, what level of consensus
>> each major opinion has, what the reasons/justifications behind each opinion
>> are, and various detailed opinions from individuals. It would be especially
>> great to have detailed evaluations of each proposal published by various
>> people so anyone can go back and understand their thought process (as
>> opposed to a list of names attached to basically a thumbs up or thumbs
>> down). Think like a supreme court decision kind of thing.
>>
>> The process doesn't need to be complete after phase 6. Any previous phase
>> could be revisited, but after a phase is revisited, the phases after it
>> should probably be also revisited in order - or at least until its decided
>> a previous phase needs to be revisited again. Each iteration would solidify
>> consensus more about each phase. I would imagine the group might loop
>> through phases 2, 3, and 4 a couple times (since constraints might conflict
>> with motivating features). It might be likely that in phase 5 while
>> evaluating proposals, people realize that there are additional criteria
>> that should be added and can propose going back to step 4 to do that.
>> Hopefully we would get to the point where the motivations and constraints
>> and relatively solid consensuses and iterations can loop through phases 5
>> and 6 until the set of proposals the group thinks is worth pursuing  is
>> narrowed down (ideally to 1 or 2).
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 26, 2022 at 11:47 AM Bram Cohen via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>>> On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard <antoine.riard@gmail•com>
>>> wrote:
>>>
>>>> What would be the canonical definition and examples of capabilities in
>>>> the Bitcoin context ?
>>>>
>>>
>>> Payments into vaults which can only be accepted by that vault and are
>>> guaranteed to be subject to the vault's restrictions (the vault has a
>>> capability)
>>>
>>> Oracles whose validity can be verified on chain (so transactions can
>>> depend on what they say. The oracle has a capability)
>>>
>>> Colored coins whose validity can be verified on chain (the colored coins
>>> have a capability)
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation•org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>

> I was actually not thinking one large central in-person meeting, but many

> Fair enough. But I think part of the point here would be to use such a

> >  I would like to note it's real work for the organizers in terms of time
> and energy: finding a common date making consensus, an acceptable host
> country (i.e respecting the travel policy of the widest...
>
> I was actually not thinking one large central in-person meeting, but many
> smaller decentralized in-person meetings where no one has to travel far.
> The meetings can be used to foster communication that can then be
> summarized and/or brought online and discussed with the larger group. Would
> certainly make all those date/visa/etc issues a lot easier.
>
> >  I would be even cautious about something restrained like "group
> consensus" in Bitcoin FOSS. At best, it's just a snapshot of people's
> understanding of the technical issues in state X at time T
>
> Fair enough. But I think part of the point here would be to use such a
> snapshot as an indicator that helps convince others that a particular idea
> has been discussed, thought through, and has actual well-reasoned support.
> Whatever you call it, it would be a useful set of data points.
>
> >  I believe the covenant problem space might be solved in an evolutionary
> way, layer by layer akin to how LN moves forward.
>
> Definitely.
>
>
> On Tue, Aug 9, 2022 at 3:15 PM Antoine Riard <antoine.riard@gmail•com>
> wrote:
>
>> Hi Billy,
>>
>> Thanks for your interest in a covenant working group.
>>
>> > place for this kind of thing to happen. I also agree with Ryan Grant's
>> > comment about in-person cut-through (ie cut through the BS and resolve
>> > misunderstandings). Perhaps every 3 IRC meetings or so, an in-person
>> meetup
>> > can be organized in various locations to facilitate that kind of cut
>> > through.
>>
>> I really appreciate in-person cut-through to resolve misunderstandings
>> and accelerate the information synchronization across the stakeholders of a
>> problem space. However, I would like to note it's real work for the
>> organizers in terms of time and energy: finding a common date making
>> consensus, an acceptable host country (i.e respecting the travel policy of
>> the widest, e.g organizing Scaling in Israel in 2019 was an issue for some
>> passport holders), a standard meeting location, seeking event sponsors,
>> communicating all those infos well ahead to ease everyone travels, ensuring
>> coffees & foods suiting many different diets, collecting topics of
>> discussions, etc. Further, even assuming travel support, it can still be a
>> prohibitive cost for a lot of participants, e.g if you have to request
>> months ahead to the host country authorities a dedicated visa for the
>> opportunity. I did a bit of in-person meetings organizing in the past, I'm
>> clearly not interested in doing it anymore, though it would be cool if
>> someone would like to do it for covenants in the future.
>>
>> > I would imagine the phases the group could go through is:
>> > 1. Define the phases (these phases). This list of 6 phases could be a
>> > starting point, but its probably best to open the floor to whether this
>> > feels like a reasonable approach and if more phases are needed or if
>> some
>> > aren't.
>> > 2. Define and prioritize the motivations (ie the various features and
>> > functionality we want out of covenants, like the ones you listed). By
>> > prioritize, I mostly mean figure out which motivations are most
>> motivating
>> > to people and rate them by strength of motivation (rather than a ranked
>> > list).
>> > 3. Define and prioritize the relevant constraints. These are things to
>> > avoid in any covenant implementation. Constraints that have been
>> brought up
>> > in the past are things like preventing the possibility of infinite
>> covenant
>> > recursion, full enumeration, preventing dynamic state, etc. By
>> prioritize
>> > here, it might be useful to categorize them into categories like "no
>> > tolerance", "some tolerance", "no reservations". Eg it might turn out
>> most
>> > people don't have any tolerance for infinite recursion, but don't mind
>> > non-full enumeration.
>> > 4. Other criteria? These are other criteria we might want to evaluate
>> > proposals according to. And some kind of way to prioritize them /
>> evaluate
>> > them against each other as trade offs.
>> > 5. Evaluate the proposals based on motivations, constraints, and other
>> > criteria. This phase shouldn't involve comparing them to each other.
>> > 6. Produce a set of conclusions/opinions on which proposals are worth
>> > pursuing further. This would be the phase where proposals are compared.
>>
>> Yes, I think overall a lot is making sense. Though it's good to keep
>> things as loose and see how it evaluates with time and new information
>> showing up.
>>
>> About 2., I think one more thing to define is the list of use-cases, I
>> would abstract out features and functionality from use-cases. E.g, I think
>> with the TLUV proposal, the taproot output editing feature enables both
>> "dynamic-amount" vault and scaling payment pools.
>>
>> About 3., I think this is going to be the hard part. Collecting all the
>> constraints and evaluating the risk tolerance of as-much-as-we-can
>> community stakeholders in face of known and plausible risks. E.g, again
>> with TLUV, I think it would make from now on the taproot internal pubkey
>> and tree of alternative scripts a kind of "dynamic state".
>>
>> About 4. I've quickly come to mind as additional criterias economic
>> simulations of any feature, privacy advantages, toolchain implementations
>> complexity, evolvability and composability with future features.
>>
>> About 6. I agree I think it's good to withhold comparison further down in
>> the pipe we can, even if there is I would say some criteria-learning
>> heuristics by mirroring features against another.
>>
>> > Each phase would probably span over more than one meeting. I imagine
>> each
>> > phase basically consisting of discussing each individual nominated item
>> (ie
>> > motivations, constraints, other criteria, or proposals) sequentially.
>> The
>> > consensus reached at the end of each phase would be considered of
>> course a
>> > group consensus of those who participated, not a global consensus, not a
>> > "bitcoin community consensus". After each phase, the results of that
>> phase
>> > would be published more widely to get broader community feedback. These
>> > results would include what the major opinions are, what level of
>> consensus
>> > each major opinion has, what the reasons/justifications behind each
>> opinion
>> > are, and various detailed opinions from individuals. It would be
>> especially
>> > great to have detailed evaluations of each proposal published by various
>> > people so anyone can go back and understand their thought process (as
>> > opposed to a list of names attached to basically a thumbs up or thumbs
>> > down). Think like a supreme court decision kind of thing.
>>
>> Yeah, again I don't see meetings as bounded in time rather happening
>> regularly as we have with LN ones. I guess it's going to take at least a
>> good year for working group participants to take habits and familiarity
>> with the problem space and reach consensus on the process itself. Further,
>> I would be even cautious about something restrained like "group consensus"
>> in Bitcoin FOSS. At best, it's just a snapshot of people's understanding of
>> the technical issues in state X at time T, and that can evaluate quickly in
>> function of new findings or issues arising. I think it's more interesting
>> to seek a lack of consensus in the sense of opposite opinions or blocking
>> arguments. I wouldn't disqualify thumbs up or thumbs down per se, there are
>> marks of interest in a specific proposal, though I lean to agree that I
>> find more interesting too laid-out evaluations and thought processes.
>>
>> > The process doesn't need to be complete after phase 6. Any previous
>> phase
>> > could be revisited, but after a phase is revisited, the phases after it
>> > should probably be also revisited in order - or at least until its
>> decided
>> > a previous phase needs to be revisited again. Each iteration would
>> solidify
>> > consensus more about each phase. I would imagine the group might loop
>> > through phases 2, 3, and 4 a couple times (since constraints might
>> conflict
>> > with motivating features). It might be likely that in phase 5 while
>> > evaluating proposals, people realize that there are additional criteria
>> > that should be added and can propose going back to step 4 to do that.
>> > Hopefully we would get to the point where the motivations and
>> constraints
>> > and relatively solid consensuses and iterations can loop through phases
>> 5
>> > and 6 until the set of proposals the group thinks is worth pursuing  is
>> > narrowed down (ideally to 1 or 2).
>>
>> For sure, in the function of new feedback arising it's good to constantly
>> reevaluate proposals. Hopefully, I think any looping should make proposals
>> more formalized and accurate. We might also have the "easy" covenants
>> moving faster than the "hard" ones across the phases. I believe the
>> covenant problem space might be solved in an evolutionary way, layer by
>> layer akin to how LN moves forward.
>>
>> Le mer. 3 août 2022 à 11:37, Billy Tetrud <billy.tetrud@gmail•com> a
>> écrit :
>>
>>> @Antoine
>>> I very much like your proposal of an open decentralized process for
>>> investigating the problem and solution spaces. IRC sounds like a reasonable
>>> place for this kind of thing to happen. I also agree with Ryan Grant's
>>> comment about in-person cut-through (ie cut through the BS and resolve
>>> misunderstandings). Perhaps every 3 IRC meetings or so, an in-person meetup
>>> can be organized in various locations to facilitate that kind of cut
>>> through.
>>>
>>> I would imagine the phases the group could go through is:
>>> 1. Define the phases (these phases). This list of 6 phases could be a
>>> starting point, but its probably best to open the floor to whether this
>>> feels like a reasonable approach and if more phases are needed or if some
>>> aren't.
>>> 2. Define and prioritize the motivations (ie the various features and
>>> functionality we want out of covenants, like the ones you listed). By
>>> prioritize, I mostly mean figure out which motivations are most motivating
>>> to people and rate them by strength of motivation (rather than a ranked
>>> list).
>>> 3. Define and prioritize the relevant constraints. These are things to
>>> avoid in any covenant implementation. Constraints that have been brought up
>>> in the past are things like preventing the possibility of infinite covenant
>>> recursion, full enumeration, preventing dynamic state, etc. By prioritize
>>> here, it might be useful to categorize them into categories like "no
>>> tolerance", "some tolerance", "no reservations". Eg it might turn out most
>>> people don't have any tolerance for infinite recursion, but don't mind
>>> non-full enumeration.
>>> 4. Other criteria? These are other criteria we might want to evaluate
>>> proposals according to. And some kind of way to prioritize them / evaluate
>>> them against each other as trade offs.
>>> 5. Evaluate the proposals based on motivations, constraints, and other
>>> criteria. This phase shouldn't involve comparing them to each other.
>>> 6. Produce a set of conclusions/opinions on which proposals are worth
>>> pursuing further. This would be the phase where proposals are compared.
>>>
>>> Each phase would probably span over more than one meeting. I imagine
>>> each phase basically consisting of discussing each individual nominated
>>> item (ie motivations, constraints, other criteria, or proposals)
>>> sequentially. The consensus reached at the end of each phase would be
>>> considered of course a group consensus of those who participated, not a
>>> global consensus, not a "bitcoin community consensus". After each phase,
>>> the results of that phase would be published more widely to get broader
>>> community feedback. These results would include what the major opinions
>>> are, what level of consensus each major opinion has, what the
>>> reasons/justifications behind each opinion are, and various detailed
>>> opinions from individuals. It would be especially great to have detailed
>>> evaluations of each proposal published by various people so anyone can go
>>> back and understand their thought process (as opposed to a list of names
>>> attached to basically a thumbs up or thumbs down). Think like a supreme
>>> court decision kind of thing.
>>>
>>> The process doesn't need to be complete after phase 6. Any previous
>>> phase could be revisited, but after a phase is revisited, the phases after
>>> it should probably be also revisited in order - or at least until its
>>> decided a previous phase needs to be revisited again. Each iteration would
>>> solidify consensus more about each phase. I would imagine the group might
>>> loop through phases 2, 3, and 4 a couple times (since constraints might
>>> conflict with motivating features). It might be likely that in phase 5
>>> while evaluating proposals, people realize that there are additional
>>> criteria that should be added and can propose going back to step 4 to do
>>> that. Hopefully we would get to the point where the motivations and
>>> constraints and relatively solid consensuses and iterations can loop
>>> through phases 5 and 6 until the set of proposals the group thinks is worth
>>> pursuing  is narrowed down (ideally to 1 or 2).
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 26, 2022 at 11:47 AM Bram Cohen via bitcoin-dev <
>>> bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>
>>>> On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard <antoine.riard@gmail•com>
>>>> wrote:
>>>>
>>>>> What would be the canonical definition and examples of capabilities in
>>>>> the Bitcoin context ?
>>>>>
>>>>
>>>> Payments into vaults which can only be accepted by that vault and are
>>>> guaranteed to be subject to the vault's restrictions (the vault has a
>>>> capability)
>>>>
>>>> Oracles whose validity can be verified on chain (so transactions can
>>>> depend on what they say. The oracle has a capability)
>>>>
>>>> Colored coins whose validity can be verified on chain (the colored
>>>> coins have a capability)
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation•org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>

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

> Defining a communication channel is still an open question: IRC, Slack,

> About the starting point for regular meetings, I think the good timing is

> softfork activation discussions will be considered as

> put this together. I think that as the community and
> ecosystem continue to grow, it's going to be an important
> part of the process to have groups like this develop. Hopefully
> they allow us to resist the "Tyranny of Structurelessness" without
> resorting to formalized governance processes and systems.

> > Defining a communication channel is still an open question: IRC, Slack,
> Discord, Discourse, ...
>
> I would vote against Slack. IRC is probably the best but maybe too
> high a barrier to entry? Publishing logs at least would counter
> concerns of it being exclusive. Maybe discord as an alternative.

> > About the starting point for regular meetings, I think the good timing is
> somewhere in November, after the upcoming cycle of Bitcoin conferences,

> Maybe as a way to keep these topics separate, it would make sense
> for activation to have its own WG. As norms develop around this one,
> they could inform creating a separate space focused on forwarding
> research and discussion around how to introduce upgrades to bitcoin.

> In general it would be nice to have multiple of these groups
> happening at once, and finding a way that they can operate separate
> from centralized companies. To my mind, there's no good reason why
> a supposedly decentralized protocol should have to be focusing on only
> one set of protocol advancements at a time. The linear way that
> discussions post-Taproot activation took shape ("What do you think the
> next bitcoin softfork should be?") is a sign of weakness in my opinion.
> Definitely a big red flag that we should be concerned with.

> * Any thoughts on starting to commit to an in-person meetup to happen
> ~6 months - 1 year after the start of the regular online meetings?

> On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> First just wanted to thank you
> for taking the initiative to
> > put this together. I think that as the community and
> > ecosystem continue to grow, it's going to be an important
> > part of the process to have groups like this develop. Hopefully
> > they allow us to resist the "Tyranny of Structurelessness" without
> > resorting to formalized governance processes and systems.
>
> Huh, lots of reading material behind that phrase.  I'd heard it
> before, but hadn't looked it up.
>
> > > Defining a communication channel is still an open question: IRC, Slack,
> > Discord, Discourse, ...
> >
> > I would vote against Slack. IRC is probably the best but maybe too
> > high a barrier to entry? Publishing logs at least would counter
> > concerns of it being exclusive. Maybe discord as an alternative.
>
> I found Discord immediately wanted a phone number from me.  I think
> IRC remains the lowest bar for participants to contribute.
>
>

> First just wanted to thank you for taking the initiative to
> put this together. I think that as the community and
> ecosystem continue to grow, it's going to be an important
> part of the process to have groups like this develop. Hopefully
> they allow us to resist the "Tyranny of Structurelessness" without
> resorting to formalized governance processes and systems.

> Defining a communication channel is still an open question: IRC, Slack,

> I understand the reason for this but I do have some concerns that
> it's not as off-topic as most of us would like. It shouldn't
> be a priority but how any of these primitives end up getting activated
> is part of the proposal itself in my opinion.
>
> I think it also became clear in some of the discussions over the past
> ~year that maybe there were more concerns than people realized about
> even the taproot activation process, whether the method used or if it
> was done too quickly. An example of where there might be
> some intersection with the WG as proposed is the question of how much
> research, security audits, etc. are "enough" before it should be
> considered for activation?

> Maybe as a way to keep these topics separate, it would make sense
> for activation to have its own WG. As norms develop around this one,
> they could inform creating a separate space focused on forwarding
> research and discussion around how to introduce upgrades to bitcoin.

> In general it would be nice to have multiple of these groups
> happening at once, and finding a way that they can operate separate
> from centralized companies. To my mind, there's no good reason why
> a supposedly decentralized protocol should have to be focusing on only
> one set of protocol advancements at a time. The linear way that
> discussions post-Taproot activation took shape ("What do you think the
> next bitcoin softfork should be?") is a sign of weakness in my opinion.
> Definitely a big red flag that we should be concerned with.

> * it seems like there might be some opportunities to work with
> bipbounty.org which grew out of the organic bounty donations that
> were made towards finding CTV vulnerabilities. For example,
> if the group develops specific, achievable research goals (building
> out use cases, researching vulnerabilities or limitations, etc.),
> bipbounty.org could help support these efforts in a more decentralized
> way by diversifying funding.

> * Any thoughts on starting to commit to an in-person meetup to happen
> ~6 months - 1 year after the start of the regular online meetings?
> That should be plenty of time for people to plan and formalize
> a location and it seems like other IRL dev meetups have been
> very productive in terms of knowledge sharing and setting priorities.
> An in-person meetup would give a nice goal to work towards and a way
> to measure progress.

> Hi Antoine,
>
> First just wanted to thank you for taking the initiative to
> put this together. I think that as the community and
> ecosystem continue to grow, it's going to be an important
> part of the process to have groups like this develop. Hopefully
> they allow us to resist the "Tyranny of Structurelessness" without
> resorting to formalized governance processes and systems.
>
> > Defining a communication channel is still an open question: IRC, Slack,
> Discord, Discourse, ...
>
> I would vote against Slack. IRC is probably the best but maybe too
> high a barrier to entry? Publishing logs at least would counter
> concerns of it being exclusive. Maybe discord as an alternative.
>
> > About the starting point for regular meetings, I think the good timing is
> somewhere in November, after the upcoming cycle of Bitcoin conferences,
>
> +1
>
> > softfork activation discussions will be considered as
> off-topic and discouraged. This is first and foremost a long-term R&D
> effort.
>
> I understand the reason for this but I do have some concerns that
> it's not as off-topic as most of us would like. It shouldn't
> be a priority but how any of these primitives end up getting activated
> is part of the proposal itself in my opinion.
>
> I think it also became clear in some of the discussions over the past
> ~year that maybe there were more concerns than people realized about
> even the taproot activation process, whether the method used or if it
> was done too quickly. An example of where there might be
> some intersection with the WG as proposed is the question of how much
> research, security audits, etc. are "enough" before it should be
> considered for activation?
>
> Maybe as a way to keep these topics separate, it would make sense
> for activation to have its own WG. As norms develop around this one,
> they could inform creating a separate space focused on forwarding
> research and discussion around how to introduce upgrades to bitcoin.
>
> In general it would be nice to have multiple of these groups
> happening at once, and finding a way that they can operate separate
> from centralized companies. To my mind, there's no good reason why
> a supposedly decentralized protocol should have to be focusing on only
> one set of protocol advancements at a time. The linear way that
> discussions post-Taproot activation took shape ("What do you think the
> next bitcoin softfork should be?") is a sign of weakness in my opinion.
> Definitely a big red flag that we should be concerned with.
>
> Couple other comments from the proposal/repo:
>
> * it seems like there might be some opportunities to work with
> bipbounty.org which grew out of the organic bounty donations that
> were made towards finding CTV vulnerabilities. For example,
> if the group develops specific, achievable research goals (building
> out use cases, researching vulnerabilities or limitations, etc.),
> bipbounty.org could help support these efforts in a more decentralized
> way by diversifying funding.
>
> * Any thoughts on starting to commit to an in-person meetup to happen
> ~6 months - 1 year after the start of the regular online meetings?
> That should be plenty of time for people to plan and formalize
> a location and it seems like other IRL dev meetups have been
> very productive in terms of knowledge sharing and setting priorities.
> An in-person meetup would give a nice goal to work towards and a way
> to measure progress.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> Agreed, anything that requires a phone number makes it difficult to be
> pseudonymous.
>
> I recommend Matrix, since it doesn't require any privacy invasive
> information and has e2ee by default for 1-1 conversations.

> On Tue, Sep 13, 2022 at 6:03 PM Ryan Grant via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org> First just wanted to thank you
>> for taking the initiative to
>> > put this together. I think that as the community and
>> > ecosystem continue to grow, it's going to be an important
>> > part of the process to have groups like this develop. Hopefully
>> > they allow us to resist the "Tyranny of Structurelessness" without
>> > resorting to formalized governance processes and systems.
>>
>> Huh, lots of reading material behind that phrase.  I'd heard it
>> before, but hadn't looked it up.
>>
>> > > Defining a communication channel is still an open question: IRC,
>> Slack,
>> > Discord, Discourse, ...
>> >
>> > I would vote against Slack. IRC is probably the best but maybe too
>> > high a barrier to entry? Publishing logs at least would counter
>> > concerns of it being exclusive. Maybe discord as an alternative.
>>
>> I found Discord immediately wanted a phone number from me.  I think
>> IRC remains the lowest bar for participants to contribute.
>>
>>
> Agreed, anything that requires a phone number makes it difficult to be
> pseudonymous.
>
> I recommend Matrix, since it doesn't require any privacy invasive
> information and has e2ee by default for 1-1 conversations.
>
> The Matrix room could optionally bridge to IRC if there is a significant
> demand for that.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> Hi Buck,
>

>
> I would vote against Slack. IRC is probably the best but maybe too high a
> barrier to entry? Publishing logs at least would counter concerns of it
> being exclusive. Maybe discord as an alternative.
>
> I would say I really like IRC too. The strong text-based format, the lack
> of avatar emoji, the low-bar to participate pseudonymously, the leveling
> field for non-native speakers contrary to audio and the easiness to grab
> the mics, all features valuable for such a process I think.
>
> If IRC is still considered a technical high-bar for a standard
> communication organ by many community stakeholders, discord is an
> alternative.
>

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