MIME-Version: 1.0
References: <ZTtgFPG4tTeZMnYn@erisian.com.au> <87r0lfz6zp.fsf@rustcorp.com.au>
In-Reply-To: <87r0lfz6zp.fsf@rustcorp.com.au>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Mon, 30 Oct 2023 12:20:32 -0400
Message-ID: <CAPfvXfK7a5To=-n+TOY34KZn2T=Dkf5M1S3eFCNmug8xuE9rTw@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007efce40608f16b1b"
Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
Precedence: list

--0000000000007efce40608f16b1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 28, 2023 at 12:51=E2=80=AFAM Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> But AFAICT there are multiple perfectly reasonable variants of vaults,
> too.  One would be:
>
> 1. master key can do anything
> 2. OR normal key can send back to vault addr without delay
> 3. OR normal key can do anything else after a delay.
>
> Another would be:
> 1. normal key can send to P2WPKH(master)
> 2. OR normal key can send to P2WPKH(normal key) after a delay.
>

I'm confused by what you mean here. I'm pretty sure that BIP-345 VAULT
handles the cases that you're outlining, though I don't understand your
terminology -- "master" vs. "normal", and why we are caring about P2WPKH
vs. anything else. Using the OP_VAULT* codes can be done in an arbitrary
arrangement of tapleaves, facilitating any number of vaultish spending
conditions, alongside other non-VAULT leaves.

Well, I found the vault BIP really hard to understand.  I think it wants
> to be a new address format, not script opcodes.
>

Again confused here. This is like saying "CHECKLOCKTIMEVERIFY wants to be a
new address format, not a script opcode."

That said, I'm sure some VAULT patterns could be abstracted into the
miniscript/descriptor layer to good effect.

--0000000000007efce40608f16b1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Oct 28, 2023 at 12:51=E2=80=AFAM =
Rusty Russell via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>
But AFAICT there are multiple perfectly reasonable variants of vaults,<br>
too.=C2=A0 One would be:<br>
<br>
1. master key can do anything<br>
2. OR normal key can send back to vault addr without delay<br>
3. OR normal key can do anything else after a delay.<br>
<br>
Another would be:<br>
1. normal key can send to P2WPKH(master)<br>
2. OR normal key can send to P2WPKH(normal key) after a delay.<br></blockqu=
ote><div><br></div><div>I&#39;m confused by what you mean here. I&#39;m pre=
tty sure that BIP-345 VAULT handles the cases that you&#39;re outlining, th=
ough  I don&#39;t understand your terminology -- &quot;master&quot; vs. &qu=
ot;normal&quot;, and why we are caring about P2WPKH vs. anything else. Usin=
g the OP_VAULT* codes can be done in an arbitrary arrangement of tapleaves,=
 facilitating any number of vaultish spending conditions, alongside other n=
on-VAULT leaves.<br></div><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">
Well, I found the vault BIP really hard to understand.=C2=A0 I think it wan=
ts<br>
to be a new address format, not script opcodes.<br></blockquote><div><br></=
div><div>Again confused here. This is like saying &quot;CHECKLOCKTIMEVERIFY=
 wants to be a new address format, not a script opcode.&quot;</div><div><br=
></div><div>That said, I&#39;m sure some VAULT patterns could be abstracted=
 into the miniscript/descriptor layer to good effect.<br></div></div></div>

--0000000000007efce40608f16b1b--