path: root/c3/c6f11a4320a80f704d793ee0b684a51c2b3038

Return-Path: <decker.christian@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8E997C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 12:56:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 707EC40448
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 12:56:06 +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 D5kc_lir1Cjn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 12:56:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com
 [IPv6:2607:f8b0:4864:20::e32])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 60D51403D0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 12:56:05 +0000 (UTC)
Received: by mail-vs1-xe32.google.com with SMTP id h30so7848443vsq.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 06 Mar 2022 04:56:05 -0800 (PST)
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
 :cc; bh=5gzp/fuSSVe3Ay4oHXJdd2vSBEU/O3PNUqGL+bBHBik=;
 b=JocCYGrE2ywLs3bDyaIPaLU6HisFtr7dbbRkMNnQaPWR5p2attC4YNWgRG/8FEqkU9
 R4TcjvSiL8HMIT8x4ay4ZLhV9K3FgLg61pHrKRYuuijVqBKC4gm70ngm6YXyA/xnaqf1
 DBgAjcYGtbYF5c93JaCdny1ed1+5DCHLAbZoTeKEGarQYU/SGWG/OXPuQQWcbOOFSuYb
 0z8TsvUzjh0r5xwhg8PW4hrt3npzD2S3JRHzZi3rpeLF2+2mGgLOCzi8H4uI1LfyDEUa
 TCdwgKwTIe49R7zh5fPuF8IctT1e6fEEZRjPqxOYdwqLLu7JwVekbpoCHKsepHyk8yFk
 T7Xw==
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:cc;
 bh=5gzp/fuSSVe3Ay4oHXJdd2vSBEU/O3PNUqGL+bBHBik=;
 b=eL3wFCbtqL+Z5/2v8on2I+T4Un5Kwgz9kQxSXVwmOuSeW8Qz1jjN14tESgbsj5FRYF
 HFbtwrPxWBtq3YueUPFG+TkNaobFGJvRGmUf+5My6xgc8ApazfYoGtH6AhQZCIAefZn0
 Ccnw7bzgH7DDmqG1RWCtZhwXOVCJROTCI5zzhJuiUnAOCE4h+HvlzIbf3b0dLhhwd+6n
 VS05m2EZYSmlgidWHrTyK1JpqnbcA3gvhwA1u7DGtAAySIGRiOyzCyCCucJHMIq6F2+o
 QXVPfaM/B2E26CyU6fnBmeeoOcl5hlhm8snontdVW66u2hwvd5A0dnz1eDtKslKqdeIz
 OFXQ==
X-Gm-Message-State: AOAM533X5PyAImnKJD4Tb6xq/6E+XFCmsq8NXvFiKuRNSEyztdUlpYGa
 Wwh6HvC9bJRmL6/SwB9zDhE0R4Ww+ODV5ZVSvxo=
X-Google-Smtp-Source: ABdhPJz/YiDii9f/m+qbhSY6N9rplFmOh0ac1IpuGhj6fSEXiEcl2iW/SSPJAKaBlNVRtjbHv9nJVXLG/MpO3byAGng=
X-Received: by 2002:a05:6102:2cb:b0:320:a581:b9e7 with SMTP id
 h11-20020a05610202cb00b00320a581b9e7mr883786vsh.17.1646571364096; Sun, 06 Mar
 2022 04:56:04 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhgXE9sB-hdzz_Bgz6iEA-M5-Yu2VOn1qRzkaq+DdVsgmw@mail.gmail.com>
 <RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com>
In-Reply-To: <RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Sun, 6 Mar 2022 13:55:53 +0100
Message-ID: <CALxbBHWztmDGraRoJEzE2r8fJgSRh_0RBGiwKWmYaE92QEDzig@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000411e3f05d98c4560"
Subject: Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX,
 Turing Completeness, and other considerations
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: Sun, 06 Mar 2022 12:56:06 -0000

--000000000000411e3f05d98c4560
Content-Type: text/plain; charset="UTF-8"

We'd have to be very carefully with this kind of third-party malleability,
since it'd make transaction pinning trivial without even requiring the
ability to spend one of the outputs (which current CPFP based pinning
attacks require).

