From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 68117C002D for ; Tue, 10 Jan 2023 13:35:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 507B3405D7 for ; Tue, 10 Jan 2023 13:35:16 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 507B3405D7 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=pFbhE5C7 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 Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tDn68memZUW for ; Tue, 10 Jan 2023 13:35:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 606824014B Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) by smtp2.osuosl.org (Postfix) with ESMTPS id 606824014B for ; Tue, 10 Jan 2023 13:35:15 +0000 (UTC) Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-14fb7fdb977so12093543fac.12 for ; Tue, 10 Jan 2023 05:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fDG1iVXjnYX2iutfAZfya2oVCjhZrkvGCevQsz0+Cvo=; b=pFbhE5C7YEVh+SjK83T51lAMlucKyKXGjt0EfYgsd7BJJj3HU7E8jlTKEAwyjDA1hG wUsLg8ZcT799ifVCRXal+j7EeGWf0LA9AVJb5+IhDZHGVVNqaXFgsYcn7gqaiAcL+PcU kRQwwGmc5qP1BnpHmCzWBZ0qyvumFGHqUZMtDAWcGplsMsztsgwBOFalAdykXyrJIaYA ZctpUfLgJyGfIQMzD/8Du/2Jt3Qr/YNFWkOSX4uDnaVcpmsFsnZ0tZ7Vbizc2er1QnmD KtGazjJGNgL1E4cDLtsD0MOVEcUhcQE4+ADrh1KdRlifcIvaodjceey4uK1rz5gWb9jO oH8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fDG1iVXjnYX2iutfAZfya2oVCjhZrkvGCevQsz0+Cvo=; b=UNvv4w99jCNPwsdsCIAAVlNOnQzbeXB0oEPDAiH2KCTIbuiGMYFtP0bHONPU1uPTyB rNrGoYjmQhI3IGjN/4yF/yTv3a94Q/Q87RFp3gWn6gGHFOzngxsVeLXHktlC0vp2aN3h 4MO1dV63HngThR43CE2oYmEo+ivbAWIA0vN8z1u4COrRh5r2NzZyc3Kj87kosg+ilwBd Lkn7ZOZpVLoic8ri4t7+tgiy/LmM6ULnPkLklcFhp/A8TGcmFI4thP2LLPp+Z9waX4Ht 3O0XF5QjOEglnfEnAhP88l+v4AL9XyKQs1BjrGHDl9ilV3D6424vaTPpLJSEg+JTbIeA ppUg== X-Gm-Message-State: AFqh2koQ7avllqkPi7S3VMa+5UZFDyqqvUxj5moHxqg88W/ydkg4Yj0Q hL+WhdLGh5vA0jVyMresRNq1lHzWivraGLg2XcFxo67H X-Google-Smtp-Source: AMrXdXsthZg7ahebG+NuPH1QDuGtPAX9n1ojP697gkNyoK6ZVfXJFfmHAb8bbtqOfTXxEzzXIk8gUATwECNe2jCrDRo= X-Received: by 2002:a05:6870:4b8d:b0:14f:d35e:b7fa with SMTP id lx13-20020a0568704b8d00b0014fd35eb7famr4548601oab.222.1673357714206; Tue, 10 Jan 2023 05:35:14 -0800 (PST) MIME-Version: 1.0 References: <8Uq3KNRWS_WV393lP9wq820PE8KNK0bhQ7u7hMJhIfdfV3-ZhSI-4q9Mw5P_TXivKtyePE2Exha4rso2yi3iNnLJpUpBQ38lAuwG-lQPVUE=@protonmail.com> In-Reply-To: From: "James O'Beirne" Date: Tue, 10 Jan 2023 08:35:04 -0500 Message-ID: To: Greg Sanders Content-Type: multipart/alternative; boundary="00000000000023382605f1e8f4c2" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal 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: Tue, 10 Jan 2023 13:35:16 -0000 --00000000000023382605f1e8f4c2 Content-Type: text/plain; charset="UTF-8" Greg explained his suggestion to me off-list, and I think it's a good one. To summarize, consider the normal "output flow" of an expected vault use: (i) output to be vaulted => (ii) OP_VAULT output => (iii) OP_UNVAULT "trigger" output => (iv) final output In my existing draft implementation, all outputs aside from (iii), the OP_UNVAULT trigger, can be P2TR or P2WSH. In other words, those outputs can hide their true script until spend. In my draft, the OP_UNVAULT trigger had to be bare so that the script interpreter could inspect part of it for validity: "does this OP_UNVAULT have the same and as the OP_VAULT?" If that output wasn't bare, because the is variable at the time of OP_UNVAULT output creation, the script interpreter would have no way of constructing the expected scriptPubKey. Greg's suggestion would allow that output to be any kind of script. He suggests to put the onto the witness stack when spending the OP_VAULT output (and creating the OP_UNVAULT output). If we did that, the script interpreter could e.g. use a NUMS point (i.e. a publicly known point with no usable private key) to construct a Taproot configuration that looks like tr(NUMS, { }) and check if the scriptPubKey of the proposed OP_UNVAULT output matches that. This would allow all outputs in vault lifecycles to be P2TR, for example, which would conceal the operation of the vault - a very nice feature! This would also allow the OP_VAULT/OP_UNVAULT opcodes to be implemented as Taproot-only OP_SUCCESSx opcodes, if that was decided to be preferable. The problem is how to (and whether to) enable something similar for witness v0 outputs. For example, if we want the (ii) and (iii) output scripts to live behind P2WSH. One (kind of hacky) option to enable this is to have the script interpreter construct the expected OP_UNVAULT scriptPubKey on the basis of what witness version it sees. For example, if it sees "OP_0 <32 bytes data>", it would use on the witness stack to construct a fitting P2WSH scriptPubKey that is compatible with the OP_VAULT being spent, and then match against that. But if it detects "OP_1 <32 bytes data>", it would do the same process for an expected Taproot-with-NUMS output. --- Anyway, sorry if that was more verbose than necessary, but I think it's a really great suggestion from Greg. I'll look at modifying the implementation accordingly. I'd be curious to hear what others think as well. --00000000000023382605f1e8f4c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg explained his suggestion to me off-list, and I think = it's a good one. To summarize, consider the normal "output flow&qu= ot; of an expected vault use:

