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
|
Return-Path: <rusty@gandalf.ozlabs.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id F17BAC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Nov 2023 12:06:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id C718C7034D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Nov 2023 12:06:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C718C7034D
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=rustcorp.com.au header.i=@rustcorp.com.au
header.a=rsa-sha256 header.s=202305 header.b=TffyOaUR
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.413
X-Spam-Level:
X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=no 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 QWvaVo4gJeK9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Nov 2023 12:06:48 +0000 (UTC)
Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76])
by smtp3.osuosl.org (Postfix) with ESMTPS id 2C92B6FCDD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Nov 2023 12:06:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2C92B6FCDD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rustcorp.com.au;
s=202305; t=1698840401;
bh=K+hh5mlLwvNVvJNuMWsKwYlZpgi57Z/Wl4bM0LBjj4M=;
h=From:To:Subject:In-Reply-To:References:Date:From;
b=TffyOaUR+P8RbWMLqdmJ8dCVdMlugtN50iQ8bZfZMtyxXx5swDxv1OdvSiZT2ZudC
77pPR1DZJ/LTbzb/0L+CMf4+2mIpGr/bGHb1keE4lM5IBFe4avsFv6SPFUL8DKkgxe
kBZleDH3qp3lfcmLUVwNEmIn6eyEepCybVyQDazPKEtkQo5EeYcGB5YJaa/wd0Cylp
m2tIJ/GWBTnxA+knWrfn10wYFl5bBNoCgWlMgFE9+GVLL6MtHeCZyRgofYMqVPGH9i
NhTycNJEhNu8sAHsLwB31xTbIkiDtrZPT6n9TQkDIB/o955ZOc1x6HKf9BLqlZCw8b
uHaLAQkt3dBiw==
Received: by gandalf.ozlabs.org (Postfix, from userid 1011)
id 4SL5Mj1CzZz4x5w; Wed, 1 Nov 2023 23:06:41 +1100 (AEDT)
From: Rusty Russell <rusty@rustcorp.com.au>
To: James O'Beirne <james.obeirne@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPfvXfK7a5To=-n+TOY34KZn2T=Dkf5M1S3eFCNmug8xuE9rTw@mail.gmail.com>
References: <ZTtgFPG4tTeZMnYn@erisian.com.au> <87r0lfz6zp.fsf@rustcorp.com.au>
<CAPfvXfK7a5To=-n+TOY34KZn2T=Dkf5M1S3eFCNmug8xuE9rTw@mail.gmail.com>
Date: Tue, 31 Oct 2023 12:54:27 +1030
Message-ID: <87v8anr0kk.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Wed, 01 Nov 2023 12:06:53 -0000
"James O'Beirne" <james.obeirne@gmail.com> writes:
> 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.
I was thinking from a user POV: the "master" key is the one they keep
super safe in case of emergencies, the "normal" is the delayed spend
key.
OP_VAULT certainly can encapsulate this, but I have yet to do the kind
of thorough review that I'd need to evaluate the various design
decisions.
> 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."
I mean in an ideal world, Bitcoin Script would be powerful enough to
implement vaults, and once a popular use pattern emerged we'd introduce
a new address type, defined to expand to that template. Like P2WPK or
P2PKH.
Sadly, we're not in that world! BIP 345 introduces a number of separate
mechanisms, such as limited script delegation, iteration and amount
arithmetic which are not expressible in Script (ok, amount arithmetic
kind of is, but ick!).
To form a real opinion, I need to consider all these elements, and
whether they should exist inside OP_VAULT, or as separate things.
That's a slow process, sorry :(
> That said, I'm sure some VAULT patterns could be abstracted into the
> miniscript/descriptor layer to good effect.
That would be very interesting, but hard. Volunteers? :)
Cheers,
Rusty.
|
