1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 67214C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2023 16:20:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 41EBC4159D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2023 16:20:47 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 41EBC4159D
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20230601 header.b=Xr6PmTN+
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 smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id IAJ-kVRQ9ent
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2023 16:20:46 +0000 (UTC)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com
[IPv6:2607:f8b0:4864:20::32f])
by smtp4.osuosl.org (Postfix) with ESMTPS id 73B4E41591
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2023 16:20:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 73B4E41591
Received: by mail-ot1-x32f.google.com with SMTP id
46e09a7af769-6ce2eaf7c2bso3225050a34.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2023 09:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1698682845; x=1699287645;
darn=lists.linuxfoundation.org;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=6ih9aw0JbVsSxMz8rnP6vJd/TS3OY51Nr6Th00mQiV0=;
b=Xr6PmTN++n8K9bglFkz0yd6lrfb4m6N1tQFrRPiJJzDo1SZLYMsOlL5jcdQKKjS4tj
Nw6Oc5pbTkENnHsomtjrMiZO/+zIiqIdP8jVKELOU3U/WeacR56y9AgltnLH69Uzxvom
05yaW3XxMyj/58OLnyOW0oZTk8LcbkNwyJ+huiT7kkT4eU00REWaEUowawixlZrrLo98
A9Ll6Gv5STP1tVjUAkQ9eoQbZChxfmdN63OtT0V7VQDrU626ztaB4Q4mnMyHWqil//7O
CIqlS35nEhhNni9nG6ZgtU2K0wgxxEqPxZ0eHPVyk5jk08n9g36vruiMB+UgkZVd4CO2
ciiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698682845; x=1699287645;
h=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=6ih9aw0JbVsSxMz8rnP6vJd/TS3OY51Nr6Th00mQiV0=;
b=pvtiWeW/bzbsmcb+vsbMVhZUoWsFMPHMB9fV7AD1ueua6lGzcD0f97SLeQ4eOOEf86
1fncSn6FtSURt5TofRcA1lIetre9zAwuJAfCwABsiMWDOyhTr5/SWgkhWTxNxjZZeDL0
o25dTdkk+fHMn1092C0Gz5GSOcIunvS6jblMiooLgbO7eP+dwhDjshyiBxWwGm/TICqy
6uUHVOK1tGFbMZOA3oJP170kO9XfATPM2oyx4N9LW6H8BCdnkDgAXnH1rqvlR/uD3nMn
s+sr76yIOypkpq0mty2z0QpJ3bpdLVnKboVC0ALTyANaE3NYmBSKpMOga7cWj12R5yUb
YzlA==
X-Gm-Message-State: AOJu0YxqgK3h6NFZK8Q+Cja5QAbJUAk8A53AkwS01NYGffLthqYDmhvh
AMbFkrAeYoCPx6gmIuX4BwsfqZee5JOayfzRarPl7uUl4k8=
X-Google-Smtp-Source: AGHT+IHf9pFLvWjYoPcgeNKRXu0zQRc2leWyWIgITX2LAQidB/FmabjDeCHp98ANqRn3Qt8IY75axEvsLlKxOQ6v0dw=
X-Received: by 2002:a05:6870:f210:b0:1d7:1533:6869 with SMTP id
t16-20020a056870f21000b001d715336869mr12478869oao.31.1698682843887; Mon, 30
Oct 2023 09:20:43 -0700 (PDT)
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"
X-Mailman-Approved-At: Mon, 30 Oct 2023 16:22:18 +0000
Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
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: Mon, 30 Oct 2023 16:20:47 -0000
--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 <<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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'm confused by what you mean here. I'm pre=
tty sure that BIP-345 VAULT handles the cases that you're outlining, th=
ough I don't understand your terminology -- "master" vs. &qu=
ot;normal", 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 "CHECKLOCKTIMEVERIFY=
wants to be a new address format, not a script opcode."</div><div><br=
></div><div>That said, I'm sure some VAULT patterns could be abstracted=
into the miniscript/descriptor layer to good effect.<br></div></div></div>
--0000000000007efce40608f16b1b--
|
