From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0093EC002D for ; Wed, 3 Aug 2022 15:37:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id CF32260D67 for ; Wed, 3 Aug 2022 15:37:23 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org CF32260D67 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=jtL61qV/ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQz2N3-z64L3 for ; Wed, 3 Aug 2022 15:37:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7D0E6610B5 Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) by smtp3.osuosl.org (Postfix) with ESMTPS id 7D0E6610B5 for ; Wed, 3 Aug 2022 15:37:22 +0000 (UTC) Received: by mail-vs1-xe2f.google.com with SMTP id m67so10680048vsc.12 for ; Wed, 03 Aug 2022 08:37:22 -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=Yahd4+CyXPV3xrDQEZwlGEvBImo7qBj6/7Rc4Rc2vYE=; b=jtL61qV/gJcEe/o3boegs8PkNUIss0C0fthkRei+odaxyW2hMnq1Z9VGZ3cU06uOjk Aqas6GPSXMpGAEtkpXPATNZaHQJE3Q1yED3kV5Yf8N4O8wWDiJsXw/p9x1zHbfp0Oot1 5N/rH9dEcRc9VS5jGRxpyqOhX5VA0ORjMwvYmvMNVLZlm2fVxlgn5Akn9+0MTKkdNLma IGqNtAKjhlVBpMUAr8oT7pqhtw9u+UILhPVIURRf3KfuP6fUMQg3IeaQFdNOLIdNAunH 8LTOTlnEPZnLrHbMlOSEkKD5K2+dAiavS2Gdl6NTbN0sM2EgZh4jWKMcq/+3La/1V6lo IPNA== 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=Yahd4+CyXPV3xrDQEZwlGEvBImo7qBj6/7Rc4Rc2vYE=; b=JN3rD8zJisfcUmzI6S7EjntpSy5RI2tPX5rWxaNs/98UFQqLwPBujyiTMZ6x3WdiSg uuX2DbEwUiHDDWehUsKe1I0g3jfjU6UdVIY93D8CjHtqiy0quwmKwBWXWX5zyikfiFtI NWrtWYF35THcjU2MvBjDaI2U4j3pIhJc0UG505isMG0B+O/CYiHcLtBBTCjOJj/nUJdo IL9aq/RFqaXqckLsKGDs0QzZYaNoLCyJTKWP+tp8vQRhqEz/nkxpQkPhgz3AxQlSG+eQ 5mHJ6l5hCS5AqzrKWWQ+Owe5F9yL0jg9eM47ujEG/Anz4OE1Obe7o7WRrAtydtSs2j+P 0IVw== X-Gm-Message-State: ACgBeo3JE7zGQNBnP1T22LvqczQEhO1P6lFRV3gFoQFwTSMA1K4gWbgO IFe2z+lAi0C/JXkty2i0cWOgtWLevNL6/zH3lnw= X-Google-Smtp-Source: AA6agR4CTQMgjTOK4sRhkQJoXVQ/CCrb/UJsq3mPMSJu1PVpNnPVSSVtbJHiX/hpKevf5AB98pfCg/4aszU8zjiGEz4= X-Received: by 2002:a67:dd12:0:b0:384:ce1e:1e84 with SMTP id y18-20020a67dd12000000b00384ce1e1e84mr5578389vsj.39.1659541041147; Wed, 03 Aug 2022 08:37:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Wed, 3 Aug 2022 10:37:05 -0500 Message-ID: To: Bram Cohen , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003f73ef05e5580218" X-Mailman-Approved-At: Wed, 03 Aug 2022 16:17:41 +0000 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: Wed, 03 Aug 2022 15:37:24 -0000 --0000000000003f73ef05e5580218 Content-Type: text/plain; charset="UTF-8" @Antoine I very much like your proposal of an open decentralized process for investigating the problem and solution spaces. IRC sounds like a reasonable 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 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 motivating 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 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. 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 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 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 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 > 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 > --0000000000003f73ef05e5580218 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Antoine
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'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

I would imagine=C2= =A0the 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 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't.=C2=A0
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
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 "no tolerance", "some tolerance", "no reservat= ions". Eg it might turn out most people don't have any tolerance f= or infinite recursion, but don't mind non-full enumeration.=C2=A0
=
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.
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=C2=A0fur= ther. This would be the phase where proposals are compared.=C2=A0

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 "bitcoin community consensus". 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

The process doesn'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
=





On Tu= e, Jul 26, 2022 at 11:47 AM Bram Cohen via bitcoin-dev <bitcoin-dev@list= s.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 capabilitie= s in the Bitcoin context ?

Paymen= ts 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)<= /div>

Oracles whose validity can be verified on chain (so tran= sactions can depend on what they say. The oracle has a capability)

Colored coins whose validity can be verified on chai= n (the colored coins have a capability)

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000003f73ef05e5580218--