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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 41E2BC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 14:54:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 0448A612B6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 14:54:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0448A612B6
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=Qs5/hyUm
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mT_GbSeA-vPQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 14:54:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5ED57612B7
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
[IPv6:2a00:1450:4864:20::22a])
by smtp3.osuosl.org (Postfix) with ESMTPS id 5ED57612B7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 14:54:46 +0000 (UTC)
Received: by mail-lj1-x22a.google.com with SMTP id b13so17909646ljf.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 02 Mar 2023 06:54:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=UBIb4OWlomtAWVtFy+zpWmuRnB9tW287jCRlqcKsEks=;
b=Qs5/hyUmV8ONZ2P847enqXsdrBpsa1UqLVdUxo6KpFYw1mVrKpsHgqz6Qd13nDSNhj
6I+/ysk9z9E3rxKrX8PQe7EDCvqmmh11FliVsAimKte4oMKFKD8Vd1IiuhjUtZsGfJ8R
15XFKQ/q53DmpvaMmSmC0naJKvuCp3e1SfPpB9S2eOVdongK1EVB4nQf/OY/v21GFs1B
VtV+F1OR8l4j+IBeVj3kqZtt2KhdMeGIc6a8USJkMeP5iNvvLmxyq+tTyz7z6k0L+ZZp
i3m37gk6+VdREW1oVycR2KHY63/wfq2ucyorlkvGFqR32pAc6RZFLiO1CGJ9ft4OvcPH
9rAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc: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=UBIb4OWlomtAWVtFy+zpWmuRnB9tW287jCRlqcKsEks=;
b=7ED8rVAI3rZRWs5eg53XUCI31tqhci136UdosBLaaUd0PLfgKlOSe66LVc1st27T2/
86ZDYCJZhfhfoRrzh39k/HWqCnxrRd8265Wm591qwQSGbIHG09oMdvv5xwXpl5gcg3Cv
aDLrfVLBTjcH14QxyUJdZQ1pvPfqk5YEZidauRqApFMIde6phQigYqpLsgbD+0fhDDFS
feGWoh2cX5IpPic+ON55pcb3QhylrzmNJWVNH2kfvkWHluIYY5rUQxIMnsFFVea9boRW
ePcYpfVh6TWGdUZWfjI3GxWKQouzTXjiiofQr0LAeMZCYMG7SzzdwdKmfN8ZE/UyboDE
d0Yw==
X-Gm-Message-State: AO0yUKUy5MX/6M2x/hiyiNGhuhAuwuMu/4wt8/ODc4T2xiQQGDcfoGy3
hdiMWIvAZU1C5EJW/fJeQc9B5Em7cDkGPJmxaV0=
X-Google-Smtp-Source: AK7set9qBVEJQbjykzElVbLINQYCgPrlVsB32GX5PNhaSn6mCbGGZkpTzSHmhzV2Bpu2TrTgU27FieY01CDxcvb3H5s=
X-Received: by 2002:a2e:b953:0:b0:295:c4c5:2e6d with SMTP id
19-20020a2eb953000000b00295c4c52e6dmr3287249ljs.2.1677768883787; Thu, 02 Mar
2023 06:54:43 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
<CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
<ZAAqIZZO1KK32Th9@erisian.com.au>
In-Reply-To: <ZAAqIZZO1KK32Th9@erisian.com.au>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 2 Mar 2023 09:54:31 -0500
Message-ID: <CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000555b9b05f5ec0226"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 14:54:58 -0000
--000000000000555b9b05f5ec0226
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Greetings AJ,
Glad I could resurrect the idea!
> 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`
Interesting idea! (I'll let you be the one to scope creep the proposal :) )
To be pedantic, EXPR_TRIGGER would become:
<trigger> <auth> <stuff> <spend-delay> <2> <OP_CSV OP_DROP
OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE
and at spend time the idx and hash are put into the witness stack.
To be clear, <spend-delay> could be embedded in the <script> too, right,
making <2> a <1> in the above? Any reason for one or the other?
Another bonus from this is that you can introduce withdrawal authorization
as well as part of the <script>. Current proposal has no withdrawal
authorization, from what I understand. So each transition in a vault
construct can have authorization, if it desires it.
> I do recognise that it makes it take a variable number of stack elements
though :)
Just when I thought I was out, they pulled me back in.
> 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.
Slavishly following the current proposal was the idea to make sure all
functionality was captured; I agree with this change.
> 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.
Previously setting CSV timeout to 0 would result in it not being
satisfiable, if I'm understanding the suggestion correctly. I suppose this
was a side-effect of having OP_UNVAULT take this value directly. Indeed
with `OP_FORWARD_OUTPUTS` being split out there's not really a reason to
use a 0 value?
> I think the existing OP_VAULT cleverness would work here, allowing you
to spend two inputs to the same output, accumulating their values.
Yes I think batching story should be same hopefully. I am assuming all the
accounting OP_VAULT is doing is being done here. We match against the hash
passed in, and fits into the "deferred checks" IIUC.
> OP_FORWARD_REFUND
Again, to be pedantic EXPR_TRIGGER becomes:
<trigger> <auth> <stuff> <spend-delay> <2> <OP_CSV OP_DROP
OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE OP_FORWARD_REFUND
Resulting in 2 more WU at spend time(for small idx). So *up front*
committing to a refund path, perhaps with value explicitly passed in.
Totally forgot about the refund path; will need to mull the issue over, see
how it interacts with BYOF schemes, etc.
Cheers,
Greg
On Wed, Mar 1, 2023 at 11:46=E2=80=AFPM Anthony Towns <aj@erisian.com.au> w=
rote:
> 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 compare=
d
> 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> direct=
ly
> > 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
>
--000000000000555b9b05f5ec0226
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Greetings AJ,</div><div><br></div><div>Glad I could r=
esurrect=C2=A0the idea!</div><div><br></div><div>> Then instead of `idx =
hash delay OP_TRIGGER_FORWARD` you</div>write `idx hash delay 2 "OP_CS=
V OP_DROP OP_FORWARD_OUTPUTS"<br>OP_FORWARD_LEAF_UPDATE`<div><br></div=
><div>Interesting idea! (I'll let you be the one to scope creep the pro=
posal :) )=C2=A0</div><div><br></div><div>To be pedantic, EXPR_TRIGGER woul=
d become:<br></div><div><br></div><div><trigger> <auth> <stu=
ff> <spend-delay> <2> <OP_CSV OP_DROP OP_FORWARD_OUTPUTS&=
gt; OP_FORWARD_LEAF_UPDATE<br></div><div><br></div><div>and at spend time t=
he idx and hash are put into the witness stack.</div><div><br></div><div>To=
be clear, <spend-delay> could be embedded in the <script> too,=
right, making <2> a <1> in the above? Any reason for one or th=
e other?</div><div><br></div><div>Another bonus from this is that you can i=
ntroduce withdrawal authorization as well as part of the <script>. Cu=
rrent proposal has no withdrawal authorization, from what I understand. So =
each transition in a vault construct can have authorization, if it desires =
it.</div><div><br></div><div>> I do recognise that it makes it take a va=
riable number of stack elements</div>though :)<div><br></div><div>Just when=
I thought=C2=A0I was out, they pulled me back in.<br><div><div><br></div>&=
gt; I don't think replacing the internal-public-key makes sense -- if i=
t<br>was immediately spendable via the keypath before there's no reason=
for<br>it not to be immediately spendable now.<div><br></div><div>Slavishl=
y following the current proposal was the idea to make sure all functionalit=
y was captured; I agree with this change.</div><div><br></div><div>> Hav=
ing OP_FORWARD_OUTPUTS not leave its input on the stack would let</div>you =
move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.<div><br><=
/div><div>Previously setting CSV timeout to 0 would result in it not being =
satisfiable, if I'm understanding the suggestion correctly. I suppose t=
his was a side-effect of having OP_UNVAULT take this value directly. Indeed=
with `<span style=3D"color:rgb(0,0,0);white-space:pre-wrap">OP_FORWARD_OUT=
PUTS` being split out there's not really a reason to use a 0 value?</sp=
an></div><div><font color=3D"#000000"><span style=3D"white-space:pre-wrap">=
<br></span></font></div><div><font color=3D"#000000"><span style=3D"white-s=
pace:pre-wrap">> </span></font>I think the existing OP_VAULT cleverness =
would work here, allowing you<br>to spend two inputs to the same output, ac=
cumulating their values.<br><div><br></div></div></div></div><div>Yes I thi=
nk batching story should be same hopefully. I am assuming all the accountin=
g OP_VAULT is doing is being done here. We match against the hash passed in=
, and fits into the "deferred checks" IIUC.</div><div><br></div><=
div>> OP_FORWARD_REFUND</div><div><br></div><div>Again, to be pedantic E=
XPR_TRIGGER becomes:</div><div><br></div><div><trigger> <auth> =
<stuff> <spend-delay> <2> <OP_CSV OP_DROP OP_FORWARD_O=
UTPUTS> OP_FORWARD_LEAF_UPDATE OP_FORWARD_REFUND<br></div><div><br></div=
><div>Resulting in 2 more WU at spend time(for small idx). So <b>up front</=
b> committing to a refund path, perhaps with value explicitly passed in.=C2=
=A0</div><div><br></div><div>Totally forgot about the refund path; will nee=
d to mull the issue over, see how it interacts with BYOF schemes, etc.</div=
><div><br></div><div>Cheers,</div><div>Greg</div><div><br></div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar=
1, 2023 at 11:46=E2=80=AFPM Anthony Towns <<a href=3D"mailto:aj@erisian=
.com.au" target=3D"_blank">aj@erisian.com.au</a>> wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 01, 2023 at 10:05:4=
7AM -0500, Greg Sanders via bitcoin-dev wrote:<br>
> Below is a sketch of a replacement for the two opcodes. <br>
<br>
I like this! I tried to come up with something along similar lines for<br>
similar reasons, but I think I tried too hard to reduce it to two opcodes<b=
r>
or something and got myself confused.<br>
<br>
> `OP_TRIGGER_FORWARD`: Takes exactly three arguments:<br>
> 1) output index to match against (provided at spend time normally)<br>
> 2) target-outputs-hash: 32 byte hash to be forwarded to output given a=
t (1)<br>
> (provided at spend time normally)<br>
> 3) spend-delay: value to be forwarded to output given at (1)<br>
<br>
I think you could generalise this as follows:<br>
<br>
=C2=A0 =C2=A0idx .. npush script OP_FORWARD_LEAF_UPDATE<br>
<br>
(OP_FLU :) with the behaviour being:<br>
<br>
=C2=A0 =C2=A0pop script from the stack<br>
=C2=A0 =C2=A0pop npush from the stack (error if non-minimal or <0)<br>
=C2=A0 =C2=A0pop npush entries from the stack,<br>
=C2=A0 =C2=A0 =C2=A0prefix script with a minimal push of that entry<br>
=C2=A0 =C2=A0pop idx off the stack (error if idx is not a valid output)<br>
=C2=A0 =C2=A0calculate the spk corresponding to taking the current<br>
=C2=A0 =C2=A0 =C2=A0input's spk and replacing the current leaf with the=
<br>
=C2=A0 =C2=A0 =C2=A0given script<br>
=C2=A0 =C2=A0check the output at idx matches this spk, and the<br>
=C2=A0 =C2=A0 =C2=A0value from this input accumulates to that output<br>
<br>
Then instead of `idx hash delay OP_TRIGGER_FORWARD` you<br>
write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"<br>
OP_FORWARD_LEAF_UPDATE`<br>
<br>
That's an additional 5 witness bytes, but a much more generic/composabl=
e<br>
opcode.<br>
<br>
Being able to prefix a script with push opcodes avoids the possibility<br>
of being able to add OP_SUCCESS instructions, so I think this is a fairly<b=
r>
safe way of allowing a TLUV-ish script to be modified, especially compared<=
br>
to OP_CAT.<br>
<br>
I do recognise that it makes it take a variable number of stack elements<br=
>
though :)<br>
<br>
> As the derived tapscript, embedded in a output scriptpubkey of the for=
m:<br>
> `tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control =
block<br>
> from the spending input, swap the inner pubkey for `NUMS`, use<br>
> `EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the ou=
tput<br>
> scriptpubkey doesnt match, fail.<br>
<br>
I don't think replacing the internal-public-key makes sense -- if it<br=
>
was immediately spendable via the keypath before there's no reason for<=
br>
it not to be immediately spendable now.<br>
<br>
> Could save 2 WU having OP_FORWARD_OUTPUTS take the <spend-delay>=
directly<br>
> as an argument, or keep it more general as I did.<br>
<br>
Having OP_FORWARD_OUTPUTS not leave its input on the stack would let<br>
you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.<br>
<br>
> Would love to know what you and others think about this direction. I<b=
r>
> apologies for any misunderstandings I have about the current OP_VAULT =
BIP!<br>
<br>
I think the existing OP_VAULT cleverness would work here, allowing you<br>
to spend two inputs to the same output, accumulating their values.<br>
<br>
I don't think it quite gives you a way to "refund" values tho=
ugh -- so<br>
that you can take a vault with 3 BTC, start the <delay> wait to spend=
<br>
1.4 BTC, and then immediately decide to spend an additional 0.8 BTC on<br>
something else, without the 0.8 BTC effectively having a doubled delay.<br>
<br>
I think you could fix that with something as simple as an additional<br>
"idx OP_FORWARD_REFUND" opcode, though -- then the restriction is=
just<br>
that the output at the refund idx has the same sPK as this input, and<br>
the total value of this input is accumulated amongst all the outputs<br>
specified by OP_FORWARD opcodes. (Maybe you need to specify the refund<br>
amount explicitly as well, to keep verification easy)<br>
<br>
That would make maybe three new opcodes to cover the "accumulate value=
<br>
from one or more inputs into specified outputs":<br>
<br>
=C2=A0- OP_FORWARD_LEAF_UPDATE --> forward input value to modified spk<b=
r>
=C2=A0- OP_FORWARD_DESTINATION --> forward input value to given spk<br>
=C2=A0- OP_FORWARD_REFUND --> forward part of input value to same spk<br=
>
<br>
along with OP_CTV:<br>
<br>
=C2=A0- OP_FORWARD_OUTPUTS --> pay to specific outputs<br>
<br>
OP_VAULT's "accumulate value" behaviour here makes the OP_IN_=
OUT_AMOUNT<br>
things from TLUV more implicit and automatic, which is nice. I think<br>
doing TLUV payment pools wouldn't require much more than the ability to=
<br>
combine OP_FLU and OP_FDEST in a single script, explicitly specifying<br>
how much value is extracted via OP_FDEST with the rest assigned to OP_FLU.<=
br>
<br>
Cheers,<br>
aj<br>
</blockquote></div>
--000000000000555b9b05f5ec0226--
|