summaryrefslogtreecommitdiff
path: root/4d/72998d4c155d13109b0e3128be96ecf18d4e9c
blob: b437413345f1bc25fc12635dd1ec05ab3597c70a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C16C8C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 03:21:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 9938B40439
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 03:21:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9938B40439
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=dXLeWME0
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7TJeqxPV9xU8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 03:21:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 982334015A
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com
 [IPv6:2607:f8b0:4864:20::130])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 982334015A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 03:21:23 +0000 (UTC)
Received: by mail-il1-x130.google.com with SMTP id v2so3315500ilm.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Jul 2022 20:21:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=3P1FUlcylTECsh9ofsTMfWVVJBQRO7HFq7FI3VyqlvA=;
 b=dXLeWME0Ey1SuxEQB5Kg1iPJNoqncrblcOfM8R2VLjur1UFbxoslSHxEXtf/NYyL9U
 AOP6TgSpvv3Bfdsr1aS2b50xyZqCYIG4ibL20kIt3U8Z+6jCA1THQyQzUtE3JPBVmELT
 cxmpkIOu67/RxaTmABsohBszmB30GS3VIyvyrzj+vdz4TKTwEZj03xV2FjEeYvrowA5t
 BjJRoqG2MUrguB/oAsWl5Y+Ud5nhPYW330ra/O/qGMm8StCK6WRcnEFTgA2iwJHV74fJ
 7a/KXyy43zce2wrT7MXrAxt+clDIN3eZXV3kanvjokyje1BLV+v7UFw09bdcyuM3ZQZ8
 ZAHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=3P1FUlcylTECsh9ofsTMfWVVJBQRO7HFq7FI3VyqlvA=;
 b=Lp/wRN0AMU/SZjauftrnuspi28ZU/EpaAyA8X2iICPm3EGsLX8aBezzziKkDSanoWC
 peRv1dXtzzJpSwxcF+x4+EVCSZOJzRVJkv/ixM/vnO0rF76dpboUxT4c2PyuwTxIoBgD
 tu7rNclH5wkWVtQSceFGaTw5R+aOTGDYukzIjqzqF9Cjci1JhxYItbIUc4XbIOFaMWHs
 wcreFgULMv29XADUbuIVnVEpKarkRK2FtKXNqftF4LCW8qB+QOyUG8HZPgvlUUw+mFZS
 Jih5mpsTjnkVVLZOfaMX1HHiDYYaNJRPWr//ygvkcRi24RWZyh7OO0pvACluhEZCMQ+w
 0sRw==
X-Gm-Message-State: AJIora8UZgnCuXD+QHVqjhmTePcBkSKiX92dlziOWL7ktruZnE0ESSB/
 gRFbGc+K2u2R60NQqGl/D3jifYrA+sLJro4DlfIWpESZiVc=
X-Google-Smtp-Source: AGRyM1tCDlQx2ZDv+SzYr5s6JQutpHK5G2zD1ESd7UKAMDHfEoQD5oc+zTNLnWTfdF0Mi7NClKge5tXkT6/jk0A3nsE=
X-Received: by 2002:a05:6e02:18c7:b0:2dc:404a:8416 with SMTP id
 s7-20020a056e0218c700b002dc404a8416mr5858273ilu.39.1658805682681; Mon, 25 Jul
 2022 20:21:22 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
 <CAHUJnBDu+PNvER-FmpT8593vX-wAZ1oPWJjQaJ=d7Y4pso_Txw@mail.gmail.com>
In-Reply-To: <CAHUJnBDu+PNvER-FmpT8593vX-wAZ1oPWJjQaJ=d7Y4pso_Txw@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 25 Jul 2022 23:21:11 -0400
Message-ID: <CALZpt+E4Ej3KJ4WqkUDTF3DRhPTbUT5mw2c_eHLuxH7w1BbWGg@mail.gmail.com>
To: Bram Cohen <bram@chia.net>
Content-Type: multipart/alternative; boundary="00000000000077bb4305e4accbba"
X-Mailman-Approved-At: Tue, 26 Jul 2022 08:20:21 +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, 26 Jul 2022 03:21:24 -0000

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

What would be the canonical definition and examples of capabilities in the
Bitcoin context ?

In anycase, I believe it would be better to start a covenant process from
the use-cases in themselves, and analyse the trade-offs of any set of
contracting primitives, or even new Bitcoin fields if they're required
building blocks of the use-cases.

Le dim. 24 juil. 2022 =C3=A0 14:23, Bram Cohen <bram@chia.net> a =C3=A9crit=
 :

> 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], "elt=
oo"
>> layered commitments [14], programmable vaults [15], multi-events contrac=
ts
>> [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 d=
o
> a step to accept them first.
>

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

<div dir=3D"ltr">What would be the canonical definition and examples of cap=
abilities in the Bitcoin context ?<br><br>In anycase, I believe it would be=
 better to start a covenant process from the use-cases in themselves, and a=
nalyse the trade-offs of any set of contracting primitives, or even new Bit=
coin fields if they&#39;re required building blocks of the use-cases.<br></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0dim. 24 juil. 2022 =C3=A0=C2=A014:23, Bram Cohen &lt;<a href=3D"mailt=
o:bram@chia.net">bram@chia.net</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr=
">On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</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:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I=
ndeed this range has grown wild. Without aiming to be exhaustive (I&#39;m c=
ertainly missing some interesting proposals lost in the abyss of <a href=3D=
"http://bitcointalk.org" target=3D"_blank">bitcointalk.org</a>), we can men=
tion the following use-cases: multi-party stateful contracts [11], congesti=
on trees [12], payment pools [13], &quot;eltoo&quot; layered commitments [1=
4], programmable vaults [15], multi-events contracts [16], blockchain-as-or=
acle bets [17], spacechains [18], trustless collateral lending [19], ...<br=
></div></blockquote><div><br></div><div>The big question you missed is whet=
her capabilities are in scope for a covenants proposal. In particular, vaul=
ts 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.</div></div>=
</div>
</blockquote></div>

--00000000000077bb4305e4accbba--