From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8EC5FC001E for ; 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 ; 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 ; 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 ; 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 ; Wed, 12 Jan 2022 20:45:43 -0500 Received: by mail-lf1-f45.google.com with SMTP id e3so11584779lfc.9 for ; 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: In-Reply-To: From: Jeremy Date: Wed, 12 Jan 2022 17:45:30 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="0000000000000fd38105d56cd8af" Cc: Bitcoin development mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 On Wed, Jan 12, 2022 at 4:35 PM Jeremy 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 ( 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 > > --0000000000000fd38105d56cd8af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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= =C2=A0CHECKSIG FROMALTSTACK


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



On Wed, Jan 12, 2022 at 4:35 PM J= eremy <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 whic= h can return the taproot key for the current input.

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.

=
This came up as a potential nicety whil= e looking at how BIP-118 "puns" 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.

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...)

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.

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 (<pk> 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'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 develop= ment of future opcodes it would be helpful for some recursive covenants.

Both opcodes are very design specific -- there's only one cho= ice of what data they could push.

Of course, we could keep 11= 8 spec'd as is, and add these PUSH_KEYs later if ever desired redundant= ly with the Checksig puns.

Cheers,

Jeremy







--0000000000000fd38105d56cd8af--