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
