Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9FB92C002D for ; Sat, 27 Aug 2022 21:01:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 72B9440935 for ; Sat, 27 Aug 2022 21:01:41 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 72B9440935 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=lvqoDCTo X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lpZn8La0K4s for ; Sat, 27 Aug 2022 21:01:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3DBF64090C Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) by smtp4.osuosl.org (Postfix) with ESMTPS id 3DBF64090C for ; Sat, 27 Aug 2022 21:01:38 +0000 (UTC) Received: by mail-vs1-xe32.google.com with SMTP id m66so4838031vsm.12 for ; Sat, 27 Aug 2022 14:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=JUcwP8ZA+XJ67iOPXN0YV/3x0jbJeoFMLg+RGTl6ZZc=; b=lvqoDCTos3RxrDYrp73dSbccAvYS2uXhtNEWOjsMu/FoaIpZ5u4bIS9NRuIVVtXTlv g4VnY4pu7hEIkMfEv/XMRpJ6Er9swZD2chViMmpPzlGjNU8IqjeztJSiGpNm50bWup0b 9HmHV+fhtBnefGi8wTqZ66LvqCtfY/sU9iH77l6gVnXNpkeigSMGF6ryAO4WPivYkRIF eZNa8MzJwVlEmFGTTTd6L2VfEkmLyUFq2nyHf573PJm4yrAUM+bxf21MEf8UQtnNB8L3 Amppzq6Svra0JKzRUQKMcGlU1HzLGC4LyB6/L/4Vs4f2r1XeOKgoWADrH5iGwD21od5Q mu1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=JUcwP8ZA+XJ67iOPXN0YV/3x0jbJeoFMLg+RGTl6ZZc=; b=KJG1QKF20zu0TgAwSoB53lhffoX8QFCbPQP4j8dsFaJlgVgDRHwH2C0LUaywKdXw+6 TrlzeVpd+G03Tetww5uYqMPdKHz//EDJjo+H3tOTJCzHUqc0xmCFl93aAxLPvSg2JlYe On0gz7mgG3Xf0Kiyu9oo7bGgKqKQggDzMKlseVfK36ovkWFM4geOR3rQi6smpW5m2csO 7jYH1J4L5B64C/B4wGASkiG42KPFsp/66TzcizjT+ln+hhEXypS+0Vg3SACKHfNum6LR VqhiEgPdNzvKsI4AaTWg/FOvD639bUISCG77Hn3MocjoyZebdAZhQaGSsbpVwkogdanF qnuA== X-Gm-Message-State: ACgBeo1EDTyjGREowrGbrMgYonoJiAqVILXPo5MLLb7RdBcENQKUr5Id wGZMT2/p3fJ86BPorfnDiE79BIlrToZkgf9UXzdm3tPywNKcWw== X-Google-Smtp-Source: AA6agR7mUfiemd76a1IFLSXSd2d3qoV7LaM5w05yJb//gseBnWvUnNRQA4unPJODCpZC61OoRRICFhQ8XMJpCh//jEM= X-Received: by 2002:a05:6102:c8a:b0:390:232a:8f29 with SMTP id f10-20020a0561020c8a00b00390232a8f29mr1581955vst.81.1661634096942; Sat, 27 Aug 2022 14:01:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Sat, 27 Aug 2022 16:01:21 -0500 Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="00000000000018557005e73f56b7" X-Mailman-Approved-At: Sat, 27 Aug 2022 21:07:38 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] On a new community process to specify covenants X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2022 21:01:42 -0000 --00000000000018557005e73f56b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 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 an= d > 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 o= f > the widest, e.g organizing Scaling in Israel in 2019 was an issue for som= e > passport holders), a standard meeting location, seeking event sponsors, > communicating all those infos well ahead to ease everyone travels, ensuri= ng > 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 so= me > > 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 brough= t > up > > in the past are things like preventing the possibility of infinite > covenant > > recursion, full enumeration, preventing dynamic state, etc. By prioriti= ze > > 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 thin= k > 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 ea= ch > > phase basically consisting of discussing each individual nominated item > (ie > > motivations, constraints, other criteria, or proposals) sequentially. T= he > > consensus reached at the end of each phase would be considered of cours= e > 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 variou= s > > 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 a= re > 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 pha= se > > 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 constrain= ts > > 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 proposal= s > 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=C3=BBt 2022 =C3=A0 11:37, Billy Tetrud a > =C3=A9crit : > >> @Antoine >> I very much like your proposal of an open decentralized process for >> investigating the problem and solution spaces. IRC sounds like a reasona= ble >> 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 mee= tup >> 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 som= e >> 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 motivati= ng >> 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 coven= ant >> recursion, full enumeration, preventing dynamic state, etc. By prioritiz= e >> here, it might be useful to categorize them into categories like "no >> tolerance", "some tolerance", "no reservations". Eg it might turn out mo= st >> 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 / evalua= te >> 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 eac= h >> phase basically consisting of discussing each individual nominated item = (ie >> motivations, constraints, other criteria, or proposals) sequentially. Th= e >> 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 pha= se >> would be published more widely to get broader community feedback. These >> results would include what the major opinions are, what level of consens= us >> each major opinion has, what the reasons/justifications behind each opin= ion >> are, and various detailed opinions from individuals. It would be especia= lly >> 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 phas= e >> 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 decid= ed >> a previous phase needs to be revisited again. Each iteration would solid= ify >> consensus more about each phase. I would imagine the group might loop >> through phases 2, 3, and 4 a couple times (since constraints might confl= ict >> 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 constraint= s >> 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 >>> 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 coin= s >>> have a capability) >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> --00000000000018557005e73f56b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 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 cou= ntry (i.e respecting the travel policy of the widest...

