diff options
| author | James O'Beirne <james.obeirne@gmail.com> | 2022-04-22 12:28:42 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-22 16:28:56 +0000 |
| commit | 543892d88315a2f335ee3235b08ecf82017c4a8d (patch) | |
| tree | b180755620dd2887d972a68235f55b92f947aaf1 | |
| parent | 3138aa491c989bddd894c3ab4b700f790331c4c8 (diff) | |
| download | pi-bitcoindev-543892d88315a2f335ee3235b08ecf82017c4a8d.tar.gz pi-bitcoindev-543892d88315a2f335ee3235b08ecf82017c4a8d.zip | |
Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
| -rw-r--r-- | c0/7a29b3dba734dbd5cbbb63166424229fccd4a7 | 164 |
1 files changed, 164 insertions, 0 deletions
diff --git a/c0/7a29b3dba734dbd5cbbb63166424229fccd4a7 b/c0/7a29b3dba734dbd5cbbb63166424229fccd4a7 new file mode 100644 index 000000000..503373278 --- /dev/null +++ b/c0/7a29b3dba734dbd5cbbb63166424229fccd4a7 @@ -0,0 +1,164 @@ +Return-Path: <james.obeirne@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 99E4CC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 22 Apr 2022 16:28:55 +0000 (UTC) +Received: by mail-oi1-x231.google.com with SMTP id q129so9601783oif.4 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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> + <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com> + <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> + <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com> +In-Reply-To: <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com> +From: "James O'Beirne" <james.obeirne@gmail.com> +Date: Fri, 22 Apr 2022 12:28:42 -0400 +Message-ID: <CAPfvXfJe6YHViquT8i+Kq2QUjZDZyUq24nKkJd2a6dYKgygxNQ@mail.gmail.com> +To: Matt Corallo <lf-lists@mattcorallo.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <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: 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 + +<div dir=3D"ltr"><div dir=3D"ltr">> There are at least three or four sep= +arate covenants designs that have<br>> been posted to this list, and I d= +on't see why we're even remotely<br>> talking about a specific o= +ne as something to move forward with at<br>> this point.<br><br>To my kn= +owledge none of these other proposals (drafts, really) have<br>actual imple= +mentations, let alone the many sample usages that exist for<br>CTV. Given t= +hat the "covenants" discussion has been ongoing for years<br>now,= + I think the lack of other serious proposals is indicative of the<br>diffic= +ulty inherent in coming up with a preferable alternative to CTV.<br><br>Eac= +h covenant proposal aside from CTV has seemed either abstruse and<br>handwa= +vy to me (TLUV, OP_EVICT) or general to the point of<br>being hard to analy= +ze for safety (CAT) or encourages<br>witness verbosity that seems wasteful = +(OP_TX[HASH]).<br><br>CTV is about as simple a covenant system as can be de= +vised - its limits<br>relative to more "general" covenant designs= + notwithstanding.<br>The level of review around CTV's design is well be= +yond the other<br>sketches for possible designs that this list has seen.</d= +iv><div dir=3D"ltr"><br> </div><div dir=3D"ltr">> We could just as well = +be talking about<br>> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone = +who is going to use<br>> CTV can probably just as easily use those inste= +ad - ie this has<br>> nothing to do with "will people use it".= +<br><br>This vault design (<a href=3D"https://github.com/jamesob/simple-ctv= +-vault">https://github.com/jamesob/simple-ctv-vault</a>)<br>is a good bench= +mark for evaluating covenant proposals because it's (i)<br>simple and (= +ii) has high utility for many users of Bitcoin. I would<br>love to see it i= +mplemented in one or all of these alternatives, but I<br>am almost certain = +no one will do it in the next few months because the<br>implementations, to= +oling, and in some cases even complete <br></div><div dir=3D"ltr">specifica= +tions do not exist.<br><br>Why that is after years of discussion and the ut= +ility of<br>covenants being widely appreciated is indicative to me.<br></di= +v><br></div> + +--000000000000f2298905dd40b85e-- + |