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

From: Billy Tetrud <billy.tetrud@gmail•com>
To: Bram Cohen <bram@chia•net>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Date: Wed, 3 Aug 2022 10:37:05 -0500	[thread overview]
Message-ID: <CAGpPWDbbZ7PEpr4iwYwBn+5QcjjCx8qmTZVB98i2Z=UwDfwaTQ@mail.gmail.com> (raw)
In-Reply-To: <CAHUJnBB1wExgJhHUeU88ZMD28s6+9UT3Cfc43_UpK40hJwUFSg@mail.gmail.com>

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

@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: 6298 bytes --]