Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 99E4CC002D for ; Fri, 22 Apr 2022 16:28:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 795A74187E for ; Fri, 22 Apr 2022 16:28:56 +0000 (UTC) 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 Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIEorEwEWy6h for ; Fri, 22 Apr 2022 16:28:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by smtp4.osuosl.org (Postfix) with ESMTPS id 31D9A416FF for ; Fri, 22 Apr 2022 16:28:55 +0000 (UTC) Received: by mail-oi1-x231.google.com with SMTP id q129so9601783oif.4 for ; Fri, 22 Apr 2022 09:28:54 -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; bh=9FYJK0w35QIE9EPfFaIjBaYBcHD5CrA2rkprlEdvNKk=; b=iopnPwvOCc2DHWiV4uQGg4QIrqeUqbf1grxxy/2zGQLQrMcHeQEMGUiMeEPEunKWMu C0R26sUW4r5v0aBPynmxr1FMyjHPAJbMy/HmlAhyTo68xxxTHAEZQuTs+QfTgv8AdyiC +qppENjrWyJgNfJxax6G0FTO//FB7+lAx8DFtbqKSNjIP5BKmh9Cxfloo+jjhpB8b3Gv Mja4UmUt9SxOpq08x/kbAYgr+tJyg5n/XPdl3F6ljHXA30wPD+PXxhsE5hsN89OlM8Ba ipPSTJUpZHU6vKg5j34HlJkjCi/xXfiqFNtftI3m19NzgTk00CQO/i/tTIKdCUnNiBR9 n4/A== 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; bh=9FYJK0w35QIE9EPfFaIjBaYBcHD5CrA2rkprlEdvNKk=; b=gIvLRQ9tpzMT4xBaGjBmKl40dlljtvy3z1ZjHlgybukY05C9G/Xl6+4SWB6azvkAGG 7ARLyTdtS10HUJxWoGXZvkwFyzGE++xc5B/OutYkANK9K1iXBYeUwbyWEzqmLscXT5xD ukaDxRm3kLQ0l76O2a6av24jOhp0wWSSXURQTURIyHdKa8sRd7ALwfXHX4GGiR8csKq6 eYd8EHRoT0Z6YocWDchHmE/YT9kIVekaIyefsBC4WipFWxeg4XC6ttxd3rLFkCRHsocB 0vL/f8b+hnE+gUmkCw1onge7CWgC2JCGmCopJaRLfxM5Irs/DeRWlLGQBF7Ft0jPPQBA fHrA== X-Gm-Message-State: AOAM531R6/ACotkjYXpWXQPZx2+nJx7elrI6OIEgIpAh2TixbepWWF1e 8wDUW0LLmzv8oyQn9MbqHv29x/HHedptKpk3QAg28NybST3Y/Q== X-Google-Smtp-Source: ABdhPJwQzJquFmylYQL10b/auC1oPWbyq9HObqvlVAYPxNwfYl4FzjuKjbXps74ndQ9rzhUT9vixCrWNb3N29oc7Gsk= X-Received: by 2002:a05:6808:1788:b0:322:eae3:5d3c with SMTP id bg8-20020a056808178800b00322eae35d3cmr2735687oib.222.1650644934075; Fri, 22 Apr 2022 09:28:54 -0700 (PDT) MIME-Version: 1.0 References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> In-Reply-To: From: "James O'Beirne" Date: Fri, 22 Apr 2022 12:28:42 -0400 Message-ID: To: Matt Corallo , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000f2298905dd40b85e" Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV 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: Fri, 22 Apr 2022 16:28:56 -0000 --000000000000f2298905dd40b85e Content-Type: text/plain; charset="UTF-8" > There are at least three or four separate covenants designs that have > been posted to this list, and I don't see why we're even remotely > talking about a specific one as something to move forward with at > this point. To my knowledge none of these other proposals (drafts, really) have actual implementations, let alone the many sample usages that exist for CTV. Given that the "covenants" discussion has been ongoing for years now, I think the lack of other serious proposals is indicative of the difficulty inherent in coming up with a preferable alternative to CTV. Each covenant proposal aside from CTV has seemed either abstruse and handwavy to me (TLUV, OP_EVICT) or general to the point of being hard to analyze for safety (CAT) or encourages witness verbosity that seems wasteful (OP_TX[HASH]). CTV is about as simple a covenant system as can be devised - its limits relative to more "general" covenant designs notwithstanding. The level of review around CTV's design is well beyond the other sketches for possible designs that this list has seen. > We could just as well be talking about > TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use > CTV can probably just as easily use those instead - ie this has > nothing to do with "will people use it". This vault design (https://github.com/jamesob/simple-ctv-vault) is a good benchmark for evaluating covenant proposals because it's (i) simple and (ii) has high utility for many users of Bitcoin. I would love to see it implemented in one or all of these alternatives, but I am almost certain no one will do it in the next few months because the implementations, tooling, and in some cases even complete specifications do not exist. Why that is after years of discussion and the utility of covenants being widely appreciated is indicative to me. --000000000000f2298905dd40b85e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There are at least three or four sep= arate covenants designs that have
> been posted to this list, and I d= on't see why we're even remotely
> talking about a specific o= ne as something to move forward with at
> this point.

To my kn= owledge none of these other proposals (drafts, really) have
actual imple= mentations, let alone the many sample usages that exist for
CTV. Given t= hat the "covenants" discussion has been ongoing for years
now,= I think the lack of other serious proposals is indicative of the
diffic= ulty inherent in coming up with a preferable alternative to CTV.

Eac= h covenant proposal aside from CTV has seemed either abstruse and
handwa= vy to me (TLUV, OP_EVICT) or general to the point of
being hard to analy= ze for safety (CAT) or encourages
witness verbosity that seems wasteful = (OP_TX[HASH]).

CTV is about as simple a covenant system as can be de= vised - its limits
relative to more "general" covenant designs= notwithstanding.
The level of review around CTV's design is well be= yond the other
sketches for possible designs that this list has seen.

> We could just as well = be talking about
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone = who is going to use
> CTV can probably just as easily use those inste= ad - ie this has
> nothing to do with "will people use it".=

This vault design (https://github.com/jamesob/simple-ctv-vault)
is a good bench= mark for evaluating covenant proposals because it's (i)
simple and (= ii) has high utility for many users of Bitcoin. I would
love to see it i= mplemented in one or all of these alternatives, but I
am almost certain = no one will do it in the next few months because the
implementations, to= oling, and in some cases even complete
specifica= tions do not exist.

Why that is after years of discussion and the ut= ility of
covenants being widely appreciated is indicative to me.

--000000000000f2298905dd40b85e--