Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C16C8C002D for ; 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 ; 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 ; 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 ; Tue, 26 Jul 2022 03:21:23 +0000 (UTC) Received: by mail-il1-x130.google.com with SMTP id v2so3315500ilm.4 for ; 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: In-Reply-To: From: Antoine Riard Date: Mon, 25 Jul 2022 23:21:11 -0400 Message-ID: To: Bram Cohen Content-Type: multipart/alternative; boundary="00000000000077bb4305e4accbba" X-Mailman-Approved-At: Tue, 26 Jul 2022 08:20:21 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
What would be the canonical definition and examples of cap= abilities in the Bitcoin context ?

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're required building blocks of the use-cases.

Le= =C2=A0dim. 24 juil. 2022 =C3=A0=C2=A014:23, Bram Cohen <bram@chia.net> a =C3=A9crit=C2=A0:
On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
I= ndeed this range has grown wild. Without aiming to be exhaustive (I'm c= ertainly missing some interesting proposals lost in the abyss of bitcointalk.org), we can men= tion the following use-cases: multi-party stateful contracts [11], congesti= on trees [12], payment pools [13], "eltoo" layered commitments [1= 4], programmable vaults [15], multi-events contracts [16], blockchain-as-or= acle bets [17], spacechains [18], trustless collateral lending [19], ...

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.
=
--00000000000077bb4305e4accbba--