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
|
Return-Path: <zachgrw@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5514AC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 11:17:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 454A0827AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 11:17:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_FONT_LOW_CONTRAST=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
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 4zE3k3oDa_GL
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 11:17:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com
[IPv6:2607:f8b0:4864:20::d31])
by smtp1.osuosl.org (Postfix) with ESMTPS id 33307827A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 11:17:31 +0000 (UTC)
Received: by mail-io1-xd31.google.com with SMTP id a15so3816399iot.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Aug 2021 04:17:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=BPXK0ZK9sGULr5FnNWo8DRjN9mbpdrVq0RgNxP8MVdc=;
b=AFXJO6/Y1y5hXOrgSwF6IM9u0p/Q5FomlJvAS3ydeQy+9UAhExVskQzHzx1z0c5+zO
8e+7vNhTq8iUUMGnqVMO2yvM5IGSlGaxnyb2tOhz5fqmdY9h3gNk46lkU8suHKKdvI9g
nyl4l2YAtyfFU+fX7GcvpLfIcZgwZieFW8eQx/+REWc32cxmbakUUbtgHpOVVvkMaQQv
ehU+DfnCfzk2godi/54SXHYLtz+LiHsxuAvqSw3UGrKdTUD2+54n2XK94V6tSxEfzMa8
oDDs5zQnjolh1JmH83ItFCVrCYfp7humll61zjRNJqQVq9VHiAbrU5RdiyskDnz4Oqzd
8nnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=BPXK0ZK9sGULr5FnNWo8DRjN9mbpdrVq0RgNxP8MVdc=;
b=b8cePnvcfOJcxykPdZkSUs6qf/sNsi1uqMvpSDWJ2nu1sbuybIBF29Ve2CmrEuyFIv
Bihbeq2iKaFrMGtapLECHm4k9vgE5WahZGL186eNiCBPi3IgfP5IhV56k/FeMT5XZJx9
FBsyprjI5pZRXnPWYsF3amZ3egoeI2mzLD08UeMklLnkPca3EJv0zJF4uIh5iB9S4wrc
DmTemlBnB//+Sn6K3+ULDirPxU6IY8zO7e4lTrtfDMTSyIEJtG21huAl6JRt92kACtLB
dzFDnoRc920wZdCHxKWnEepdScCOJgXIr7/mUrpLgumQBkmN+hL+7VajGMZ0ibOcwb87
HW6A==
X-Gm-Message-State: AOAM531nMI00ye9TQ9YkHl93IJvvK7Ug8xBVXe8vDfmQS8xwWs3+is+Z
jyFSsjBgy1kWslY3nyBntrO1MRyvJ2Z4NIsS6U0=
X-Google-Smtp-Source: ABdhPJye0HHHyyefa3oynrDYackCPZhbIMVguMYWvFCgvWWt+c1cJ9/38ytKehUwB8cuFhULOzTTvVtuoO6wxdumErI=
X-Received: by 2002:a5d:8d1a:: with SMTP id p26mr12758306ioj.178.1629112650148;
Mon, 16 Aug 2021 04:17:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
<CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com>
<CAJ4-pEDWuNfdE4NXkZBsOnuSQ4YOv28YVwGavyiU+FPvpC6y1w@mail.gmail.com>
<CAGpPWDZL6BpzoNa0Qgf-Ux60fyWPjZH=NESkgbhEQO_My=XiAg@mail.gmail.com>
<CAJ4-pEBwdUJ3kg=yb-kWZLoaX5f_2t353K7Tr+dJy+JpAoKTmQ@mail.gmail.com>
<CAGpPWDYMZ+w3VSaLhR68f4WVq7NCUp3SedwW2e8QnRHOgLQqQg@mail.gmail.com>
<CAJ4-pEAT8Rrf7dN9A+F2SUvaRz0-DqgDw45whtZcWCTPeQ+uxA@mail.gmail.com>
<T9dyi_J_ZLwT8hXaxOBlCEhdoB9hsBcvFZX3r1JrtxunUTnFe7wefV6hi3Itw8z84drqAn64ZCJhfSfz7Aw0cqx4Aa8DtN1irvE-d4JPoeE=@protonmail.com>
<CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com>
<1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com>
In-Reply-To: <1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Mon, 16 Aug 2021 13:17:19 +0200
Message-ID: <CAJ4-pECSE=by2ag4QmqrXbX_R0sk6HOL1KH0z2h=+915jaEE6Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000cfb17e05c9ab58f5"
X-Mailman-Approved-At: Mon, 16 Aug 2021 12:07:12 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Exploring: limiting transaction output amount as
a function of total input value
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, 16 Aug 2021 11:17:32 -0000
--000000000000cfb17e05c9ab58f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj,
Thank you for your counterproposal. I fully agree that as a first step we
must establish whether the proposed functionality can be implemented
without making any changes to consensus.
Your counterproposal is understandably more technical in nature because it
explores an implementation on top of Bitcoin as-is. However I feel that for
a fair comparison of the functionality of both proposals a purely
functional description of your proposal is essential.
If I understand your proposal correctly, then I believe there are some
major gaps between yours and mine:
Keys for unrestricted spending: in my proposal, they never have to come
online unless spending more than the limit is desired. In your proposal,
these keys are required to come online in several situations.
Presigning transactions: not required in my proposal. Wouldn=E2=80=99t such
presigning requirement be detrimental for the usability of your proposal?
Does it mean that for instance the amount and window in which the
transaction can be spent is determined at the time of signing? In my
proposal, there is no limit in the number of transactions per window.
Number of windows: limited in your proposal, unlimited in mine.
There are probably additional gaps that I am currently not technically able
to recognize.
I feel that the above gaps are significant enough to state that your
proposal does not meet the basic requirements of my proposal.
Next to consider is whether the gap is acceptable, weighing the effort to
implement the required consensus changes against the effort and feasibility
of implementing your counterproposal.
I feel that your counterproposal has little chance of being implemented
because of the still considerable effort required and the poor result in
functional terms. I also wonder if your proposal is feasible considering
wallet operability.
Considering all the above, I believe that implementing consensus changes in
order to support the proposed functionality would preferable over your
counterproposal.
I acknowledge that a consensus change takes years and is difficult to
achieve, but that should not be any reason to stop exploring the appetite
for the proposed functionality and perhaps start looking at possible
technical solutions.
Zac
On Sat, 14 Aug 2021 at 03:50, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Zac,
>
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your insightful response.
> >
> > Perhaps I should take a step back and take a strictly functional angle.
> Perhaps the list could help me to establish whether the proposed
> functionality is:
> >
> > Desirable;
> > Not already possible;
> > Feasible to implement.
> >
> > The proposed functionality is as follows:
> >
> > The ability to control some coin with two private keys (or two sets of
> private keys) such that spending is limited over time for one private key
> (i.e., it is for instance not possible to spend all coin in a single
> transaction) while spending is unrestricted for the other private key (no
> limits apply). No limits must apply to coin transacted to a third party.
> >
> > Also, it must be possible never having to bring the unrestricted privat=
e
> key online unless more than the limit imposed on the restrictive private
> key is desired to be spent.
> >
> > Less generally, taking the perspective of a hodler: the user must be
> able to keep one key offline and one key online. The offline key allows
> unrestricted spending, the online key is limited in how much it is allowe=
d
> to spend over time.
> >
> > Furthermore, the spending limit must be intuitive. Best candidate I
> believe would be a maximum spend per some fixed number of blocks. For
> instance, the restrictive key may allow a maximum of 100k sats per any
> window of 144 blocks. Ofcourse the user must be able to set these
> parameters freely.
>
> My proposal does not *quite* implement a window.
> However, that is because it uses `nLockTime`.
>
> With the use of `nSequence` in relative-locktime mode, however, it *does*
> implement a window, sort of.
> More specifically, it implements a timeout on spending --- if you spend
> using a presigned transaction (which creates an unencumbered
> specific-valued TXO that can be arbitrarily spent with your online keyset=
)
> then you cannot get another "batch" of funds until the `nSequence` relati=
ve
> locktime passes.
> However, this *does* implement a window that limits a maximum value
> spendable per any window of the relative timelock you select.
>
> The disadvantage is that `nSequence` use is a lot more obvious and
> discernible than `nLockTime` use.
> Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and tha=
t
> is a good cover for `nLockTime` transactions.
> I believe Dave Harding proposed that wallets should also use, at random,
> (say 50-50) `nSequence`-in-relative-locktime-mode as an alternate
> anti-fee-sniping mechanism.
> This alternate anti-fee-sniping would help cover `nSequence` use.
>
> Note that my proposal does impose a maximum limit on the number of window=
s.
> With `nSequence`-in-relative-locktime-mode the limit is the number of
> times that the online keyset can spend.
> After spending that many windows, the offline keyset has to be put back
> online to generate a new set of transactions.
>
> It has the massive massive advantage that you can implement it today
> without any consensus change, and I think you can expect that consensus
> change will take a LONG time (xref SegWit, Taproot).
>
> Certainly the functionality is desirable.
> But it seems it can be implemented with Bitcoin today.
>
> Regards,
> ZmnSCPxj
>
>
--000000000000cfb17e05c9ab58f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Hi=C2=A0<span style=3D"color:rgb(0,0,0)">ZmnSCPxj,</span>=
</div><div dir=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><=
div dir=3D"auto"><span style=3D"color:rgb(0,0,0)">Thank you for your counte=
rproposal. I fully agree that as a first step we must establish whether the=
proposed functionality can be implemented without making any changes to co=
nsensus.</span></div><div dir=3D"auto"><span style=3D"color:rgb(0,0,0)"><br=
></span></div><div style=3D"background-color:rgba(0,0,0,0)!important;border=
-color:rgb(255,255,255)!important;color:rgb(255,255,255)!important" dir=3D"=
auto"><font style=3D"color:rgb(0,0,0)">Your counterproposal is understandab=
ly more technical in nature because it explores an implementation on top of=
Bitcoin as-is. However I feel that for a fair comparison of the functional=
ity of both proposals a purely functional description of your proposal is e=
ssential.</font></div><div style=3D"background-color:rgba(0,0,0,0);border-c=
olor:rgb(255,255,255)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)"><br></=
font></div><div style=3D"background-color:rgba(0,0,0,0);border-color:rgb(25=
5,255,255)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">If I understand y=
our proposal correctly, then I believe there are some major gaps between yo=
urs and mine:</font></div><div style=3D"background-color:rgba(0,0,0,0);bord=
er-color:rgb(255,255,255)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)"><b=
r></font></div><div style=3D"background-color:rgba(0,0,0,0)!important;borde=
r-color:rgb(32,33,36)!important;color:rgb(255,255,255)!important" dir=3D"au=
to"><font style=3D"color:rgb(0,0,0)">Keys for unrestricted spending: in my =
proposal, they never have to come online unless spending more than the limi=
t is desired. In your proposal, these keys are required to come online in s=
everal situations.</font></div><div style=3D"background-color:rgba(0,0,0,0)=
;border-color:rgb(32,33,36)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">=
<br></font></div><div style=3D"background-color:rgba(0,0,0,0)!important;bor=
der-color:rgb(222,223,227)!important;color:rgb(255,255,255)!important" dir=
=3D"auto"><font style=3D"color:rgb(0,0,0)">Presigning transactions: not req=
uired in my proposal. Wouldn=E2=80=99t such presigning requirement be detri=
mental for the usability of your proposal? Does it mean that for instance t=
he amount and window in which the transaction can be spent is determined at=
the time of signing? In my proposal, there is no limit in the number of tr=
ansactions per window.</font></div><div dir=3D"auto"><span style=3D"color:r=
gb(0,0,0)"><br></span></div><div style=3D"background-color:rgba(0,0,0,0)!im=
portant;border-color:rgb(255,255,255)!important;color:rgb(255,255,255)!impo=
rtant" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">Number of windows: lim=
ited in your proposal, unlimited in mine.</font></div><div dir=3D"auto"><sp=
an style=3D"color:rgb(0,0,0)"><br></span></div><div style=3D"background-col=
or:rgba(0,0,0,0)!important;border-color:rgb(255,255,255)!important;color:rg=
b(255,255,255)!important" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">The=
re are probably additional gaps that I am currently not technically able to=
recognize.</font></div><div style=3D"background-color:rgba(0,0,0,0);border=
-color:rgb(255,255,255)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)"><br>=
</font></div><div style=3D"background-color:rgba(0,0,0,0);border-color:rgb(=
255,255,255)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">I feel that the=
above gaps are significant enough to state that your proposal does not mee=
t the basic requirements of my proposal.</font></div><div style=3D"backgrou=
nd-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir=3D"auto"><font st=
yle=3D"color:rgb(0,0,0)"><br></font></div><div style=3D"background-color:rg=
ba(0,0,0,0)!important;border-color:rgb(32,33,36)!important;color:rgb(255,25=
5,255)!important" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">Next to con=
sider is whether the gap is acceptable, weighing the effort to implement th=
e required consensus changes against the effort and feasibility of implemen=
ting your counterproposal.</font></div><div style=3D"background-color:rgba(=
0,0,0,0);border-color:rgb(32,33,36)" dir=3D"auto"><font style=3D"color:rgb(=
0,0,0)"><br></font></div><div style=3D"background-color:rgba(0,0,0,0);borde=
r-color:rgb(32,33,36)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">I feel=
that your counterproposal has little chance of being implemented because o=
f the still considerable effort required and the poor result in functional =
terms. I also wonder if your proposal is feasible considering wallet operab=
ility.</font></div><div style=3D"background-color:rgba(0,0,0,0);border-colo=
r:rgb(32,33,36)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)"><br></font><=
/div><div style=3D"background-color:rgba(0,0,0,0);border-color:rgb(32,33,36=
)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">Considering all the above,=
I believe that implementing consensus changes in order to support the prop=
osed functionality would preferable =C2=A0over your counterproposal.</font>=
</div><div style=3D"background-color:rgba(0,0,0,0);border-color:rgb(32,33,3=
6)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)"><br></font></div><div sty=
le=3D"background-color:rgba(0,0,0,0);border-color:rgb(32,33,36)" dir=3D"aut=
o"><font style=3D"color:rgb(0,0,0)">I acknowledge that a consensus change t=
akes years and is difficult to achieve, but that should not be any reason t=
o stop exploring the appetite for the proposed functionality and perhaps st=
art looking at possible technical solutions.</font></div><div style=3D"back=
ground-color:rgba(0,0,0,0);border-color:rgb(32,33,36)" dir=3D"auto"><font s=
tyle=3D"color:rgb(0,0,0)"><br></font></div><div style=3D"background-color:r=
gba(0,0,0,0);border-color:rgb(32,33,36)" dir=3D"auto"><font style=3D"color:=
rgb(0,0,0)">Zac</font></div><div style=3D"background-color:rgba(0,0,0,0);bo=
rder-color:rgb(32,33,36)" dir=3D"auto"><br></div><div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 14 Aug 2021 at 03:5=
0, ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonm=
ail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padd=
ing-left:1ex;border-left-color:rgb(204,204,204)">Good morning Zac,<br>
<br>
<br>
> Hi=C2=A0ZmnSCPxj,<br>
><br>
> Thank you for your insightful response.<br>
><br>
> Perhaps I should take a step back and take a strictly functional angle=
. Perhaps the list could help me to establish whether=C2=A0the proposed fun=
ctionality is:<br>
><br>
> Desirable;<br>
> Not already possible;<br>
> Feasible to implement.<br>
><br>
> The proposed functionality is as follows:<br>
><br>
> The ability to control some coin with two private keys (or two sets of=
private keys) such that spending is limited over time for one private key =
(i.e., it is for instance not possible to spend all coin in a single transa=
ction) while spending is unrestricted for the other private key (no limits =
apply). No limits must apply to coin transacted to a third party.<br>
><br>
> Also, it must be possible never having to bring the unrestricted priva=
te key online unless more than the limit imposed on the restrictive private=
key is desired to be spent.<br>
><br>
> Less generally, taking the perspective of a hodler: the user must be a=
ble to keep one key offline and one key online. The offline key allows unre=
stricted spending, the online key is limited in how much it is allowed to s=
pend over time.<br>
><br>
> Furthermore, the spending limit must be intuitive. Best candidate I be=
lieve would be a maximum spend per some fixed number of blocks. For instanc=
e, the restrictive key may allow a maximum of 100k sats per any window of 1=
44 blocks. Ofcourse the user must be able to set these parameters freely.<b=
r>
<br>
My proposal does not *quite* implement a window.<br>
However, that is because it uses `nLockTime`.<br>
<br>
With the use of `nSequence` in relative-locktime mode, however, it *does* i=
mplement a window, sort of.<br>
More specifically, it implements a timeout on spending --- if you spend usi=
ng a presigned transaction (which creates an unencumbered specific-valued T=
XO that can be arbitrarily spent with your online keyset) then you cannot g=
et another "batch" of funds until the `nSequence` relative lockti=
me passes.<br>
However, this *does* implement a window that limits a maximum value spendab=
le per any window of the relative timelock you select.<br>
<br>
The disadvantage is that `nSequence` use is a lot more obvious and discerni=
ble than `nLockTime` use.<br>
Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that =
is a good cover for `nLockTime` transactions.<br>
I believe Dave Harding proposed that wallets should also use, at random, (s=
ay 50-50) `nSequence`-in-relative-locktime-mode as an alternate anti-fee-sn=
iping mechanism.<br>
This alternate anti-fee-sniping would help cover `nSequence` use.<br>
<br>
Note that my proposal does impose a maximum limit on the number of windows.=
<br>
With `nSequence`-in-relative-locktime-mode the limit is the number of times=
that the online keyset can spend.<br>
After spending that many windows, the offline keyset has to be put back onl=
ine to generate a new set of transactions.<br>
<br>
It has the massive massive advantage that you can implement it today withou=
t any consensus change, and I think you can expect that consensus change wi=
ll take a LONG time (xref SegWit, Taproot).<br>
<br>
Certainly the functionality is desirable.<br>
But it seems it can be implemented with Bitcoin today.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div></div>
--000000000000cfb17e05c9ab58f5--
|