diff options
| author | Jeremy Rubin <jeremy.l.rubin@gmail.com> | 2022-04-21 14:08:36 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-21 19:08:52 +0000 |
| commit | 6b69509c274dd027f3e3bffe944174b1f2ca598b (patch) | |
| tree | 924a789c87ffca92b06dce3b99909a472262e8cb | |
| parent | 2e070eee80b8c72644c7a94a8de21a6c78d912e0 (diff) | |
| download | pi-bitcoindev-6b69509c274dd027f3e3bffe944174b1f2ca598b.tar.gz pi-bitcoindev-6b69509c274dd027f3e3bffe944174b1f2ca598b.zip | |
Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
| -rw-r--r-- | 20/6077018a2bcf773aaaffad284d5096813d4225 | 174 |
1 files changed, 174 insertions, 0 deletions
diff --git a/20/6077018a2bcf773aaaffad284d5096813d4225 b/20/6077018a2bcf773aaaffad284d5096813d4225 new file mode 100644 index 000000000..1d4ac5eb4 --- /dev/null +++ b/20/6077018a2bcf773aaaffad284d5096813d4225 @@ -0,0 +1,174 @@ +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'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 '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><= +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.</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-- + |