Cheers,
Christian

On Sat, 5 Mar 2022, 00:33 ZmnSCPxj via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Jeremy,
>
> Umm `OP_ANNEX` seems boring ....
>
>
> > It seems like one good option is if we just go on and banish the
> OP_ANNEX. Maybe that solves some of this? I sort of think so. It definitely
> seems like we're not supposed to access it via script, given the quote from
> above:
> >
> > Execute the script, according to the applicable script rules[11], using
> the witness stack elements excluding the script s, the control block c, and
> the annex a if present, as initial stack.
> > If we were meant to have it, we would have not nixed it from the stack,
> no? Or would have made the opcode for it as a part of taproot...
> >
> > But recall that the annex is committed to by the signature.
> >
> > So it's only a matter of time till we see some sort of Cat and Schnorr
> Tricks III the Annex Edition that lets you use G cleverly to get the annex
> onto the stack again, and then it's like we had OP_ANNEX all along, or
> without CAT, at least something that we can detect that the value has
> changed and cause this satisfier looping issue somehow.
>
> ... Never mind I take that back.
>
> Hmmm.
>
> Actually if the Annex is supposed to be ***just*** for adding weight to
> the transaction so that we can do something like increase limits on SCRIPT
> execution, then it does *not* have to be covered by any signature.
> It would then be third-party malleable, but suppose we have a "valid"
> transaction on the mempool where the Annex weight is the minimum necessary:
>
> * If a malleated transaction has a too-low Annex, then the malleated
> transaction fails validation and the current transaction stays in the
> mempool.
> * If a malleated transaction has a higher Annex, then the malleated
> transaction has lower feerate than the current transaction and cannot evict
> it from the mempool.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">We&#39;d have to be very carefully with this kind of thir=
d-party malleability, since it&#39;d make transaction pinning trivial witho=
ut even requiring the ability to spend one of the outputs (which current CP=
FP based pinning attacks require).=C2=A0<div dir=3D"auto"><br></div><div di=
r=3D"auto">Cheers,</div><div dir=3D"auto">Christian</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 5 Mar 2022=
, 00:33 ZmnSCPxj via bitcoin-dev, &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">Good morning Jeremy,<br>
<br>
Umm `OP_ANNEX` seems boring ....<br>
<br>
<br>
&gt; It seems like one good option is if we just go on and banish the OP_AN=
NEX. Maybe that solves some of this? I sort of think so. It definitely seem=
s like we&#39;re not supposed to access it via script, given the quote from=
 above:<br>
&gt;<br>
&gt; Execute the script, according to the applicable script rules[11], usin=
g the witness stack elements excluding the script s, the control block c, a=
nd the annex a if present, as initial stack.<br>
&gt; If we were meant to have it, we would have not nixed it from the stack=
, no? Or would have made the opcode for it as a part of taproot...<br>
&gt;<br>
&gt; But recall that the annex is committed=C2=A0to by=C2=A0the signature.<=
br>
&gt;<br>
&gt; So it&#39;s only a matter of time till we see some sort of Cat and Sch=
norr Tricks III the Annex Edition that lets you use G cleverly to get the a=
nnex onto the stack again, and then it&#39;s like we had OP_ANNEX all along=
, or without CAT, at least something that we can detect that the value has =
changed and cause this satisfier looping issue somehow.<br>
<br>
... Never mind I take that back.<br>
<br>
Hmmm.<br>
<br>
Actually if the Annex is supposed to be ***just*** for adding weight to the=
 transaction so that we can do something like increase limits on SCRIPT exe=
cution, then it does *not* have to be covered by any signature.<br>
It would then be third-party malleable, but suppose we have a &quot;valid&q=
uot; transaction on the mempool where the Annex weight is the minimum neces=
sary:<br>
<br>
* If a malleated transaction has a too-low Annex, then the malleated transa=
ction fails validation and the current transaction stays in the mempool.<br=
>
* If a malleated transaction has a higher Annex, then the malleated transac=
tion has lower feerate than the current transaction and cannot evict it fro=
m the mempool.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000411e3f05d98c4560--