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>
In-Reply-To: <CAGpPWDbbZ7PEpr4iwYwBn+5QcjjCx8qmTZVB98i2Z=UwDfwaTQ@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 9 Aug 2022 16:15:35 -0400
Message-ID: <CALZpt+HWzZdwMrtX=8rMpZ+e5dWcmbMeEx3jhTB_XnWz1n7RJQ@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000552a105e5d499ea"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Precedence: list

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

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 motivatin=
g
> 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 mos=
t
> 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 / evaluat=
e
> 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 phas=
e
> would be published more widely to get broader community feedback. These
> results would include what the major opinions are, what level of consensu=
s
> 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 decide=
d
> 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=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 reasonab=
le
> 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 meet=
up
> 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 motivatin=
g
> 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 covena=
nt
> 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 mos=
t
> 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 / evaluat=
e
> 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 phas=
e
> would be published more widely to get broader community feedback. These
> results would include what the major opinions are, what level of consensu=
s
> each major opinion has, what the reasons/justifications behind each opini=
on
> are, and various detailed opinions from individuals. It would be especial=
ly
> 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 decide=
d
> a previous phase needs to be revisited again. Each iteration would solidi=
fy
> consensus more about each phase. I would imagine the group might loop
> through phases 2, 3, and 4 a couple times (since constraints might confli=
ct
> 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
>>
>

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

<div dir=3D"ltr">Hi Billy,<br><br>Thanks for your interest in a covenant wo=
rking group.<br><br>&gt; place for this kind of thing to happen. I also agr=
ee with Ryan Grant&#39;s<br>&gt; comment about in-person cut-through (ie cu=
t through the BS and resolve<br>&gt; misunderstandings). Perhaps every 3 IR=
C meetings or so, an in-person meetup<br>&gt; can be organized in various l=
ocations to facilitate that kind of cut<br>&gt; through.<br><br>I really ap=
preciate 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&#39;s real work for the organizers in ter=
ms of time and energy: finding a common date making consensus, an acceptabl=
e host country (i.e respecting the travel policy of the widest, e.g organiz=
ing Scaling in Israel in 2019 was an issue for some passport holders), a st=
andard meeting location, seeking event sponsors, communicating all those in=
fos well ahead to ease everyone travels, ensuring coffees &amp; foods suiti=
ng many different diets, collecting topics of discussions, etc. Further, ev=
en 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&#39;m clearly not interested in doing it=
 anymore, though it would be cool if someone would like to do it for covena=
