MIME-Version: 1.0
References: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com>
 <8Uq3KNRWS_WV393lP9wq820PE8KNK0bhQ7u7hMJhIfdfV3-ZhSI-4q9Mw5P_TXivKtyePE2Exha4rso2yi3iNnLJpUpBQ38lAuwG-lQPVUE=@protonmail.com>
 <CAB3F3DsyN_Nj0Fs4LseiwxUE96tFt079qbb0hKBnTBZdyaPcSQ@mail.gmail.com>
 <CAPfvXfK=ykkFWEpRruudLBMt-DaUprFcF=XCJvQ65AFEbo0zpg@mail.gmail.com>
In-Reply-To: <CAPfvXfK=ykkFWEpRruudLBMt-DaUprFcF=XCJvQ65AFEbo0zpg@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Tue, 10 Jan 2023 08:35:04 -0500
Message-ID: <CAPfvXfJSj_CbHW+F4WhrX+NNcEUV14NSKLzRcPR6DqQ0tav5KQ@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000023382605f1e8f4c2"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal
Precedence: list

--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 <recovery-spk-hash> and
<spend-delay> as the OP_VAULT?"

If that output wasn't bare, because the <target-hash> 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 <target-hash> 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, {<OP_UNVAULT <recovery-key> <spend-delay> <target-hash>})

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 <target-hash> 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

<div dir=3D"ltr">Greg explained his suggestion to me off-list, and I think =
it&#39;s a good one. To summarize, consider the normal &quot;output flow&qu=
ot; of an expected vault use:<div><br></div><div>(i) output to be vaulted=
=C2=A0</div><div>=C2=A0 =3D&gt; (ii) OP_VAULT output=C2=A0</div><div>=C2=A0=
 =C2=A0 =3D&gt; (iii) OP_UNVAULT &quot;trigger&quot; output=C2=A0</div><div=
>=C2=A0 =C2=A0 =C2=A0 =3D&gt; (iv) final output</div><div><br></div><div>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=
: &quot;does this OP_UNVAULT have the same &lt;recovery-spk-hash&gt; and &l=
t;spend-delay&gt; as the OP_VAULT?&quot;</div><div><br></div><div>If that o=
utput wasn&#39;t bare, because the &lt;target-hash&gt; is variable at the t=
ime of OP_UNVAULT output creation, the script interpreter would have no way=
 of constructing the expected scriptPubKey.</div><div><br></div><div>Greg&#=
39;s suggestion would allow that output to be any kind of script. He sugges=
ts to put the &lt;target-hash&gt; 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</div><div>=C2=A0=C2=A0</div><div>=C2=A0 tr(NUMS, {&lt;OP_UNVAULT &lt;=
recovery-key&gt; &lt;spend-delay&gt; &lt;target-hash&gt;})</div><div><br></=
div><div>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</div><div><br></div><div>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.</div><div><br></div><div>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 &quot;OP_0 &lt;32 bytes data&g=
t;&quot;, it would use &lt;target-hash&gt; 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 &quot;OP_1 &lt;32 byte=
s data&gt;&quot;, it would do the same process for an expected Taproot-with=
-NUMS output.</div><div><br></div><div>---</div><div><br></div><div>Anyway,=
 sorry if that was more verbose than necessary, but I think it&#39;s a real=
ly great suggestion from Greg. I&#39;ll look at modifying the implementatio=
n accordingly. I&#39;d be curious to hear what others think as well.=C2=A0<=
/div><div><br></div></div>

--00000000000023382605f1e8f4c2--