path: root/20/6077018a2bcf773aaaffad284d5096813d4225

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 50C27C002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 19:08:50 +0000 (UTC)
Received: by mail-lf1-x12c.google.com with SMTP id w1so10374268lfa.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <jeremy.l.rubin@gmail.com>
Date: Thu, 21 Apr 2022 14:08:36 -0500
Message-ID: <CAD5xwhjObHqDf=sOFU=RQG-MZ+=s9Qiqo=+WVxtfc7oC_Bzoxw@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <https://twitter.com/JeremyRubin>

--000000000000f942db05dd2ed6cb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I think I&#39;ve discu=
ssed this type of concept previously somewhere but cannot find a link to wh=
ere.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">Largely, I think the following:</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1) This doesn&=
#39;t reduce burden of maintenance and risk of consensus split, it raises i=
t:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)">=C2=A0 =C2=A0A) as we now have =
a bunch of tricky code around reorgs and mempool around the time of rule de=
-activation.</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">=C2=A0 =C2=A0B) we ne=
ed to permanently maintain the rule to validate old blocks fully</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">2) Most of the value=C2=A0of a &#39;temporar=
y soft fork&#39; 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><=
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&#39;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 -&gt; emula=
tor consensus guaranteed -&gt; non signature based opcode.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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=
.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)">Best,</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">Jeremy</div><br clear=3D"all"><div><div dir=
=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_bl=
ank">@JeremyRubin</a><br></div></div></div></div>

--000000000000f942db05dd2ed6cb--