path: root/e8/0deb772f5f3712cc65b444e5d2f42aaf494db9

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9FB92C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 Aug 2022 21:01:38 +0000 (UTC)
Received: by mail-vs1-xe32.google.com with SMTP id m66so4838031vsm.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
 <CAHUJnBDu+PNvER-FmpT8593vX-wAZ1oPWJjQaJ=d7Y4pso_Txw@mail.gmail.com>
 <CALZpt+E4Ej3KJ4WqkUDTF3DRhPTbUT5mw2c_eHLuxH7w1BbWGg@mail.gmail.com>
 <CAHUJnBB1wExgJhHUeU88ZMD28s6+9UT3Cfc43_UpK40hJwUFSg@mail.gmail.com>
 <CAGpPWDbbZ7PEpr4iwYwBn+5QcjjCx8qmTZVB98i2Z=UwDfwaTQ@mail.gmail.com>
 <CALZpt+HWzZdwMrtX=8rMpZ+e5dWcmbMeEx3jhTB_XnWz1n7RJQ@mail.gmail.com>
In-Reply-To: <CALZpt+HWzZdwMrtX=8rMpZ+e5dWcmbMeEx3jhTB_XnWz1n7RJQ@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sat, 27 Aug 2022 16:01:21 -0500
Message-ID: <CAGpPWDY0WV0dzRx2mD7kd-48+wrF=BJBf=ZB5R6+owPrdHTp+w@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000018557005e73f56b7"
X-Mailman-Approved-At: Sat, 27 Aug 2022 21:07:38 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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 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 <billy.tetrud@gmail.c=
om> 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 <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 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

<div dir=3D"ltr">&gt;=C2=A0

I would like to note it&#39;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...<div><br></div><div>=
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</div><div><br=
></div><div>&gt;=C2=A0

I would be even cautious about something restrained like &quot;group consen=
sus&quot; in Bitcoin FOSS. At best, it&#39;s just a snapshot of people&#39;=
s understanding of the technical issues in state X at time T</div><div><br>=
</div><div>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><div><br></div><div>&gt;=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.</div><div><br></div><div>Definitely.<br></div><div><br></div></div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Tue, Aug 9, 2022 at 3:15 PM Antoine Riard &lt;<a href=3D"mailto:antoine.ri=
ard@gmail.com" target=3D"_blank">antoine.riard@gmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi=
 Billy,<br><br>Thanks for your interest in a covenant working group.<br><br=
>&gt; place for this kind of thing to happen. I also agree with Ryan Grant&=
#39;s<br>&gt; comment about in-person cut-through (ie cut through the BS an=
d resolve<br>&gt; misunderstandings). Perhaps every 3 IRC meetings or so, a=
n in-person meetup<br>&gt; can be organized in various locations to facilit=
ate that kind of cut<br>&gt; through.<br><br>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&#39;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 &amp; 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&#39;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><br>&gt; I would imagine the phases the group could go through is:<br>&g=
t; 1. Define the phases (these phases). This list of 6 phases could be a<br=
>&gt; starting point, but its probably best to open the floor to whether th=
is<br>&gt; feels like a reasonable approach and if more phases are needed o=
r if some<br>&gt; aren&#39;t.<br>&gt; 2. Define and prioritize the motivati=
ons (ie the various features and<br>&gt; functionality we want out of coven=
ants, like the ones you listed). By<br>&gt; prioritize, I mostly mean figur=
e out which motivations are most motivating<br>&gt; to people and rate them=
 by strength of motivation (rather than a ranked<br>&gt; list).<br>&gt; 3. =
Define and prioritize the relevant constraints. These are things to<br>&gt;=
 avoid in any covenant implementation. Constraints that have been brought u=
p<br>&gt; in the past are things like preventing the possibility of infinit=
e covenant<br>&gt; recursion, full enumeration, preventing dynamic state, e=
tc. By prioritize<br>&gt; here, it might be useful to categorize them into =
categories like &quot;no<br>&gt; tolerance&quot;, &quot;some tolerance&quot=
;, &quot;no reservations&quot;. Eg it might turn out most<br>&gt; people do=
n&#39;t have any tolerance for infinite recursion, but don&#39;t mind<br>&g=
t; non-full enumeration.<br>&gt; 4. Other criteria? These are other criteri=
a we might want to evaluate<br>&gt; proposals according to. And some kind o=
f way to prioritize them / evaluate<br>&gt; them against each other as trad=
e offs.<br>&gt; 5. Evaluate the proposals based on motivations, constraints=
, and other<br>&gt; criteria. This phase shouldn&#39;t involve comparing th=
em to each other.<br>&gt; 6. Produce a set of conclusions/opinions on which=
 proposals are worth<br>&gt; pursuing further. This would be the phase wher=
