path: root/9f/60073a8752a1f8e3b20115e63df785ce747fc8

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8EC5FC001E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 Jan 2022 01:45:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 7794560615
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 Jan 2022 01:45:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3TTncFunojYH
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 Jan 2022 01:45:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1B1D96058D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 Jan 2022 01:45:44 +0000 (UTC)
Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com
 [209.85.167.45]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20D1jg4K012081
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 12 Jan 2022 20:45:43 -0500
Received: by mail-lf1-f45.google.com with SMTP id e3so11584779lfc.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Jan 2022 17:45:42 -0800 (PST)
X-Gm-Message-State: AOAM530eRJ3/S1knToklYRrylYdvp2KhejrUfcbeipkKeSvJH0FRBYgp
 H+Q1WQ707VoKFH4mpD1lKdHrpiyjgF9ZJ1E2QNY=
X-Google-Smtp-Source: ABdhPJwf8OTFdMtlyinmeWk+A3sWg2iJEorngLAxweE6QMwIE2tuEHPITGeXy5xXWigMPfgPkMLDD3IHk5eBomxmulI=
X-Received: by 2002:a05:651c:1794:: with SMTP id
 bn20mr1548932ljb.323.1642038341652; 
 Wed, 12 Jan 2022 17:45:41 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhjBjuV_doqWUe4AFxWO0GdiUPkOj7rub8woB57cD4WYcg@mail.gmail.com>
In-Reply-To: <CAD5xwhjBjuV_doqWUe4AFxWO0GdiUPkOj7rub8woB57cD4WYcg@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 12 Jan 2022 17:45:30 -0800
X-Gmail-Original-Message-ID: <CAD5xwhibK4wQGRMvBKjBX_vnFTZpmoNQVWEYkBOF8buJTkqafQ@mail.gmail.com>
Message-ID: <CAD5xwhibK4wQGRMvBKjBX_vnFTZpmoNQVWEYkBOF8buJTkqafQ@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="0000000000000fd38105d56cd8af"
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_PUSH_KEY_* & BIP-118 0x01 Pun
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, 13 Jan 2022 01:45:46 -0000

--0000000000000fd38105d56cd8af
Content-Type: text/plain; charset="UTF-8"

Note:

BIP-118 as-is enables something similar to OP_PUSH_KEY_INTERNAL_TAGGED via
the following script fragment:

witness: <internal pk> <sig>
program: DUP 0x01 CHECKSIG SWAP DUP TOALTSTACK CHECKSIG FROMALTSTACK


It's unclear how useful this might be, since the signature already covers
the transaction.

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Wed, Jan 12, 2022 at 4:35 PM Jeremy <jlrubin@mit.edu> wrote:

> Hi Devs,
>
> Two small transaction introspection opcodes that are worth considering are
> OP_PUSH_KEY_INTERNAL or OP_PUSH_KEY_EXTERNAL which can return the taproot
> key for the current input.
>
> While the internal key could be included in the tree already, and this is
> just a performance improvement, the external key creates a hash cycle and
> is not possible to include directly.
>
> This came up as a potential nicety while looking at how BIP-118 "puns" a
> single 0x01 byte as a key argument to refer to the Internal key for
> compactness. It would be more general if instead of 0x01, there were an
> opcode that actually put the Internal key on the stack.
>
> There is a small incompatibility with BIP-118 with this approach, which is
> that keys are not tagged for APO-enablement. Thus, there should either be a
> version of this opcode for APO tagged or not, or, APO should instead define
> some CheckSig2 which has APO if tagging is still desired. (Or we could
> abandon tagging keys too...)
>
> It might be worth pursuing simplifying APO to use these OP_PUSH_KEY
> opcodes because future plans for more generalized covenant might benefit
> from being able to get the current key off the stack. For example, TLUV
> might be able to be decomposed into simpler (RISC) opcodes for getting the
> internal key, getting the current merkel path, and then manipulating it,
> then tweaking the internal key.
>
> The internal key might be useful for signing in a path not just for APO,
> but also because you might want to sign e.g. a transaction that is
> contingent on a HTLC scriptcode being satisfied. Because it is cheaper to
> use the 0x01 CHECKSIG than doing a separate key (<pk> CHECKSIG), it also
> causes an unintended side effect from APO of incentivizing not using a
> unique key per branch (privacy loss) and incentivizing enabling an APO
> tagged key where one is not required (unless 0x00, as I've noted elsewhere
> is added to the 118 spec as a pun for an untagged key).
>
> Pushing the external key's use is less obvious, but with the development
> of future opcodes it would be helpful for some recursive covenants.
>
> Both opcodes are very design specific -- there's only one choice of what
> data they could push.
>
> Of course, we could keep 118 spec'd as is, and add these PUSH_KEYs later
> if ever desired redundantly with the Checksig puns.
>
> Cheers,
>
> Jeremy
>
>
>
>
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>

