Re: [bitcoin-dev] On a new community process to specify covenants

From: Billy Tetrud <billy.tetrud@gmail•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Date: Sat, 27 Aug 2022 16:01:21 -0500	[thread overview]
Message-ID: <CAGpPWDY0WV0dzRx2mD7kd-48+wrF=BJBf=ZB5R6+owPrdHTp+w@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+HWzZdwMrtX=8rMpZ+e5dWcmbMeEx3jhTB_XnWz1n7RJQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 14452 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 16500 bytes --]