= I was actually not thinking one large central in-person meeting, but many s= maller decentralized in-person meetings where no one has to travel far. The= meetings can be used to foster communication that can then be summarized a= nd/or brought online and discussed with the larger group. Would certainly= =C2=A0make all those date/visa/etc issues a lot easier.=C2=A0
>=C2=A0 I would be even cautious about something restrained like "group consen= sus" 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 particula= r=C2=A0idea has been discussed, thought through, and has actual well-reason= ed support. Whatever you call it, it would be a useful set of data points.<= br>

>=C2=A0 I believe the covenant problem space migh= t be solved in an evolutionary way, layer by layer akin to how LN moves for= ward.

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&= #39;s
> comment about in-person cut-through (ie cut through the BS an= d resolve
> misunderstandings). Perhaps every 3 IRC meetings or so, a= n in-person meetup
> can be organized in various locations to facilit= ate that kind of cut
> through.

I really appreciate in-person = cut-through to resolve misunderstandings and accelerate the information syn= chronization across the stakeholders of a problem space. However, I would l= ike to note it's real work for the organizers in terms of time and ener= gy: finding a common date making consensus, an acceptable host country (i.e= respecting the travel policy of the widest, e.g organizing Scaling in Isra= el in 2019 was an issue for some passport holders), a standard meeting loca= tion, seeking event sponsors, communicating all those infos well ahead to e= ase everyone travels, ensuring coffees & foods suiting many different d= iets, 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 dedic= ated 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.<= br>
> I would imagine the phases the group could go through is:
&g= t; 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 th= is
> feels like a reasonable approach and if more phases are needed o= r if some
> aren't.
> 2. Define and prioritize the motivati= ons (ie the various features and
> functionality we want out of coven= ants, like the ones you listed). By
> prioritize, I mostly mean figur= e 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 u= p
> in the past are things like preventing the possibility of infinit= e covenant
> recursion, full enumeration, preventing dynamic state, e= tc. 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 do= n't have any tolerance for infinite recursion, but don't mind
&g= t; non-full enumeration.
> 4. Other criteria? These are other criteri= a we might want to evaluate
> proposals according to. And some kind o= f way to prioritize them / evaluate
> them against each other as trad= e offs.
> 5. Evaluate the proposals based on motivations, constraints= , and other
> criteria. This phase shouldn't involve comparing th= em to each other.
> 6. Produce a set of conclusions/opinions on which= proposals are worth
> pursuing further. This would be the phase wher= e 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 wit= h time and new information showing up.

About 2., I think one more th= ing to define is the list of use-cases, I would abstract out features and f= unctionality from use-cases. E.g, I think with the TLUV proposal, the tapro= ot output editing feature enables both "dynamic-amount" vault and= scaling payment pools.

About 3., I think this is going to be the ha= rd part. Collecting all the constraints and evaluating the risk tolerance o= f as-much-as-we-can community stakeholders in face of known and plausible r= isks. E.g, again with TLUV, I think it would make from now on the taproot i= nternal pubkey and tree of alternative scripts a kind of "dynamic stat= e".

About 4. I've quickly come to mind as additional criter= ias economic simulations of any feature, privacy advantages, toolchain impl= ementations complexity, evolvability and composability with future features= .

About 6. I agree I think it's good to withhold comparison furt= her down in the pipe we can, even if there is I would say some criteria-lea= rning heuristics by mirroring features against another.

> Each ph= ase 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) sequential= ly. The
> consensus reached at the end of each phase would be conside= red of course a
> group consensus of those who participated, not a gl= obal consensus, not a
> "bitcoin community consensus". Afte= r each phase, the results of that phase
> would be published more wid= ely to get broader community feedback. These
> results would include = what the major opinions are, what level of consensus
> each major opi= nion has, what the reasons/justifications behind each opinion
> are, = and various detailed opinions from individuals. It would be especially
&= gt; great to have detailed evaluations of each proposal published by variou= s
> people so anyone can go back and understand their thought process= (as
> opposed to a list of names attached to basically a thumbs up o= r thumbs
> down). Think like a supreme court decision kind of thing.<= br>
Yeah, again I don't see meetings as bounded in time rather happe= ning regularly as we have with LN ones. I guess it's going to take at l= east a good year for working group participants to take habits and familiar= ity with the problem space and reach consensus on the process itself. Furth= er, I would be even cautious about something restrained like "group co= nsensus" in Bitcoin FOSS. At best, it's just a snapshot of people&= #39;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 oppo= site opinions or blocking arguments. I wouldn't disqualify thumbs up or= thumbs down per se, there are marks of interest in a specific proposal, th= ough I lean to agree that I find more interesting too laid-out evaluations = and thought processes.

