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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 967C1C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 04:46:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 7139A60F79
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 04:46:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7139A60F79
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham 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 jQc7_QWiQbOU
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 04:46:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9F01160E3B
Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp3.osuosl.org (Postfix) with ESMTPS id 9F01160E3B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 04:46:34 +0000 (UTC)
Received: from [124.181.34.14] (helo=sapphire.erisian.com.au)
by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)
(envelope-from <aj@erisian.com.au>)
id 1pXapp-0003DQ-2Q; Thu, 02 Mar 2023 14:46:31 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 02 Mar 2023 14:46:25 +1000
Date: Thu, 2 Mar 2023 14:46:25 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Greg Sanders <gsanders87@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZAAqIZZO1KK32Th9@erisian.com.au>
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
<CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
X-Spam_score: -1.0
X-Spam_bar: -
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
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: Thu, 02 Mar 2023 04:46:38 -0000
On Wed, Mar 01, 2023 at 10:05:47AM -0500, Greg Sanders via bitcoin-dev wrote:
> Below is a sketch of a replacement for the two opcodes.
I like this! I tried to come up with something along similar lines for
similar reasons, but I think I tried too hard to reduce it to two opcodes
or something and got myself confused.
> `OP_TRIGGER_FORWARD`: Takes exactly three arguments:
> 1) output index to match against (provided at spend time normally)
> 2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)
> (provided at spend time normally)
> 3) spend-delay: value to be forwarded to output given at (1)
I think you could generalise this as follows:
idx .. npush script OP_FORWARD_LEAF_UPDATE
(OP_FLU :) with the behaviour being:
pop script from the stack
pop npush from the stack (error if non-minimal or <0)
pop npush entries from the stack,
prefix script with a minimal push of that entry
pop idx off the stack (error if idx is not a valid output)
calculate the spk corresponding to taking the current
input's spk and replacing the current leaf with the
given script
check the output at idx matches this spk, and the
value from this input accumulates to that output
Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
OP_FORWARD_LEAF_UPDATE`
That's an additional 5 witness bytes, but a much more generic/composable
opcode.
Being able to prefix a script with push opcodes avoids the possibility
of being able to add OP_SUCCESS instructions, so I think this is a fairly
safe way of allowing a TLUV-ish script to be modified, especially compared
to OP_CAT.
I do recognise that it makes it take a variable number of stack elements
though :)
> As the derived tapscript, embedded in a output scriptpubkey of the form:
> `tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block
> from the spending input, swap the inner pubkey for `NUMS`, use
> `EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output
> scriptpubkey doesnt match, fail.
I don't think replacing the internal-public-key makes sense -- if it
was immediately spendable via the keypath before there's no reason for
it not to be immediately spendable now.
> Could save 2 WU having OP_FORWARD_OUTPUTS take the <spend-delay> directly
> as an argument, or keep it more general as I did.
Having OP_FORWARD_OUTPUTS not leave its input on the stack would let
you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.
> Would love to know what you and others think about this direction. I
> apologies for any misunderstandings I have about the current OP_VAULT BIP!
I think the existing OP_VAULT cleverness would work here, allowing you
to spend two inputs to the same output, accumulating their values.
I don't think it quite gives you a way to "refund" values though -- so
that you can take a vault with 3 BTC, start the <delay> wait to spend
1.4 BTC, and then immediately decide to spend an additional 0.8 BTC on
something else, without the 0.8 BTC effectively having a doubled delay.
I think you could fix that with something as simple as an additional
"idx OP_FORWARD_REFUND" opcode, though -- then the restriction is just
that the output at the refund idx has the same sPK as this input, and
the total value of this input is accumulated amongst all the outputs
specified by OP_FORWARD opcodes. (Maybe you need to specify the refund
amount explicitly as well, to keep verification easy)
That would make maybe three new opcodes to cover the "accumulate value
from one or more inputs into specified outputs":
- OP_FORWARD_LEAF_UPDATE --> forward input value to modified spk
- OP_FORWARD_DESTINATION --> forward input value to given spk
- OP_FORWARD_REFUND --> forward part of input value to same spk
along with OP_CTV:
- OP_FORWARD_OUTPUTS --> pay to specific outputs
OP_VAULT's "accumulate value" behaviour here makes the OP_IN_OUT_AMOUNT
things from TLUV more implicit and automatic, which is nice. I think
doing TLUV payment pools wouldn't require much more than the ability to
combine OP_FLU and OP_FDEST in a single script, explicitly specifying
how much value is extracted via OP_FDEST with the rest assigned to OP_FLU.
Cheers,
aj
|
