path: root/57/4fb2a83c68df2bb7940f77cdceb843c30dcb6b

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 8B8FCC001E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 Jan 2022 00:35:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 66CBD60615
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 Jan 2022 00:35:35 +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 pfe9cyfZrFz6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 Jan 2022 00:35:34 +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 15AAC6058D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 Jan 2022 00:35:33 +0000 (UTC)
Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com
 [209.85.167.52]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20D0ZVLE022943
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 12 Jan 2022 19:35:32 -0500
Received: by mail-lf1-f52.google.com with SMTP id j11so14007457lfg.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Jan 2022 16:35:32 -0800 (PST)
X-Gm-Message-State: AOAM530ii91oDBeS+2msIbMNOR1IYcSBWzlHvNivtQiN1cRlRIlTJrVA
 cc0rKIh/dkzrhI3vDmaDOjzAt7+Ky1otbLhMf/Y=
X-Google-Smtp-Source: ABdhPJzTIGorvfmDqNf/bT8jcbgJmid8F4H34ZfSt6l98bg6Za8qhc7JT4LRO4rLlBminEuvGvcOhdNOtNEVGdt/REY=
X-Received: by 2002:a05:651c:1794:: with SMTP id
 bn20mr1405797ljb.323.1642034130617; 
 Wed, 12 Jan 2022 16:35:30 -0800 (PST)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 12 Jan 2022 16:35:19 -0800
X-Gmail-Original-Message-ID: <CAD5xwhjBjuV_doqWUe4AFxWO0GdiUPkOj7rub8woB57cD4WYcg@mail.gmail.com>
Message-ID: <CAD5xwhjBjuV_doqWUe4AFxWO0GdiUPkOj7rub8woB57cD4WYcg@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000108a0305d56bddd2"
Subject: [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 00:35:35 -0000

--000000000000108a0305d56bddd2
Content-Type: text/plain; charset="UTF-8"

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>

--000000000000108a0305d56bddd2
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">Hi Devs,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Two small=
 transaction introspection opcodes that are worth considering are OP_PUSH_K=
EY_INTERNAL or OP_PUSH_KEY_EXTERNAL which can return the taproot key for th=
e current input.</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">While the internal key could be included in the tree=
 already, and this is just a performance improvement, the external key crea=
tes a hash cycle and is not possible to include directly.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">This came=
 up as a potential nicety while looking at how BIP-118 &quot;puns&quot; a s=
ingle 0x01 byte as a key argument to refer to the Internal key for compactn=
ess. 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_defau=
lt" 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,h=
elvetica,sans-serif;font-size:small;color:#000000">There is a small incompa=
tibility 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 h=
as APO if tagging is still desired. (Or we could abandon tagging keys too..=
.)</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">It might be worth pursuing simplifying APO to use these OP_PUSH_KE=
Y opcodes because future plans for more generalized covenant might benefit =
from being able to get the current key off the stack. For example, TLUV mig=
ht be able to be decomposed into simpler (RISC) opcodes for getting the int=
ernal key, getting the current merkel path, and then manipulating it, then =
tweaking the internal key.</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-seri=
f;font-size:small;color:#000000">The internal key might be useful for signi=
ng 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. Bec=
ause it is cheaper to use the 0x01 CHECKSIG than doing a separate key (&lt;=
pk&gt; CHECKSIG), it also causes an unintended side effect from APO of ince=
ntivizing not using a unique key per branch (privacy loss) and incentivizin=
g enabling an 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,s=
ans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">Pushing the external key&#39;s use is less obvious, but with the d=
evelopment of future opcodes it would be helpful for some recursive covenan=
ts.</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_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000">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:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">Of course, we could keep 118 spec=
&#39;d as is, and add these PUSH_KEYs later if ever desired redundantly wit=
h the Checksig puns.</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000">Cheers,</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-serif;font-size:small;color:#000000">Jeremy</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></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=
"><br></div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signatur=
e" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"htt=
ps://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"=
https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div></=
div>

--000000000000108a0305d56bddd2--