e proposals are compared.<br><br>Yes, I think overall a lot is making sense=
. Though it&#39;s good to keep things as loose and see how it evaluates wit=
h time and new information showing up.<br><br>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 &quot;dynamic-amount&quot; vault and=
 scaling payment pools.<br><br>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 &quot;dynamic stat=
e&quot;.<br><br>About 4. I&#39;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=
.<br><br>About 6. I agree I think it&#39;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.<br><br>&gt; Each ph=
ase would probably span over more than one meeting. I imagine each<br>&gt; =
phase basically consisting of discussing each individual nominated item (ie=
<br>&gt; motivations, constraints, other criteria, or proposals) sequential=
ly. The<br>&gt; consensus reached at the end of each phase would be conside=
red of course a<br>&gt; group consensus of those who participated, not a gl=
obal consensus, not a<br>&gt; &quot;bitcoin community consensus&quot;. Afte=
r each phase, the results of that phase<br>&gt; would be published more wid=
ely to get broader community feedback. These<br>&gt; results would include =
what the major opinions are, what level of consensus<br>&gt; each major opi=
nion has, what the reasons/justifications behind each opinion<br>&gt; are, =
and various detailed opinions from individuals. It would be especially<br>&=
gt; great to have detailed evaluations of each proposal published by variou=
s<br>&gt; people so anyone can go back and understand their thought process=
 (as<br>&gt; opposed to a list of names attached to basically a thumbs up o=
r thumbs<br>&gt; down). Think like a supreme court decision kind of thing.<=
br><br>Yeah, again I don&#39;t see meetings as bounded in time rather happe=
ning regularly as we have with LN ones. I guess it&#39;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 &quot;group co=
nsensus&quot; in Bitcoin FOSS. At best, it&#39;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&#39;s more interesting to seek a lack of consensus in the sense of oppo=
site opinions or blocking arguments. I wouldn&#39;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.<br><br>&gt; The process doesn&#39;t need to be compl=
ete after phase 6. Any previous phase<br>&gt; could be revisited, but after=
 a phase is revisited, the phases after it<br>&gt; should probably be also =
revisited in order - or at least until its decided<br>&gt; a previous phase=
 needs to be revisited again. Each iteration would solidify<br>&gt; consens=
us more about each phase. I would imagine the group might loop<br>&gt; thro=
ugh phases 2, 3, and 4 a couple times (since constraints might conflict<br>=
&gt; with motivating features). It might be likely that in phase 5 while<br=
>&gt; evaluating proposals, people realize that there are additional criter=
ia<br>&gt; that should be added and can propose going back to step 4 to do =
that.<br>&gt; Hopefully we would get to the point where the motivations and=
 constraints<br>&gt; and relatively solid consensuses and iterations can lo=
op through phases 5<br>&gt; and 6 until the set of proposals the group thin=
ks is worth pursuing =C2=A0is<br>&gt; narrowed down (ideally to 1 or 2).<br=
><br>For sure, in the function of new feedback arising it&#39;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 &quot;easy&quo=
t; covenants moving faster than the &quot;hard&quot; 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. <br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 3 ao=C3=
=BBt 2022 =C3=A0=C2=A011:37, Billy Tetrud &lt;<a href=3D"mailto:billy.tetru=
d@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>&gt; a =C3=A9crit=
=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">@Antoine<div>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&#39;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</div><div><br></div><div>I would imagine=C2=A0the pha=
ses the group could go through is:</div><div>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&#39;t.=C2=A0</div><div>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><=
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 &quot;no =
tolerance&quot;, &quot;some tolerance&quot;, &quot;no reservations&quot;. E=
g it might turn out most people don&#39;t have any tolerance for infinite r=
ecursion, but don&#39;t mind non-full enumeration.=C2=A0</div><div>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.</div><div>5. Evaluate the proposals bas=
ed on motivations, constraints, and other criteria. This phase shouldn&#39;=
t involve comparing them to each other.</div><div>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</div><div><br></div><d=
iv>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 &quot;bitcoin community consensus&quot;. 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><=
div><br></div><div>The process doesn&#39;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</div><div><br></div><di=
v><br></div><div><br></div><div><br></div><div><br></div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 26, 20=
22 at 11:47 AM Bram Cohen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 25, 2022 at 8:21 PM A=
ntoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_blan=
k">antoine.riard@gmail.com</a>&gt; wrote:<br></div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">What =
would be the canonical definition and examples of capabilities in the Bitco=
in context ?<br></div></blockquote><div><br></div><div>Payments into vaults=
 which can only be accepted by that vault and are guaranteed to be subject =
to the vault&#39;s restrictions (the vault has a capability)</div><div><div=
><br>Oracles whose validity can be verified on chain (so transactions can d=
epend on what they say. The oracle has a capability)</div><div><br></div></=
div><div>Colored coins whose validity can be verified on chain (the colored=
 coins have a capability)</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
</blockquote></div>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>

--00000000000018557005e73f56b7--