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
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 67972C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Aug 2021 18:12:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 496BA83A6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Aug 2021 18:12:47 +0000 (UTC)
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
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 YelFOFdt5AMr
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Aug 2021 18:12:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
[IPv6:2a00:1450:4864:20::529])
by smtp1.osuosl.org (Postfix) with ESMTPS id 438C483A6B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Aug 2021 18:12:45 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id i6so268970edu.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 03 Aug 2021 11:12:45 -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=2O+1TbaR76RL5z+cKvU/ZFfcH8kmnSir3kto2Xx/5/M=;
b=tzt/iCKh82iNrstjqLxfSukGDrWOHolJH3tcBDDKhcf0CFisLDuAtiQShT3kf6NA8W
RQapQzky2rUXIadqY0Z0zBzQuDKOwgksj9YfKlfI5oPzWay6ecnUFCiCOlRq9SeZV61+
ZXFdbMOOjakg6NoBWESbtjSdJBOUvfTNu391XuzwfFb03eg62DZIOfs5ZDq20xviAXRL
N7021uU1g0WY7rUWbYjY/74h/Q9vjAR8zzzW3N0pL1sktPSujvb8LGZ72pGCupoGGa8Y
lDCDNYLHrKbd5OS6eLJQQODqITvbkTJry5VTUJeHBZTjMOuafTSXLFi1OQIA96fy8RS0
Xlgw==
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=2O+1TbaR76RL5z+cKvU/ZFfcH8kmnSir3kto2Xx/5/M=;
b=uhKIZWCLotPbNFXNXvTf+rggFsHd9CTCTWJ1ZQc6suPMDbk00D8MEG8rFh15ZhspaA
1AHhdkUIm0KGg2C6fuddKJF0wXOvL4jT2XFMJcDexARAxFu5iRvd4AVekiI8mhiT9Miw
kZ4PoqgjbkSNoJ61yrawRXZMzWQUHFCh3vBuBRpVGmwJLRJgM2NkBtmnaQqs31R8jP8k
K8PRuGkAdr67zQtFLxPM+mzXaNBt+tJAg15s0WDpOV4eM6y23G00q0qnGNPh1zi1E7Op
NvBoAT9FtLnFk/iDWwXTzH1f47XfceQTCMpSuW+IAdyBtaeBT6nFrsI5NdmveKP6OIEJ
dZmw==
X-Gm-Message-State: AOAM5334fU/a0Ct3J5xfPXF12zHNvNqRKtfUTA3/n+u22ipeurZ46Gvn
vBiUr/X+N1NptkF2r/SalWchUlo/Gnl0vbysH6I=
X-Google-Smtp-Source: ABdhPJxxwsN7Qm0C2i+GDn/5uvOCEOt7sg2503c2xKxEwf9BRgwrQ2b36PYBJf1JNyJsMgHF1vJAMMamWgO2ABsmRX8=
X-Received: by 2002:a50:fb05:: with SMTP id d5mr26349869edq.5.1628014363393;
Tue, 03 Aug 2021 11:12:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAJ4-pEAETy7_vOez5H32mZLg9gRpRajvoBjZyBT_v=DEqdQJvQ@mail.gmail.com>
<CAJ4-pEAxqvMc89xSp9NXXNwnpJ3NhMqE6p=dRbpYCAB3Gbb14g@mail.gmail.com>
In-Reply-To: <CAJ4-pEAxqvMc89xSp9NXXNwnpJ3NhMqE6p=dRbpYCAB3Gbb14g@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 3 Aug 2021 11:12:28 -0700
Message-ID: <CAGpPWDbidOBqUXHpoteAf50WXeMi392PJZmApyT8h2Gk6n1gKQ@mail.gmail.com>
To: Zac Greenwood <zachgrw@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d1c58405c8aba102"
X-Mailman-Approved-At: Tue, 03 Aug 2021 19:05:14 +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: Tue, 03 Aug 2021 18:12:47 -0000
--000000000000d1c58405c8aba102
Content-Type: text/plain; charset="UTF-8"
> To enable more straightforward validation logic.
> within the current epoch
Ah I see, this is all limited to within a single epoch. I think that
sufficiently limits the window of time in which nodes have to store
information for rate limited outputs. However, I don't see how specifying
block ranges simplifies the logic - wouldn't this complicate the logic with
additional user-specified constraints? It also prevents the output from
being able to be rate limited over the span of multiple epochs, which would
seem to make it a lot more difficult to use for certain types of wallets
(eg cold wallets).
I think I see the logic of your 'remaining' parameter there. If you start
with a single rate-limited input, you can split that into many outputs,
only one of which have a 'remaining' balance. The rest can simply remain
unspendable for the rest of the epoch. That way these things don't need to
be tied together. However, that doesn't solve the problem of 3rd parties
being able to send money into the wallet.
> I don't believe that the marginal added functionality would justify the
increased implementation complexity
Perhaps, but I think there is a lot of benefit in allowing these kinds of
things to operate as similarly as possible to normal transactions, for one
because of usability reasons. If each opcode has its own quirks that are
not intuitively related to their purpose (eg if a rate-limited wallet had
no way to get a receiving address), it would confuse end-users (eg who
wonder how to get a receiving address and how they can ask people to send
money into their wallet) or require a lot of technical complexity in
applications (eg to support something like cooperatively connecting with
their wallet so that a transaction can be made that creates a new
single-output for the wallet). A little complexity in this opcode can save
a lot of external complexity here I think.
> my understanding of Bitcoin is way too low to be able to write a BIP and
do the implementation
You might be able to find people willing to help. I would be willing to
help write the BIP spec. I'm not the right person to help with the
implementation, but perhaps you could find someone else who is. Even if the
BIP isn't adopted, it could be a starting point or inspiration for someone
else to write an improved version.
On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw@gmail.com> wrote:
> [Note: I've moved your reply to the newly started thread]
>
> Hi Billy,
>
> Thank you for your kind and encouraging feedback.
>
> I don't quite understand why you'd want to define a specific span of
>> blocks for the rate limit. Why not just specify the size of the window (in
>> blocks) to rate limit within, and the limit?
>
>
> To enable more straightforward validation logic.
>
> You mentioned change addresses, however, with the parameters you defined,
>> there would be no way to connect together the change address with the
>> original address, meaning they would have completely separate rate limits,
>> which wouldn't work since the change output would ignore the previous rate
>> limit.
>
>
> The rate-limiting parameters must be re-specified for each rate-limited
> input. So, a transaction that has a rate-limited input is only valid if its
> output is itself rate-limited such that it does not violate the
> rate-limiting constraints of its input.
>
> In my thread-starter, I gave the below example of a rate-limited address
> a2 that serves as input for transaction t2:
>
> a2: 99.8 sats at height 800100;
> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>
> Transaction t2:
> Included at block height 800200
> Spend: 400k + fees.
> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>
> Note how transaction t2 re-specifies the rate-limiting parameters.
> Validation must ensure that the re-specified parameters are within bounds,
> i.e., do not allow more spending per epoch than the rate-limiting
> parameters of its input address a2. Re-specifying the rate-limiting
> parameters offers the flexibility to further restrict spending, or to
> disable any additional spending within the current epoch by setting
> a_remaining to zero.
>
> Result:
> Value at destination address: 400k sats;
> Rate limiting params at destination address: none;
> Value at change address a3: 99.4m sats;
> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k,
> a_remaining=100k.
>
> As a design principle I believe it makes sense if the system is able to
> verify the validity of a transaction without having to consider any
> transactions that precede its inputs. As a side-note, doing away with this
> design principle would however enable more sophisticated rate-limiting
> (such as rate-limiting per sliding window instead of rate-limiting per
> epoch having a fixed start and end block), but while at the same time
> reducing the size of per rate-limiting transaction (because it would enable
> specifying the rate-limiting parameters more space-efficiently). To test
> the waters and to keep things relatively simple, I chose not to go into
> this enhanced form of rate-limiting.
>
> I haven't gone into how to process a transaction having multiple
> rate-limited inputs. The easiest way to handle this case is to not allow
> any transaction having more than one rate-limited input. One could imagine
> complex logic to handle transactions having multiple rate-limited inputs by
> creating multiple rate-limited change addresses. However at first glance I
> don't believe that the marginal added functionality would justify the
> increased implementation complexity.
>
> I'd be interested in seeing you write a BIP for this.
>
>
> Thank you, but sadly my understanding of Bitcoin is way too low to be able
> to write a BIP and do the implementation. However I see tremendous value in
> this functionality. Favorable feedback of the list regarding the usefulness
> and the technical feasibility of rate-limiting functionality would of
> course be an encouragement for me to descend further down the rabbit hole.
>
> Zac
>
>
> On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw@gmail.com> wrote:
>
>> [Resubmitting to list with minor edits. My previous submission ended up
>> inside an existing thread, apologies.]
>>
>> Hi list,
>>
>> I'd like to explore whether it is feasible to implement new scripting
>> capabilities in Bitcoin that enable limiting the output amount of a
>> transaction based on the total value of its inputs. In other words, to
>> implement the ability to limit the maximum amount that can be sent from an
>> address.
>>
>> Two use cases come to mind:
>>
>> UC1: enable a user to add additional protection their funds by
>> rate-limiting the amount that they are allowed to send during a certain
>> period (measured in blocks). A typical use case might be a user that
>> intends to hodl their bitcoin, but still wishes to occasionally send small
>> amounts. Rate-limiting avoids an attacker from sweeping all the users'
>> funds in a single transaction, allowing the user to become aware of the
>> theft and intervene to prevent further thefts.
>>
>> UC2: exchanges may wish to rate-limit addresses containing large amounts
>> of bitcoin, adding warm- or hot-wallet functionality to a cold-storage
>> address. This would enable an exchange to drastically reduce the number of
>> times a cold wallet must be accessed with private keys that give access to
>> the full amount.
>>
>> In a typical setup, I'd envision using multisig such that the user has
>> two sets of private keys to their encumbered address (with a "set" of keys
>> meaning "one or more" keys). One set of private keys allows only for
>> sending with rate-limiting restrictions in place, and a second set of
>> private keys allowing for sending any amount without rate-limiting,
>> effectively overriding such restriction.
>>
>> The parameters that define in what way an output is rate-limited might be
>> defined as follows:
>>
>> Param 1: a block height "h0" indicating the first block height of an
>> epoch;
>> Param 2: a block height "h1" indicating the last block height of an epoch;
>> Param 3: an amount "a" in satoshi indicating the maximum amount that is
>> allowed to be sent in any epoch;
>> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum
>> amount that is allowed to be sent within the current epoch.
>>
>> For example, consider an input containing 100m sats (1 BTC) which has
>> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000,
>> 800143, 500k, 500k). These parameters define that the address is
>> rate-limited to sending a maximum of 500k sats in the current epoch that
>> starts at block height 800000 and ends at height 800143 (or about one day
>> ignoring block time variance) and that the full amount of 500k is still
>> sendable. These rate-limiting parameters ensure that it takes at minimum
>> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to
>> spend the full 100m sats. As noted earlier, in a typical setup a user
>> should retain the option to transact the entire amount using a second (set
>> of) private key(s).
>>
>> For rate-limiting to work, any change output created by a transaction
>> from a rate-limited address must itself be rate-limited as well. For
>> instance, expanding on the above example, assume that the user spends 200k
>> sats from a rate-limited address a1 containing 100m sats:
>>
>> Start situation:
>> At block height 800000: rate-limited address a1 is created;
>> Value of a1: 100.0m sats;
>> Rate limiting params of a1: h0=800000, h1=800143, a=500k,
>> a_remaining=500k;
>>
>> Transaction t1:
>> Included at block height 800100;
>> Spend: 200k + fee;
>> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k.
>>
>> Result:
>> Value at destination address: 200k sats;
>> Rate limiting params at destination address: none;
>> Value at change address a2: 99.8m sats;
>> Rate limiting params at change address a2: h0=800000, h1=800143, a=500k,
>> a_remaining=300k.
>>
>> In order to properly enforce rate limiting, the change address must be
>> rate-limited such that the original rate limit of 500k sats per 144 blocks
>> cannot be exceeded. In this example, the change address a2 were given the
>> same rate limiting parameters as the transaction that served as its input.
>> As a result, from block 800100 up until and including block 800143, a
>> maximum amount of 300k sats is allowed to be spent from the change address.
>>
>> Example continued:
>> a2: 99.8 sats at height 800100;
>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>
>> Transaction t2:
>> Included at block height 800200
>> Spend: 400k + fees.
>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>>
>> Result:
>> Value at destination address: 400k sats;
>> Rate limiting params at destination address: none;
>> Value at change address a3: 99.4m sats;
>> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k,
>> a_remaining=100k.
>>
>> Transaction t2 is allowed because it falls within the next epoch (running
>> from 800144 to 800287) so a spend of 400k does not violate the constraint
>> of 500k per epoch.
>>
>> As could be seen, the rate limiting parameters are part of the
>> transaction and chosen by the user (or their wallet). This means that the
>> parameters must be validated to ensure that they do not violate the
>> intended constraints.
>>
>> For instance, this transaction should not be allowed:
>> a2: 99.8 sats at height 800100;
>> Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>
>> Transaction t2a:
>> Included at block height 800200;
>> Spend: 400k + fees;
>> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k.
>>
>> This transaction t2a attempts to shift the epoch forward by 20 blocks
>> such that it starts at 800124 instead of 800144. Shifting the epoch forward
>> like this must not be allowed because it enables spending more that the
>> rate limit allows, which is 500k in any epoch of 144 blocks. It would
>> enable overspending:
>>
>> t1: spend 200k at 800100 (epoch 1: total: 200k);
>> t2a: spend 400k at 800200 (epoch 2: total: 400k);
>> t3a: spend 100k at 800201 (epoch 2: total: 500k);
>> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch
>> 2).
>>
>> Specifying the rate-limiting parameters explicitly at every transaction
>> allows the user to tighten the spending limit by setting tighter limits or
>> for instance by setting a_remainder to 0 if they wish to enforce not
>> spending more during an epoch. A second advantage of explicitly specifying
>> the four rate-limiting parameters with each transaction is that it allows
>> the system to fully validate the transaction without having to consider any
>> previous transactions within an epoch.
>>
>> I will stop here because I would like to gauge interest in this idea
>> first before continuing work on other aspects. Two main pieces of work jump
>> to mind:
>>
>> Define all validations;
>> Describe aggregate behaviour of multiple (rate-limited) inputs, proof
>> that two rate-limited addresses cannot spend more than the sum of their
>> individual limits.
>>
>> Zac
>>
>
--000000000000d1c58405c8aba102
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> To enable more straightforward validation logic.<div>=
> within the current epoch</div><div><br></div><div>Ah I see, this is al=
l limited to within a single epoch. I think that sufficiently limits the wi=
ndow of time in which nodes have to store information for rate limited outp=
uts. However, I don't see how specifying block ranges simplifies the lo=
gic - wouldn't this complicate the logic with additional user-specified=
constraints? It also prevents the output from being able to be rate limite=
d over the span of multiple epochs, which would seem to make it a lot more =
difficult to use for certain types of wallets (eg cold wallets).=C2=A0</div=
><div><br></div><div>I think I see the logic of your 'remaining' pa=
rameter there. If you start with a single rate-limited input, you can split=
that into many outputs, only one of which have a 'remaining' balan=
ce. The rest can simply remain unspendable for the rest of the epoch. That =
way these things don't need to be tied together. However, that doesn=
9;t solve the problem of 3rd parties being able to send money into the wall=
et.=C2=A0</div><div><br></div><div>> I don't believe that the margin=
al added functionality would justify the increased implementation complexit=
y</div><div><br></div><div>Perhaps, but I think there is a lot of benefit i=
n allowing these kinds of things to operate as similarly as possible to nor=
mal transactions, for one because of usability reasons. If each opcode has =
its own quirks that are not intuitively related to their purpose (eg if a r=
ate-limited wallet had no way to get a receiving address), it would confuse=
end-users (eg who wonder how to get a receiving address and how they can a=
sk people to send money into their wallet) or require a lot of technical co=
mplexity in applications (eg to support something like cooperatively connec=
ting with their wallet so that a transaction can be made that creates a new=
single-output=C2=A0for the wallet). A little complexity in this opcode can=
save a lot of external complexity here I think.=C2=A0</div><div><br></div>=
<div>> my understanding of Bitcoin is way too low to be able to write a =
BIP and do the implementation</div><div><br></div><div>You might be able to=
find people willing to help. I would be willing to help write the BIP spec=
. I'm not the right person to help with the implementation, but perhaps=
you could find someone else who is. Even if the BIP isn't adopted, it =
could be a starting point or inspiration for someone else to write an impro=
ved version.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <<a=
href=3D"mailto:zachgrw@gmail.com" target=3D"_blank">zachgrw@gmail.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">[Note: I've moved your reply to the newly started thread]<d=
iv><br></div><div>Hi Billy,<div><br></div><div>Thank you for your kind and =
encouraging feedback.</div><div><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">I don't quite understand why you'd want to define =
a specific span of blocks for the rate limit. Why not just specify the size=
of the window (in blocks) to rate limit within, and the limit?</blockquote=
><div><br></div><div>To enable more straightforward validation logic.</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You mentio=
ned change addresses, however, with the parameters you defined, there would=
be no way to connect together the change address with the original address=
, meaning they would have completely separate rate limits, which wouldn'=
;t work since the change output would ignore the previous rate limit.</bloc=
kquote><div><br></div><div>The rate-limiting parameters must be re-specifie=
d for each rate-limited input. So, a transaction that has a rate-limited in=
put is only valid if its output is itself rate-limited such that it does no=
t violate the rate-limiting constraints of its input.</div><div><br></div><=
div>In my thread-starter, I gave the below example of a rate-limited addres=
s a2 that serves as input for transaction t2:</div><div><br></div><div><div=
>a2: 99.8 sats at height=C2=A0800100;</div><div>Rate-limit params: h0=3D800=
000, h1=3D800143, a=3D500k, a_remaining=3D300k;</div><div><br></div><div>Tr=
ansaction t2:</div><div>Included at block height 800200</div><div>Spend: 40=
0k=C2=A0+ fees.</div><div>Rate-limiting params: h0=3D800144, h1=3D800287, a=
=3D500k, a_remaining=3D100k.<br></div><div><br></div><div>Note how transact=
ion t2 re-specifies the rate-limiting parameters. Validation must ensure th=
at the re-specified parameters are within bounds, i.e., do not allow more s=
pending per epoch than the rate-limiting parameters of its input address a2=
. Re-specifying the rate-limiting parameters offers the flexibility to furt=
her restrict spending, or to disable any additional spending within the cur=
rent epoch by setting a_remaining to zero.</div><div><br></div><div><div>Re=
sult:</div><div>Value at destination address: 400k sats;</div><div>Rate lim=
iting params at destination address: none;</div><div>Value at change addres=
s a3: 99.4m sats;</div><div>Rate limiting params at change address a3: h0=
=3D800144, h1=3D800287, a=3D500k, a_remaining=3D100k.</div></div></div><div=
><br></div><div>As a design principle I believe it makes sense if the syste=
m is able to verify the validity of a transaction without having to conside=
r any transactions that precede its inputs. As a side-note, doing away with=
this design principle would however enable more sophisticated rate-limitin=
g (such as rate-limiting per sliding window instead of rate-limiting per ep=
och having a fixed start and end block), but while at the same time reducin=
g the size of per rate-limiting transaction (because it would enable specif=
ying the rate-limiting parameters more space-efficiently). To test the wate=
rs and to keep things relatively simple, I chose not to go into this enhanc=
ed form of rate-limiting.</div><div><br></div><div>I haven't gone into =
how to process a transaction having multiple rate-limited inputs. The easie=
st way to handle this case is to not allow any transaction having more than=
one rate-limited input. One could imagine complex logic to handle transact=
ions having multiple rate-limited inputs by creating multiple rate-limited =
change addresses. However at first glance I don't believe that the marg=
inal added functionality would justify the increased implementation complex=
ity.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
=C2=A0I'd be interested in seeing you write a BIP for this.</blockquote=
><div><br></div><div>Thank you, but sadly my understanding of Bitcoin is wa=
y too low to be able to write a BIP and do the implementation. However I se=
e tremendous value in this functionality. Favorable feedback of the list re=
garding the usefulness and the technical feasibility of rate-limiting funct=
ionality would of course be an encouragement for me to descend further down=
the rabbit hole.</div><div><br></div><div>Zac</div></div><div><br></div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <<a href=3D"mailto:zachgrw@g=
mail.com" target=3D"_blank">zachgrw@gmail.com</a>> wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>[Resubmi=
tting to list with minor edits. My previous submission ended up inside an e=
xisting thread, apologies.]</div><div><br></div><div>Hi list,</div><div><br=
></div><div>I'd like to explore whether it is feasible to implement new=
scripting capabilities in Bitcoin that enable limiting the output amount o=
f a transaction based on the total value of its inputs. In other words, to =
implement the ability to limit the maximum amount that can be sent from an =
address.</div><div><br></div><div>Two use cases come to mind:</div><div><br=
></div><div>UC1: enable a user to add additional protection their funds by =
rate-limiting the amount that they are allowed to send during a certain per=
iod (measured in blocks). A typical use case might be a user that intends t=
o hodl their bitcoin, but still wishes to occasionally send small amounts. =
Rate-limiting avoids an attacker from sweeping all the users' funds in =
a single transaction, allowing the user to become aware of the theft and in=
tervene to prevent further thefts.</div><div><br></div><div>UC2: exchanges =
may wish to rate-limit addresses containing large amounts of bitcoin, addin=
g warm- or hot-wallet functionality to a cold-storage address. This would e=
nable an exchange to drastically reduce the number of times a cold wallet m=
ust be accessed with private keys that give access to the full amount.</div=
><div><br></div><div>In a typical setup, I'd envision using multisig su=
ch that the user has two sets of private keys to their encumbered address (=
with a "set" of keys meaning "one or more" keys). One s=
et of private keys allows only for sending with rate-limiting restrictions =
in place, and a second set of private keys allowing for sending any amount =
without rate-limiting, effectively overriding such restriction.</div><div><=
br></div><div>The parameters that define in what way an output is rate-limi=
ted might be defined as follows:</div><div><br></div><div>Param 1: a block =
height "h0" indicating the first block height of an epoch;</div><=
div><div>Param 2: a block height "h1" indicating the last block h=
eight of an epoch;</div><div>Param 3: an amount "a" in satoshi in=
dicating the maximum amount that is allowed to be sent in any epoch;<br></d=
iv><div>Param 4: an amount "a_remaining" (in satoshi) indicating =
the maximum amount that is allowed to be sent within the current epoch.</di=
v></div><div><br></div><div>For example, consider an input containing 100m =
sats (1 BTC) which has been rate-limited with parameters (h0, h1, a, a_rema=
ining) of (800000, 800143, 500k, 500k). These parameters define that the ad=
dress is rate-limited to sending a maximum of 500k sats in the current epoc=
h that starts at block height 800000 and ends at height 800143 (or about on=
e day ignoring block time variance) and that the full amount of 500k is sti=
ll sendable. These rate-limiting parameters ensure that it takes at minimum=
100m / 500k =3D 200 transactions and 200 x 144 blocks or about 200 days to=
spend the full 100m sats. As noted earlier, in a typical setup a user shou=
ld retain the option to transact the entire amount using a second (set of) =
private key(s).</div><div><br></div><div>For rate-limiting to work, any cha=
nge output created by a transaction from a rate-limited address must itself=
be rate-limited as well. For instance, expanding on the above example, ass=
ume that the user spends 200k sats from a rate-limited address a1 containin=
g 100m sats:</div><div><br></div><div>Start situation:</div><div>At block h=
eight 800000: rate-limited address a1 is created;</div><div>Value of a1: 10=
0.0m sats;</div><div>Rate limiting params of a1: h0=3D800000, h1=3D800143, =
a=3D500k, a_remaining=3D500k;</div><div><br></div><div>Transaction t1:</div=
><div>Included at block height 800100;</div><div>Spend: 200k + fee;</div><d=
iv>Rate limiting params: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D=
300k.</div><div><br></div><div>Result:</div><div>Value at destination addre=
ss: 200k sats;</div><div>Rate limiting params at destination address: none;=
</div><div>Value at change address a2: 99.8m sats;</div><div>Rate limiting =
params at change address a2: h0=3D800000, h1=3D800143, a=3D500k, a_remainin=
g=3D300k.</div><div><br></div><div>In order to properly enforce rate limiti=
ng, the change address must be rate-limited such that the original rate lim=
it of 500k sats per 144 blocks cannot be exceeded. In this example, the cha=
nge address a2 were given the same rate limiting parameters as the transact=
ion that served as its input. As a result, from block 800100 up until and i=
ncluding block 800143, a maximum amount of 300k sats is allowed to be spent=
from the change address.</div><div><br></div><div>Example continued:</div>=
<div>a2: 99.8 sats at height=C2=A0800100;</div><div>Rate-limit params: h0=
=3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k;</div><div><br></div><=
div>Transaction t2:</div><div>Included at block height 800200</div><div>Spe=
nd: 400k=C2=A0+ fees.</div><div>Rate-limiting params: h0=3D800144, h1=3D800=
287, a=3D500k, a_remaining=3D100k.<br></div><div><br></div><div><div>Result=
:</div><div>Value at destination address: 400k sats;</div><div>Rate limitin=
g params at destination address: none;</div><div>Value at change address a3=
: 99.4m sats;</div><div>Rate limiting params at change address a3: h0=3D800=
144, h1=3D800287, a=3D500k, a_remaining=3D100k.</div><div><br></div><div>Tr=
ansaction t2 is allowed because it falls within the next epoch (running fro=
m 800144 to 800287) so a spend of 400k does not violate the constraint of 5=
00k per epoch.</div><div><br></div><div>As could be seen, the rate limiting=
parameters are part of the transaction and chosen by the user (or their wa=
llet). This means that the parameters must be validated to ensure that they=
do not violate the intended constraints.</div><div><br></div><div>For inst=
ance, this transaction should not be allowed:</div><div><div>a2: 99.8 sats =
at height=C2=A0800100;</div><div>Rate-limit params of a2: h0=3D800000, h1=
=3D800143, a=3D500k, a_remaining=3D300k;</div><div><br></div><div>Transacti=
on t2a:</div><div>Included at block height 800200;</div><div>Spend: 400k=C2=
=A0+ fees;</div><div><div>Rate-limit params: h0=3D800124, h1=3D800267, a=3D=
500k, a_remaining=3D100k.</div><div><br></div></div><div>This transaction t=
2a attempts to shift the epoch forward by 20 blocks such that it starts at =
800124 instead of 800144. Shifting the epoch forward like this must not be =
allowed because it enables spending more that the rate limit allows, which =
is 500k in any epoch of 144 blocks. It would enable overspending:</div></di=
v><div><br></div><div>t1: spend 200k at 800100 (epoch 1: total: 200k);</div=
><div>t2a: spend 400k at 800200 (epoch 2: total: 400k);</div><div>t3a: spen=
d 100k at 800201 (epoch 2: total: 500k);</div><div>t4a: spend 500k at 80026=
8 (epoch 2: total: 1000k, overspending for epoch 2).</div><div><br></div><d=
iv>Specifying the rate-limiting parameters explicitly at every transaction =
allows the user to tighten the spending limit by setting tighter limits or =
for instance by setting a_remainder to 0 if they wish to enforce not spendi=
ng more during an epoch. A second advantage of explicitly specifying the fo=
ur rate-limiting parameters with each transaction is that it allows the sys=
tem to fully validate the transaction without having to consider any previo=
us transactions within an epoch.</div><div><br></div><div>I will stop here =
because I would like to gauge interest in this idea first before continuing=
work on other aspects. Two main pieces of work jump to mind:</div><div><br=
></div><div>Define all validations;</div><div>Describe aggregate behaviour =
of multiple (rate-limited) inputs, proof that two rate-limited addresses ca=
nnot spend more than the sum of their individual limits.</div><font color=
=3D"#888888"><div><br></div><div>Zac</div></font></div></div>
</blockquote></div>
</blockquote></div>
--000000000000d1c58405c8aba102--
|