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