path: root/bb/063cb4e302ee7f3e3e8348783bacf3c2bc5fc6

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 07E1CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Aug 2022 15:46:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id D3F0741674
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Aug 2022 15:46:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D3F0741674
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=qWAszHOM
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 HDPZMNJ5pnjR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Aug 2022 15:46:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 81B0E41682
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com
 [IPv6:2607:f8b0:4864:20::132])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 81B0E41682
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Aug 2022 15:46:35 +0000 (UTC)
Received: by mail-il1-x132.google.com with SMTP id e7so4727796ilc.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Aug 2022 08:46:35 -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=X3pdCH5GeTAzQDTWCaw4ATxpvP9+QpIvzmVruoZ849I=;
 b=qWAszHOM6ZtRKj0zxtrWSCSWYmwBWsm2elpEH/WJOY97FwXqSWoVMh1EdRqCpMSMnj
 fX5Munb8tX5ddXXOxMejhalflAtJq3pR5ZJziBoKSGM3BQ8HHK5FPzZl7I+xq9bsfN9y
 FeC6PhT0uNXPgje0gvj5YOHW8Fw5huAHNXTyXU1/9CP4GUmD/rSSNQH0apRFfXT0g5q0
 s9PtRFcTu/LVkuWlxyWt2GBuL1CNYripvBcmZlnvKjohDA2bf1kt2h1ZfZaXgWzcLRrx
 qHXhLqq6Rwt+iuJ36SIymm+y88o0e8PEYk+pF+TGpsUj+cBlKVAsYcEWi/y2YCNDJrI5
 kIhQ==
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=X3pdCH5GeTAzQDTWCaw4ATxpvP9+QpIvzmVruoZ849I=;
 b=DoxSTlUiz5s1LYFYwQvXoS+kCvZg92S9spKl5/pqa5Pks/xJ3C8a5bM64m3Mp2T49f
 oXozoXxQv+LRUtzm1wfCp4YcsZ3oqacP/GWKTlC+wbhBybybOXVcJGCPbYMZuHXtTPdG
 kkSChH7eL+fVoejO46ppXa7eQfTbOFP84PJJJQehaE1P7zFXLLC8NEjOVpSbe+SoR9kc
 vtVYyJ5I+rXSI4ueTqRBo+I530VfxEe20UkrqFw6z3iyVw8vEMrEvJqcw+X3/cVXxg1Z
 wkyORDIFPr9/19ckVV/BiW+ARCfVXl6FyGjogTLZV9OqZgW383sigwDvJpIgA0/rcVB+
 Lbuw==
X-Gm-Message-State: ACgBeo1JpohS6nEqhbUM+ZablDLHjroDVl7CeMFv4iIVTlH+WTF5DVV+
 fTRCWx7XiAZdMJ+nq0A2IvXtpAeaEC81nBQDIO0=
X-Google-Smtp-Source: AA6agR7oCLM8MENBWBYpvYJcK2k/cJbJAtrV7VxKkx21CYAldcw9I2oNo5b6fkmX/s/P84l8o+q2QWtSEn7WwJ4oQbM=
X-Received: by 2002:a05:6e02:1102:b0:2ea:da70:efea with SMTP id
 u2-20020a056e02110200b002eada70efeamr7392225ilk.70.1661874394405; Tue, 30 Aug
 2022 08:46:34 -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>
 <CAGpPWDY0WV0dzRx2mD7kd-48+wrF=BJBf=ZB5R6+owPrdHTp+w@mail.gmail.com>
In-Reply-To: <CAGpPWDY0WV0dzRx2mD7kd-48+wrF=BJBf=ZB5R6+owPrdHTp+w@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 30 Aug 2022 16:46:23 +0100
Message-ID: <CALZpt+FViEy=2zABg-XXt_NVMTS4ss7s+2zKbUGQq9xpQr13_w@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f09da705e77748e9"
X-Mailman-Approved-At: Tue, 30 Aug 2022 15:52:52 +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: Tue, 30 Aug 2022 15:46:43 -0000

--000000000000f09da705e77748e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Billy,

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

Minimizing travel hurdles for everyone sounds wise. About decentralized
in-person meetings we already have a wide network of BitDev all around the
world that can be opportunities to foster communication on covenant R&D
advances. Staying interested in participating in in-person covenant-focus
meetings though I won't volunteer to organize them, from my experience it's
a real trade different from Bitcoin research engineering!

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

Yeah, collecting, building and maintaining a set of strong data points that
would improve the community covenant information-gathering process.
However, I think observing consensus is better left to everyone's personal
judgement rather than proclaiming it. At best, we can monitor the lack of
consensus.

