MIME-Version: 1.0
References: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
In-Reply-To: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
From: Bram Cohen <bram@chia.net>
Date: Sun, 24 Jul 2022 11:22:51 -0700
Message-ID: <CAHUJnBDu+PNvER-FmpT8593vX-wAZ1oPWJjQaJ=d7Y4pso_Txw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005945b305e49128b4"
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Precedence: list

--0000000000005945b305e49128b4
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Indeed this range has grown wild. Without aiming to be exhaustive (I'm
> certainly missing some interesting proposals lost in the abyss of
> bitcointalk.org), we can mention the following use-cases: multi-party
> stateful contracts [11], congestion trees [12], payment pools [13], "eltoo"
> layered commitments [14], programmable vaults [15], multi-events contracts
> [16], blockchain-as-oracle bets [17], spacechains [18], trustless
> collateral lending [19], ...
>

The big question you missed is whether capabilities are in scope for a
covenants proposal. In particular, vaults work a lot better when payments
to them are immediately locked up in the vault rather than it having to do
a step to accept them first.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Jul 20, 2022 at 2:46 PM Antoine R=
iard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><div c=
lass=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"><div=
 dir=3D"ltr">Indeed this range has grown wild. Without aiming to be exhaust=
ive (I&#39;m certainly missing some interesting proposals lost in the abyss=
 of <a href=3D"http://bitcointalk.org" target=3D"_blank">bitcointalk.org</a=
>), we can mention the following use-cases: multi-party stateful contracts =
[11], congestion trees [12], payment pools [13], &quot;eltoo&quot; layered =
commitments [14], programmable vaults [15], multi-events contracts [16], bl=
ockchain-as-oracle bets [17], spacechains [18], trustless collateral lendin=
g [19], ...<br></div></blockquote><div><br></div><div>The big question you =
missed is whether capabilities are in scope for a covenants proposal. In pa=
rticular, vaults work a lot better when payments to them are immediately lo=
cked up in the vault rather than it having to do a step to accept them firs=
t.</div></div></div>

--0000000000005945b305e49128b4--