nts in the future.<br><br>&gt; I would imagine the phases the group could g=
o through is:<br>&gt; 1. Define the phases (these phases). This list of 6 p=
hases could be a<br>&gt; starting point, but its probably best to open the =
floor to whether this<br>&gt; feels like a reasonable approach and if more =
phases are needed or if some<br>&gt; aren&#39;t.<br>&gt; 2. Define and prio=
ritize the motivations (ie the various features and<br>&gt; functionality w=
e 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 p=
eople and rate them by strength of motivation (rather than a ranked<br>&gt;=
 list).<br>&gt; 3. Define and prioritize the relevant constraints. These ar=
e things to<br>&gt; avoid in any covenant implementation. Constraints that =
have been brought up<br>&gt; in the past are things like preventing the pos=
sibility of infinite covenant<br>&gt; recursion, full enumeration, preventi=
ng dynamic state, etc. By prioritize<br>&gt; here, it might be useful to ca=
tegorize them into categories like &quot;no<br>&gt; tolerance&quot;, &quot;=
some tolerance&quot;, &quot;no reservations&quot;. Eg it might turn out mos=
t<br>&gt; people don&#39;t have any tolerance for infinite recursion, but d=
on&#39;t mind<br>&gt; non-full enumeration.<br>&gt; 4. Other criteria? Thes=
e are other criteria we might want to evaluate<br>&gt; proposals according =
to. And some kind of way to prioritize them / evaluate<br>&gt; them against=
 each other as trade offs.<br>&gt; 5. Evaluate the proposals based on motiv=
ations, constraints, and other<br>&gt; criteria. This phase shouldn&#39;t i=
nvolve comparing them to each other.<br>&gt; 6. Produce a set of conclusion=
s/opinions on which proposals are worth<br>&gt; pursuing further. This woul=
d 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 things as loose and see h=
ow it evaluates with time and new information showing 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-amo=
unt&quot; vault and scaling payment pools.<br><br>About 3., I think this is=
 going to be the hard part. Collecting all the constraints and evaluating t=
he risk tolerance of as-much-as-we-can community stakeholders in face of kn=
own and plausible risks. E.g, again with TLUV, I think it would make from n=
ow on the taproot internal pubkey and tree of alternative scripts a kind of=
 &quot;dynamic state&quot;.<br><br>About 4. I&#39;ve quickly come to mind a=
s additional criterias economic simulations of any feature, privacy advanta=
ges, toolchain implementations complexity, evolvability and composability w=
ith future features.<br><br>About 6. I agree I think it&#39;s good to withh=
old comparison further down in the pipe we can, even if there is I would sa=
y some criteria-learning heuristics by mirroring features against another.<=
br><br>&gt; Each phase would probably span over more than one meeting. I im=
agine each<br>&gt; phase basically consisting of discussing each individual=
 nominated item (ie<br>&gt; motivations, constraints, other criteria, or pr=
oposals) sequentially. The<br>&gt; consensus reached at the end of each pha=
se would be considered of course a<br>&gt; group consensus of those who par=
ticipated, not a global consensus, not a<br>&gt; &quot;bitcoin community co=
nsensus&quot;. After each phase, the results of that phase<br>&gt; would be=
 published more widely to get broader community feedback. These<br>&gt; res=
ults would include what the major opinions are, what level of consensus<br>=
&gt; each major opinion has, what the reasons/justifications behind each op=
inion<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 various<br>&gt; people so anyone can go back and understand th=
eir thought process (as<br>&gt; opposed to a list of names attached to basi=
cally a thumbs up or thumbs<br>&gt; down). Think like a supreme court decis=
ion kind of thing.<br><br>Yeah, again I don&#39;t see meetings as bounded i=
n 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 group participants to take =
habits and familiarity with the problem space and reach consensus on the pr=
ocess itself. Further, I would be even cautious about 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 technical issues in state X a=
t time T, and that can evaluate quickly in function of new findings or issu=
es arising. I think it&#39;s more interesting to seek a lack of consensus i=
n the sense of opposite opinions or blocking arguments. I wouldn&#39;t disq=
ualify thumbs up or thumbs down per se, there are marks of interest in a sp=
ecific proposal, though I lean to agree that I find more interesting too la=
id-out evaluations and thought processes.<br><br>&gt; The process doesn&#39=
;t need to be complete after phase 6. Any previous phase<br>&gt; could be r=
evisited, but after a phase is revisited, the phases after it<br>&gt; shoul=
d probably be also revisited in order - or at least until its decided<br>&g=
t; a previous phase needs to be revisited again. Each iteration would solid=
ify<br>&gt; consensus more about each phase. I would imagine the group migh=
t loop<br>&gt; through 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 ar=
e additional criteria<br>&gt; that should be added and can propose going ba=
ck 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 an=
d iterations can loop through phases 5<br>&gt; and 6 until the set of propo=
sals the group thinks is worth pursuing =C2=A0is<br>&gt; narrowed down (ide=
ally to 1 or 2).<br><br>For sure, in the function of new feedback arising i=
t&#39;s good to constantly reevaluate proposals. Hopefully, I think any loo=
ping should make proposals more formalized and accurate. We might also have=
 the &quot;easy&quot; covenants moving faster than the &quot;hard&quot; one=
s across the phases. I believe the covenant problem space might be solved i=
n an evolutionary way, layer by layer akin to how LN moves forward. <br></d=
iv><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.tetrud@gmail.com">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>

--0000000000000552a105e5d499ea--