There is already an ongoing effort to document primitives :
https://github.com/bitcoinops/bitcoinops.github.io/pull/806 and making
progress on the use-cases collection soon.


Le sam. 27 ao=C3=BBt 2022 =C3=A0 22:01, Billy Tetrud <billy.tetrud@gmail.co=
m> a
=C3=A9crit :

> >  I would like to note it's real work for the organizers in terms of tim=
e
> 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. Wou=
ld
> 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 ide=
a
> 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 evolutionar=
y
> 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 o=
f 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 so=
me
>> passport holders), a standard meeting location, seeking event sponsors,
>> communicating all those infos well ahead to ease everyone travels, ensur=
ing
>> 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 thi=
s
>> > 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 ranke=
d
>> > 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 thi=
nk
>> 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 implementation=
s
>> complexity, evolvability and composability with future features.
>>
>> About 6. I agree I think it's good to withhold comparison further down i=
n
>> 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 ite=
m
>> (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. Thes=
e
>> > 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 vario=
us
>> > 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. Furthe=
r,
>> I would be even cautious about something restrained like "group consensu=
s"
>> 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 interestin=
g
>> to seek a lack of consensus in the sense of opposite opinions or blockin=
g
>> 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 i=
t
>> > 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 criteri=
a
>> > 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 phase=
s
>> 5
>> > and 6 until the set of proposals the group thinks is worth pursuing  i=
s
>> > narrowed down (ideally to 1 or 2).
>>
>> For sure, in the function of new feedback arising it's good to constantl=
y
>> reevaluate proposals. Hopefully, I think any looping should make proposa=
ls
>> 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.=
com> 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 reason=
able
>>> 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 me=
etup
>>> 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 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 motivat=
ing
>>> 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 cove=
nant
>>> 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 m=
ost
>>> 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 / evalu=
ate
>>> 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 detaile=
d
>>> evaluations of each proposal published by various people so anyone can =
go
>>> back and understand their thought process (as opposed to a list of name=
s
>>> 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 af=
ter
>>> it should probably be also revisited in order - or at least until its
>>> decided a previous phase needs to be revisited again. Each iteration wo=
uld
>>> solidify consensus more about each phase. I would imagine the group mig=
ht
>>> 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 d=
o
>>> 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 w=
orth
>>> 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 i=
n
>>>>> 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
>>>>
>>>

--000000000000f09da705e77748e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Billy,<div><br></div><div>&gt; I was actually not think=
ing 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=C2=A0make all those date/=
visa/etc issues a lot easier.</div><div><br></div><div>Minimizing travel hu=
rdles for everyone sounds wise. About decentralized in-person meetings we a=
lready have a wide network of BitDev all around the world that can be oppor=
tunities to foster communication on covenant R&amp;D advances. Staying inte=
rested in participating in in-person covenant-focus meetings though I won&#=
39;t volunteer to organize them, from my=C2=A0experience it&#39;s a real tr=
ade different from Bitcoin research engineering!</div><div><br></div><div>&=
gt; 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=C2=A0=
idea has been discussed, thought through, and has actual well-reasoned supp=
ort. Whatever you call it, it would be a useful set of data points.</div><d=
iv><br></div><div>Yeah, collecting, building and maintaining a set of stron=
g data points that would improve the community covenant information-gatheri=
ng process. However, I think observing consensus is better left to everyone=
&#39;s personal judgement rather than proclaiming it. At best, we can monit=
or the lack of consensus.</div><div><br></div><div>There is already an ongo=
ing effort to document primitives :=C2=A0<a href=3D"https://github.com/bitc=
oinops/bitcoinops.github.io/pull/806">https://github.com/bitcoinops/bitcoin=
ops.github.io/pull/806</a> and making progress on the use-cases collection =
soon.</div><div>=C2=A0=C2=A0 =C2=A0</div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0sam. 27 ao=C3=BBt 2022 =C3=
=A0=C2=A022:01, Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com">=
billy.tetrud@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex=
"><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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr">Hi Billy,<br><br>Thanks for your in=
terest in a covenant working group.<br><br>&gt; place for this kind of thin=
g to happen. I also agree with Ryan Grant&#39;s<br>&gt; comment about in-pe=
rson cut-through (ie cut through the BS and resolve<br>&gt; misunderstandin=
gs). Perhaps every 3 IRC meetings or so, an in-person meetup<br>&gt; can be=
 organized in various locations to facilitate that kind of cut<br>&gt; thro=
ugh.<br><br>I really appreciate in-person cut-through to resolve misunderst=
andings and accelerate the information synchronization across the stakehold=
ers of a problem space. However, I would like to note it&#39;s real work fo=
r 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, com=
municating all those infos well ahead to ease everyone travels, ensuring co=
ffees &amp; foods suiting many different diets, collecting topics of discus=
sions, etc. Further, even assuming travel support, it can still be a prohib=
itive cost for a lot of participants, e.g if you have to request months ahe=
ad to the host country authorities a dedicated 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 l=
ike to do it for covenants in the future.<br><br>&gt; I would imagine the p=
hases the group could go through is:<br>&gt; 1. Define the phases (these ph=
ases). This list of 6 phases could be a<br>&gt; starting point, but its pro=
bably best to open the floor to whether this<br>&gt; feels like a reasonabl=
e approach and if more phases are needed or if some<br>&gt; aren&#39;t.<br>=
&gt; 2. Define and prioritize the motivations (ie the various features and<=
br>&gt; functionality we want out of covenants, like the ones you listed). =
By<br>&gt; prioritize, I mostly mean figure out which motivations are most =
motivating<br>&gt; to people and rate them by strength of motivation (rathe=
r than a ranked<br>&gt; list).<br>&gt; 3. Define and prioritize the relevan=
t constraints. These are things to<br>&gt; avoid in any covenant implementa=
tion. Constraints that have been brought up<br>&gt; in the past are things =
like preventing the possibility of infinite covenant<br>&gt; recursion, ful=
l enumeration, preventing dynamic state, etc. By prioritize<br>&gt; here, i=
t might be useful to categorize them into categories like &quot;no<br>&gt; =
tolerance&quot;, &quot;some tolerance&quot;, &quot;no reservations&quot;. E=
g it might turn out most<br>&gt; people don&#39;t have any tolerance for in=
finite recursion, but don&#39;t mind<br>&gt; non-full enumeration.<br>&gt; =
4. Other criteria? These are other criteria we might want to evaluate<br>&g=
t; proposals according to. And some kind of way to prioritize them / evalua=
te<br>&gt; them against each other as trade offs.<br>&gt; 5. Evaluate the p=
roposals based on motivations, constraints, and other<br>&gt; criteria. Thi=
s phase shouldn&#39;t involve comparing them to each other.<br>&gt; 6. Prod=
uce a set of conclusions/opinions on which proposals are worth<br>&gt; purs=
uing further. This would be the phase where proposals are compared.<br><br>=
Yes, I think overall a lot is making sense. Though it&#39;s good to keep th=
ings as loose and see how it evaluates with time and new information showin=
g up.<br><br>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 &quot;dynamic-amount&quot; vault and scaling payment pools.<br><br>Ab=
out 3., I think this is going to be the hard part. Collecting all the const=
raints and evaluating the risk tolerance of as-much-as-we-can community sta=
keholders in face of known and plausible risks. E.g, again with TLUV, I thi=
nk it would make from now on the taproot internal pubkey and tree of altern=
ative scripts a kind of &quot;dynamic state&quot;.<br><br>About 4. I&#39;ve=
 quickly come to mind as additional criterias economic simulations of any f=
eature, privacy advantages, toolchain implementations complexity, evolvabil=
ity and composability with future features.<br><br>About 6. I agree I think=
 it&#39;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 fea=
tures against another.<br><br>&gt; Each phase would probably span over more=
 than one meeting. I imagine each<br>&gt; phase basically consisting of dis=
cussing each individual nominated item (ie<br>&gt; motivations, constraints=
, other criteria, or proposals) sequentially. The<br>&gt; consensus reached=
 at the end of each phase would be considered of course a<br>&gt; group con=
sensus of those who participated, not a global consensus, not a<br>&gt; &qu=
ot;bitcoin community consensus&quot;. After each phase, the results of that=
 phase<br>&gt; would be published more widely to get broader community feed=
back. These<br>&gt; results would include what the major opinions are, what=
 level of consensus<br>&gt; each major opinion has, what the reasons/justif=
ications behind each opinion<br>&gt; are, and various detailed opinions fro=
m individuals. It would be especially<br>&gt; great to have detailed evalua=
tions of each proposal published by various<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 or thumbs<br>&gt; down). Think lik=
e a supreme court decision kind of thing.<br><br>Yeah, again I don&#39;t se=
e meetings as bounded in time rather happening regularly as we have with LN=
 ones. I guess it&#39;s going to take at least a good year for working grou=
p participants to take habits and familiarity with the problem space and re=
ach consensus on the process itself. Further, I would be even cautious abou=
t something restrained like &quot;group consensus&quot; in Bitcoin FOSS. At=
 best, it&#39;s just a snapshot of people&#39;s understanding of the techni=
cal 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 see=
k a lack of consensus in the sense of opposite opinions or blocking argumen=
ts. I wouldn&#39;t disqualify thumbs up or thumbs down per se, there are ma=
rks of interest in a specific proposal, though 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 complete after phase 6. Any previous p=
hase<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. Eac=
h iteration would solidify<br>&gt; consensus more about each phase. I would=
 imagine the group might loop<br>&gt; through phases 2, 3, and 4 a couple t=
imes (since constraints might conflict<br>&gt; with motivating features). I=
t might be likely that in phase 5 while<br>&gt; evaluating proposals, peopl=
e realize that there are additional criteria<br>&gt; that should be added a=
nd 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 relative=
ly solid consensuses and iterations can loop through phases 5<br>&gt; and 6=
 until the set of proposals the group thinks 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 constantly reevaluate proposals. Hop=
efully, I think any looping should make proposals more formalized and accur=
ate. We might also have the &quot;easy&quot; covenants moving faster than t=
he &quot;hard&quot; 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. <br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">Le=C2=A0mer. 3 ao=C3=BBt 2022 =C3=A0=C2=A011:37, Billy =
Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">bill=
y.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-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr">@Antoine<div>I very much like your proposal of an open dec=
entralized process for investigating the problem and solution spaces. IRC s=
ounds like a reasonable place for this kind of thing to happen. I also agre=
e with Ryan 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-person meetup can be organized in various locations to facilitate th=
at kind of cut through.=C2=A0</div><div><br></div><div>I would imagine=C2=
=A0the phases the group could go through is:</div><div>1. Define the phases=
 (these phases). This list of 6 phases could be a starting point, but its p=
robably best 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. Define and prioritize the motivations (ie the various features and=
 functionality we want out of covenants, like the ones you listed). By prio=
ritize, I mostly mean figure out which motivations are most motivating to p=
eople and rate them by strength of motivation (rather than a ranked list).=
=C2=A0</div><div>3. Define and prioritize the relevant constraints. These a=
re things to avoid in any covenant implementation. Constraints that have be=
en brought up in the past are things like preventing the possibility of inf=
inite covenant recursion, full enumeration, preventing dynamic state, etc. =
By prioritize here, it might be useful to categorize them into categories l=
ike &quot;no tolerance&quot;, &quot;some tolerance&quot;, &quot;no reservat=
ions&quot;. Eg it might turn out most people don&#39;t have any tolerance f=
or infinite recursion, but don&#39;t mind non-full enumeration.=C2=A0</div>=
<div>4. Other criteria? These are other=C2=A0criteria we might want to eval=
uate proposals according to. And some kind of way to prioritize them / eval=
uate them against each other=C2=A0as trade offs.</div><div>5. Evaluate the =
proposals based on motivations, constraints, and other criteria. This phase=
 shouldn&#39;t involve comparing them to each other.</div><div>6. Produce a=
 set of conclusions/opinions on which proposals are worth pursuing=C2=A0fur=
ther. This would be the phase where proposals are compared.=C2=A0</div><div=
><br></div><div>Each phase would probably span over more than one meeting. =
I imagine each phase basically consisting of discussing each individual nom=
inated item=C2=A0(ie motivations, constraints, other criteria, or proposals=
) sequentially. The consensus reached at the end of each phase would be con=
sidered of course a group consensus of those who participated, not a global=
 consensus, not a &quot;bitcoin community consensus&quot;. After each phase=
, the results of that phase would be published more widely to get broader c=
ommunity feedback. These results would include what the major opinions are,=
 what level of consensus each major opinion has, what the reasons/justifica=
tions behind each opinion are, and various detailed opinions from individua=
ls. It would be especially great to have detailed evaluations of each propo=
sal 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 thum=
bs up or thumbs 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 pha=
se is revisited, the phases after it should probably be also revisited in o=
rder - or at least until its decided a previous phase=C2=A0needs to be revi=
sited 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 t=
imes (since constraints might conflict with motivating features). It might =
be likely that in phase 5 while evaluating proposals, people realize that t=
here are additional criteria that should be added and can propose going bac=
k to step 4 to do that. Hopefully we would get to the point where the motiv=
ations 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=C2=A0 is narrowed down (ideally to 1 or 2).=C2=A0</div><div>=
<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tu=
e, Jul 26, 2022 at 11:47 AM Bram Cohen via bitcoin-dev &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div dir=3D"ltr">On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard &lt;<a =
href=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gma=
il.com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr">What would be the canonical definition and examples of cap=
abilities in the Bitcoin context ?<br></div></blockquote><div><br></div><di=
v>Payments into vaults which can only be accepted by that vault and are gua=
ranteed to be subject to the vault&#39;s restrictions (the vault has a capa=
bility)</div><div><div><br>Oracles whose validity can be verified on chain =
(so transactions can depend 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><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color: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>
</blockquote></div>

--000000000000f09da705e77748e9--