From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 50C27C002C for ; Thu, 21 Apr 2022 19:08:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 2706B41977 for ; Thu, 21 Apr 2022 19:08:52 +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 m2K9DJbecAVg for ; Thu, 21 Apr 2022 19:08:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by smtp4.osuosl.org (Postfix) with ESMTPS id A71B641974 for ; Thu, 21 Apr 2022 19:08:50 +0000 (UTC) Received: by mail-lf1-x12c.google.com with SMTP id w1so10374268lfa.4 for ; Thu, 21 Apr 2022 12:08:50 -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=vCrxwjIeWT7H4dSEqN43khksITYR+RDogqLwhbMBcAs=; b=JKZxg7dBrcVfxyuXYrvhcV8l692lC4/jZBE5Ukveti8RiiUz3wQfgj2vPT6G4G+Lvr TBpLWiSkXkWtvI1BcsUkG8AO54M6bik5pA692UJaLEu3yOtklPlHbzZFle/nvX0KyFJh p9rONZWLF9mugC7/UWdUvQjsSYglGQzRYucFovMOIgE0JJpBAKhm/bUULODUDyQXvX/o tvS84ZzSrVeY714XQDecu3yry9/uTLZbAoKj+jyOAd5IbP5BdefjK9k/NjhdB1rUWyVN nV4+AOGmYuNBOAPQywp7EAhu6gzDsOikC0ALyArMyzYG9G+Rq2SeQliua9B0xSwppJOx m+dQ== 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=vCrxwjIeWT7H4dSEqN43khksITYR+RDogqLwhbMBcAs=; b=PJZRUfgMXAVj51LLLtTSoiO+RibbymhUUtyd3m0yBd74UP2+hX4HJdaU7ntcB9jgDJ PWCtRgIHRS740AtIEju4UeGeoCKA3MEo/XgkCl4aDoaoIZ0NNfL+YJVhdg+v82hLVm7M 6Csf8n77+4/FutNp9GF1LjEQo2PwZQguc7QpbOjF0r1R/c6vNzniL7PQRH5E9z1mCOo/ fRh/66I+WSdkBM2TZn+B6p6eyaVsMjt7N1obj3gOD3Vo9n60D0EQAcqz6IxxNvLdsGC4 nmw8PVaOcxkSxyCDjcbVkSkuOfqfbN46y8Kyk6FJ3uCCnQn3MOaXfTFGwZmbx6PaVupg o+Vw== X-Gm-Message-State: AOAM533E35B9Y8Xw3spCHgPN7PK9NY0ZbZp5NFzx9HxHIwsxzp7xFyrO mEnKZhK/GB7obKeL/41XK48S2nxrzt+zutnzoSic37oI X-Google-Smtp-Source: ABdhPJwEDov+PJihocuaoGL0YnIPaV44mIESMMfK5Eu4xo2UJtaMw83I+1DX3jrs6m1U07zLKSVHnA9UyGXqWRf4Y4A= X-Received: by 2002:a05:6512:1112:b0:471:a77b:abe6 with SMTP id l18-20020a056512111200b00471a77babe6mr611029lfg.262.1650568128446; Thu, 21 Apr 2022 12:08:48 -0700 (PDT) MIME-Version: 1.0 References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> From: Jeremy Rubin Date: Thu, 21 Apr 2022 14:08:36 -0500 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000f942db05dd2ed6cb" 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: Thu, 21 Apr 2022 19:08:52 -0000 --000000000000f942db05dd2ed6cb Content-Type: text/plain; charset="UTF-8" I think I've discussed this type of concept previously somewhere but cannot find a link to where. Largely, I think the following: 1) This doesn't reduce burden of maintenance and risk of consensus split, it raises it: A) as we now have a bunch of tricky code around reorgs and mempool around the time of rule de-activation. B) we need to permanently maintain the rule to validate old blocks fully 2) Most of the value of a 'temporary soft fork' is more safely captured by use of a CTV emulation server / servers, which has a more graceful degradation property of the servers simply shutting down and not authorizing new contracts, but funds not being vulnerable to theft. The model here is trust, as opposed to a timeout. 2A) The way I implemented the oracles in CTV was such that, if we wanted to, we could actually soft-fork the rules for the oracle's keys such that they would *have to* only sign CTV-valid transactions (e.g., the keys could be made public). Pretty weird model, but cool that it would enable after-the-fact trust model improvements. This could be generalized for any opcode to be emulator -> emulator consensus guaranteed -> non signature based opcode. Although I will note that I like the spirit of this, and encourage thinking more creatively about other ways to have temporary forks in Bitcoin like this. Best, Jeremy -- @JeremyRubin --000000000000f942db05dd2ed6cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think I've discu= ssed this type of concept previously somewhere but cannot find a link to wh= ere.

Largely, I think the following:

1) This doesn&= #39;t reduce burden of maintenance and risk of consensus split, it raises i= t:
=C2=A0 =C2=A0A) as we now have = a bunch of tricky code around reorgs and mempool around the time of rule de= -activation.
=C2=A0 =C2=A0B) we ne= ed to permanently maintain the rule to validate old blocks fully
2) Most of the value=C2=A0of a 'temporar= y soft fork' is more safely captured by use of a CTV emulation server /= servers, which has a more graceful degradation property of the servers sim= ply shutting down and not authorizing new contracts, but funds not being vu= lnerable to theft. The model here is trust, as opposed to a timeout.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:rgb(0,0,0)">=C2=A0 =C2=A02A) The way I implemented t= he oracles in CTV was such that, if we wanted to, we could actually soft-fo= rk the rules for the oracle's keys such that they would *have to* only = sign CTV-valid transactions (e.g., the keys could be made public). Pretty w= eird model, but cool that it would enable after-the-fact trust model improv= ements. This could be generalized for any opcode to be emulator -> emula= tor consensus guaranteed -> non signature based opcode.

Alt= hough I will note that I like the spirit of this, and encourage thinking mo= re creatively about other ways to have temporary forks in Bitcoin like this= .

Best,

Jeremy
--000000000000f942db05dd2ed6cb--