> The process doesn't need to be compl= ete 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
> consens= us more about each phase. I would imagine the group might loop
> thro= ugh 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 criter= ia
> 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 lo= op through phases 5
> and 6 until the set of proposals the group thin= ks is worth pursuing =C2=A0is
> narrowed down (ideally to 1 or 2).
For sure, in the function of new feedback arising it's good to con= stantly reevaluate proposals. Hopefully, I think any looping should make pr= oposals more formalized and accurate. We might also have the "easy&quo= t; covenants moving faster than the "hard" ones across the phases= . I believe the covenant problem space might be solved in an evolutionary w= ay, layer by layer akin to how LN moves forward.

Le=C2=A0mer. 3 ao=C3= =BBt 2022 =C3=A0=C2=A011:37, Billy Tetrud <billy.tetrud@gmail.com> a =C3=A9crit= =C2=A0:
@Antoine
I very much like your proposal of an open decentraliz= ed process for investigating the problem and solution spaces. IRC sounds li= ke a reasonable place for this kind of thing to happen. I also agree with R= yan 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-p= erson meetup can be organized in various locations to facilitate that kind = of cut through.=C2=A0

I would imagine=C2=A0the pha= ses the group could go through is:
1. Define the phases (these ph= ases). This list of 6 phases could be a starting point, but its probably be= st to open the floor to whether this feels like a reasonable=C2=A0approach = and if more phases are needed or if some aren't.=C2=A0
2. Def= ine and prioritize the motivations (ie the various features and functionali= ty we want out of covenants, like the ones you listed). By prioritize, I mo= stly mean figure out which motivations are most motivating to people and ra= te them by strength of motivation (rather than a ranked list).=C2=A0
<= div>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 covenan= t 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". E= g it might turn out most people don't have any tolerance for infinite r= ecursion, but don't mind non-full enumeration.=C2=A0
4. Other= criteria? These are other=C2=A0criteria we might want to evaluate proposal= s according to. And some kind of way to prioritize them / evaluate them aga= inst each other=C2=A0as trade offs.
5. Evaluate the proposals bas= ed on motivations, constraints, and other criteria. This phase shouldn'= t involve comparing them to each other.
6. Produce a set of concl= usions/opinions on which proposals are worth pursuing=C2=A0further. This wo= uld be the phase where proposals are compared.=C2=A0

Each phase would probably span over more than one meeting. I imagine eac= h phase basically consisting of discussing each individual nominated item= =C2=A0(ie motivations, constraints, other criteria, or proposals) sequentia= lly. 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 resul= ts of that phase would be published more widely to get broader community fe= edback. These results would include what the major opinions are, what level= of consensus each major opinion has, what the reasons/justifications behin= d each opinion are, and various detailed opinions from individuals. It woul= d be especially great to have detailed evaluations of each proposal publish= ed by various people so anyone can go back and understand their thought pro= cess (as opposed to a list of names attached to basically a thumbs up or th= umbs down). Think like a supreme court decision kind of thing.=C2=A0
<= div>
The process doesn't need to be complete after phase = 6. Any previous phase could be revisited,=C2=A0but after a phase is revisit= ed, the phases after it should probably be also revisited in order - or at = least until its decided a previous phase=C2=A0needs to be revisited again. = Each iteration would solidify consensus more about each phase. I would imag= ine the group might loop through phases 2, 3, and 4 a couple times (since c= onstraints might conflict with motivating features). It might be likely tha= t in phase 5 while evaluating proposals, people realize that there are addi= tional criteria that should be added and can propose going back to step 4 t= o do that. Hopefully we would get to the point where the motivations and co= nstraints and relatively solid consensuses and iterations can loop through = phases 5 and 6 until the set of proposals the group thinks is worth pursuin= g=C2=A0 is narrowed down (ideally to 1 or 2).=C2=A0






On Tue, Jul 26, 20= 22 at 11:47 AM Bram Cohen via bitcoin-dev <bitcoin-dev@lists.linuxfounda= tion.org> wrote:
On Mon, Jul 25, 2022 at 8:21 PM A= ntoine Riard <antoine.riard@gmail.com> wrote:
What = would be the canonical definition and examples of capabilities in the Bitco= in 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 d= epend 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/mail= man/listinfo/bitcoin-dev
--00000000000018557005e73f56b7--