--0000000000000fd38105d56cd8af
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:#000000">Note:</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000">BIP-118 as-is=
 enables something similar to OP_PUSH_KEY_INTERNAL_TAGGED via the following=
 script fragment:</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000">witness: &lt;internal pk&gt; &lt;sig&gt;</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000">program: DUP 0x01 CHECKSIG SWAP DUP TOALTSTACK=
=C2=A0CHECKSIG FROMALTSTACK</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
">It&#39;s unclear how useful this might be, since the signature already co=
vers the transaction.</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div>=
<div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signatur=
e"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" targe=
t=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" ta=
rget=3D"_blank"></a></div></div></div><br></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 12, 2022 at 4:35 PM J=
eremy &lt;<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">Hi Devs,</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-siz=
e:small;color:rgb(0,0,0)">Two small transaction introspection opcodes that =
are worth considering are OP_PUSH_KEY_INTERNAL or OP_PUSH_KEY_EXTERNAL whic=
h can return the taproot key for the current input.</div><div class=3D"gmai=
l_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-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">While the i=
nternal key could be included in the tree already, and this is just a perfo=
rmance improvement, the external key creates a hash cycle and is not possib=
le to include directly.</div><div class=3D"gmail_default" style=3D"font-fam=
ily: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-seri=
f;font-size:small;color:rgb(0,0,0)">This came up as a potential nicety whil=
e looking at how BIP-118 &quot;puns&quot; a single 0x01 byte as a key argum=
ent to refer to the Internal key for compactness. It would be more general =
if instead of 0x01, there were an opcode that actually put the Internal key=
 on the stack.</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 clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)">There is a small incompatibility with BIP-118 wi=
th this approach, which is that keys are not tagged for APO-enablement. Thu=
s, there should either be a version of this opcode for APO tagged or not, o=
r, APO should instead define some CheckSig2 which has APO if tagging is sti=
ll desired. (Or we could abandon tagging keys too...)</div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">It might =
be worth pursuing simplifying APO to use these OP_PUSH_KEY opcodes because =
future plans for more generalized covenant might benefit from being able to=
 get the current key off the stack. For example, TLUV might be able to be d=
ecomposed into simpler (RISC) opcodes for getting the internal key, getting=
 the current merkel path, and then manipulating it, then tweaking the inter=
nal key.</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">The internal key might be useful for signing in a path=
 not just for APO, but also because you might want to sign e.g. a transacti=
on that is contingent on a HTLC scriptcode being satisfied. Because it is c=
heaper to use the 0x01 CHECKSIG than doing a separate key (&lt;pk&gt; CHECK=
SIG), it also causes an unintended side effect from APO of incentivizing no=
t using a unique key per branch (privacy loss) and incentivizing enabling a=
n APO tagged key where one is not required (unless 0x00, as I&#39;ve noted =
elsewhere is added to the 118 spec as a pun for an untagged key).</div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">Pushing the external key&#39;s use is less obvious, but with the develop=
ment of future opcodes it would be helpful for some recursive covenants.</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)">Both opcodes are very design specific -- there&#39;s only one cho=
ice of what data they could push.</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,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)">Of course, we could keep 11=
8 spec&#39;d as is, and add these PUSH_KEYs later if ever desired redundant=
ly with the Checksig puns.</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">Cheers,</div><div class=3D"gmail_def=
ault" 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:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy</div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl=
e=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,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily: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-ser=
if;font-size:small;color:rgb(0,0,0)"><br></div><br clear=3D"all"><div><div =
dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRub=
in" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Jeremy=
Rubin" target=3D"_blank"></a></div></div></div></div>
</blockquote></div>

--0000000000000fd38105d56cd8af--