(i) output to be vaulted= =C2=A0
=C2=A0 =3D> (ii) OP_VAULT output=C2=A0
=C2=A0= =C2=A0 =3D> (iii) OP_UNVAULT "trigger" output=C2=A0
=C2=A0 =C2=A0 =C2=A0 =3D> (iv) final output

In= my existing draft implementation, all outputs aside from (iii), the OP_UNV= AULT trigger, can be P2TR or P2WSH. In other words, those outputs can hide = their true script until spend. In my draft, the OP_UNVAULT trigger had to b= e bare so that the script interpreter could inspect part of it for validity= : "does this OP_UNVAULT have the same <recovery-spk-hash> and &l= t;spend-delay> as the OP_VAULT?"

If that o= utput wasn't bare, because the <target-hash> is variable at the t= ime of OP_UNVAULT output creation, the script interpreter would have no way= of constructing the expected scriptPubKey.

Greg&#= 39;s suggestion would allow that output to be any kind of script. He sugges= ts to put the <target-hash> onto the witness stack when spending the = OP_VAULT output (and creating the OP_UNVAULT output). If we did that, the s= cript interpreter could e.g. use a NUMS point (i.e. a publicly known point = with no usable private key) to construct a Taproot configuration that looks= like
=C2=A0=C2=A0
=C2=A0 tr(NUMS, {<OP_UNVAULT <= recovery-key> <spend-delay> <target-hash>})

and check if the scriptPubKey of the proposed OP_UNVAULT output ma= tches that. This would allow all outputs in vault lifecycles to be P2TR, fo= r example, which would conceal the operation of the vault - a very nice fea= ture!=C2=A0

This would also allow the OP_VAULT/OP_= UNVAULT opcodes to be implemented as Taproot-only OP_SUCCESSx opcodes, if t= hat was decided to be preferable.

The problem is h= ow to (and whether to) enable something similar for witness v0 outputs. For= example, if we want the (ii) and (iii) output scripts to live behind P2WSH= . One (kind of hacky) option to enable this is to have the script interpret= er construct the expected OP_UNVAULT scriptPubKey on the basis of what witn= ess version it sees. For example, if it sees "OP_0 <32 bytes data&g= t;", it would use <target-hash> on the witness stack to construc= t a fitting P2WSH scriptPubKey that is compatible with the OP_VAULT being s= pent, and then match against that. But if it detects "OP_1 <32 byte= s data>", it would do the same process for an expected Taproot-with= -NUMS output.

---

Anyway,= sorry if that was more verbose than necessary, but I think it's a real= ly great suggestion from Greg. I'll look at modifying the implementatio= n accordingly. I'd be curious to hear what others think as well.=C2=A0<= /div>

--00000000000023382605f1e8f4c2--