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
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
|
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 81888C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 00:41:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7ADFC831A2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 00:41:33 +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 W2DWA2b211O7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 00:41:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
[IPv6:2a00:1450:4864:20::530])
by smtp1.osuosl.org (Postfix) with ESMTPS id 32730831A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 00:41:30 +0000 (UTC)
Received: by mail-ed1-x530.google.com with SMTP id t1so989211edd.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 09 Aug 2021 17:41:29 -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=43zEbuhZI9piceCG+LHaPKDxrzWT87wQtHL8cLM68IU=;
b=YKlZCWQ+fT+HBNEVBkk6gzrj3IgmYX5oNXKETFNIQAL7tZpjfcoHFBCJpVS7Ea+CbJ
4SYiBFdAVNzLhOqSpFkueRG7wuivW4D7+eTfdjvMRah19b5YPJ1LLlA5qw2OlVaT/jQ4
fX7peeujrhdEMdfQv1QKSW1WfH42iaE6RTtL22ag+KigNd3W+tYn/KRCI2qXGsn3hZmU
aAJN4HWHirP9cv/1TsZDQkok0YHC7tS2IUbAF6JpIOaOnB+MgkiEH9sELuR9sS+VZoAz
6xjbrjuE09U6KpA/+VPV1O8KLJtoAzdU+bl3ZOZcQpwt0ICbJKmpidKWMohlD76WStgB
NuNg==
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=43zEbuhZI9piceCG+LHaPKDxrzWT87wQtHL8cLM68IU=;
b=axyBNN9xbutnznm+vM1n00wvqeAYiSanWtkMJWP938Bq1ksV/r5ohKkQTjGNzOv7QC
9KHdqceN/+bKerRsGRcUIx6XvcxWBDE9CkD/ENoiyEKZajBf3tdz+xGjYqsLXF9Av3qY
jxSZiNXYQQIzgCV0sbHued/+u3KLgwOEuJzU+wi1O4FSMp1+62LJuBiPHTMhrYB8zTSp
cGSnDc5m+qZPl+ZhbFZlUd3ptd3V1h8XESRbcDSwPhhyLIOSrdsMXkV8q7Tg2hh+XMQG
t8WsBK6qEEkBqFruvZG66sa5ijIXAoaHdmoLE+8oTIycWSHYLY3tVMAplzODzPtzAFJt
9D+Q==
X-Gm-Message-State: AOAM533ajFbi33c0kRhnBQ8utw2O10DGoHCn87T5AIWPK2UN9OCCroXp
32kNFnsGp0z4WWI6qlkNt5amiwXSdyQEcrzxlMU=
X-Google-Smtp-Source: ABdhPJwfxu8IkovdJC0QB0KpzANTExYA0BsXRfktOs5lNaBcDgdiFKDVWHF2ljTW8qPbZKIpyuLHIEXDiGInTEihWoI=
X-Received: by 2002:a05:6402:19a:: with SMTP id
r26mr1412882edv.230.1628556088193;
Mon, 09 Aug 2021 17:41:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAJ4-pEAETy7_vOez5H32mZLg9gRpRajvoBjZyBT_v=DEqdQJvQ@mail.gmail.com>
<CAJ4-pEAxqvMc89xSp9NXXNwnpJ3NhMqE6p=dRbpYCAB3Gbb14g@mail.gmail.com>
<CAGpPWDbidOBqUXHpoteAf50WXeMi392PJZmApyT8h2Gk6n1gKQ@mail.gmail.com>
<CAJ4-pEAi-ooVMvJmeXhrS9J6-JVQ1jxy1On1NTQYpOSD49cbrw@mail.gmail.com>
<CAGpPWDZNrPT9Li_neNOr3BDGdusMorWjFodNPo6YqNC3SDaf3w@mail.gmail.com>
<CAJ4-pEByppCRQwKqkPaAMMLiqw0ZcCECuSjGZjeW529BKMAhRg@mail.gmail.com>
In-Reply-To: <CAJ4-pEByppCRQwKqkPaAMMLiqw0ZcCECuSjGZjeW529BKMAhRg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 9 Aug 2021 17:41:12 -0700
Message-ID: <CAGpPWDY5-pUx8+Ne9VzL-=XeE8uTH7djzgngXxghKpMZOPGzoQ@mail.gmail.com>
To: Zac Greenwood <zachgrw@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000022355a05c929c3e7"
X-Mailman-Approved-At: Tue, 10 Aug 2021 10:13:00 +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, 10 Aug 2021 00:41:33 -0000
--00000000000022355a05c929c3e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> By explicitly specifying the start and end block of an epoch, the user
has more flexibility in shifting the epoch
Ok I see. I think I understand your proposal better now. If the output is
spent within the range epochStart - epochEnd, the limit holds, if it is
spent outside that range the change output must also have a range of the
same length (or shorter?). So you want there to be the ability for the user
to precisely define the length and starting block of the
rate-limiting-period (epoch). I'd say it'd be clearer to specify the window
length and the starting block in that case. The same semantics can be kept.
> This would require the system to bookkeep how much was spent since the
first rate-limited output
Yes, for the length of the epoch, after which the bookkeeping can be
discarded/reset until a new transaction is sent. Your proposal also
requires bookkeeping tho - it needs to store the 'remain' value with the
UTXO as well because its not efficient to go back and re-execute the script
just to grab that value.
> using an address as input for a transaction will always spends the full
amount at that address
Using a UTXO will spend the full UTXO. The address may contain many UTXOs.
I'm not suggesting that a change address isn't needed - I'm suggesting that
the *same* address be used as the change address for the change output. Eg
consider the following UTXO info:
Address X: rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats)
* UTXO 1: 100k sats, 50k spent by ancestor inputs since epochStart 800100
* UTXO 2: 200k sats, 10k spent since epochStart
When sending a transaction using UTXO 2, a node would look up the list of
UTXOs in Address X, add up the amount spent since epochStart (60k) and
ensure that at most 40k is going to an address that isn't address X. So a
valid transaction might look like:
Input: UTXO 2
Output 1: 30k -> Address A
Output 2: 170k -> Address X
On Thu, Aug 5, 2021 at 7:22 AM Zac Greenwood <zachgrw@gmail.com> wrote:
> Hi Billy,
>
> > It sounds like you're proposing an opcode
>
> No. I don=E2=80=99t have enough knowledge of Bitcoin to be able to tell h=
ow (and
> if) rate-limiting can be implemented as I suggested. I am not able to
> reason about opcodes, so I kept my description at a more functional level=
.
>
> > I still don't understand why its useful to specify those as absolute
> block heights
>
> I feel that this a rather uninteresting data representation aspect that=
=E2=80=99s
> not worth going back and forth about. Sure, specifying the length of the
> epoch may also be an option, although at the price of giving up some
> functionality, and without much if any gains.
>
> By explicitly specifying the start and end block of an epoch, the user ha=
s
> more flexibility in shifting the epoch (using alternate values for
> epochStart and epochEnd) and simultaneously increasing the length of an
> epoch. These seem rather exotic features, but there=E2=80=99s no harm in =
retaining
> them.
>
> > if you have a UTXO encumbered by rateLimit(epochStart =3D 800100,
> epochEnd =3D 800200, limit =3D 100k, remain =3D 100k), what happens if yo=
u don't
> spend that UTXO before block 800200?
>
> The rate limit remains in place. So if this UTXO is spent in block 900000=
,
> then at most 100k may be spent. Also, the new epoch must be at least 100
> blocks and remain must correctly account for the actual amount spent.
>
> > This is how I'd imagine creating an opcode like this:
>
> > rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats)
>
> This would require the system to bookkeep how much was spent since the
> first rate-limited output. It is a more intuitive way of rate-limiting bu=
t
> it may be much more difficult to implement, which is why I went with the
> epoch-based rate limiting solution. In terms of functionality, I believe
> the two solutions are nearly identical for all practical purposes.
>
> Your next section confuses me. As I understand it, using an address as
> input for a transaction will always spends the full amount at that addres=
s.
> That=E2=80=99s why change addresses are required, no? If Bitcoin were abl=
e to pay
> exact amounts then there wouldn=E2=80=99t be any need for change outputs.
>
> Zac
>
>
> On Thu, 5 Aug 2021 at 08:39, Billy Tetrud <billy.tetrud@gmail.com> wrote:
>
>> > A maximum amount is allowed to be spent within EVERY epoch.
>>
>> It sounds like you're proposing an opcode that takes in epochStart and
>> epochEnd as parameters. I still don't understand why its useful to speci=
fy
>> those as absolute block heights. You mentioned that this enables more
>> straightforward validation logic, but I don't see how. Eg, if you have a
>> UTXO encumbered by rateLimit(epochStart =3D 800100, epochEnd =3D 800200,=
limit
>> =3D 100k, remain =3D 100k), what happens if you don't spend that UTXO be=
fore
>> block 800200? Is the output no longer rate limited then? Or is the opcod=
e
>> calculating 800200-800100 =3D 100 and applying a rate limit for the next
>> epoch? If the first, then the UTXO must be spent within one epoch to rem=
ain
>> rate limited. If the second, then it seems nearly identical to simply
>> specifying window=3D100 as a parameter instead of epochStart and epochEn=
d.
>>
>> > then there must be only a single (rate-limited) output
>>
>> This rule would make transactions tricky if you're sending money into
>> someone else's wallet that may be rate limited. If the requirement is th=
at
>> only you yourself can send money into a rate limited wallet, then this
>> point is moot but it would be ideal to not have such a requirement.
>>
>> This is how I'd imagine creating an opcode like this:
>>
>> rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats)
>>
>> This would define that the epoch is 1 day's worth of blocks. This would
>> evenly divide bitcoin's retarget period and so each window would start a=
nd
>> end at those dividing lines (eg the first 144 blocks of the retargetting
>> period, then the second, then the third, etc).
>>
>> When this output is spent, it ensures that there's a maximum of 100k sat=
s
>> is sent to addresses other than the originating address. It also records
>> the amount spent in the current 144 block window for that address (eg by
>> simply recording the already-spent amount on the resulting UTXO and havi=
ng
>> an index that allows looking up UTXOs by address and adding them up). Th=
at
>> way, when any output from that address is spent again, if a new 144 bloc=
k
>> window has started, the limit is reset, but if its still within the same
>> window, the already-spent amounts for UTXOs from that address are added =
up
>> and subtracted from the limit, and that number is the remaining limit a
>> subsequent transaction needs to adhere to.
>>
>> This way, 3rd party could send transactions into an address like this,
>> and multiple outputs can be combined and used to spend to arbitrary outp=
uts
>> (up to the rate limit of course).
>>
>> On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood <zachgrw@gmail.com> wrote:
>>
>>> > Ah I see, this is all limited to within a single epoch.
>>>
>>> No, that wouldn't be useful. A maximum amount is allowed to be spent
>>> within EVERY epoch.
>>>
>>> Consider an epoch length of 100 blocks with a spend limit of 200k per
>>> epoch. The following is allowed:
>>>
>>> epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for
>>> epoch1: 80k;
>>> epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining
>>> for epoch1: 20k;
>>> epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for
>>> epoch2: 40k.
>>>
>>> Since the limit pertains to each individual epoch, it is allowed to
>>> spend up to the full limit at the start of any new epoch. In this examp=
le,
>>> the spending was as follows:
>>>
>>> 800140: 120k
>>> 800195: 60k
>>> 800201: 160k.
>>>
>>> Note that in a span of 62 blocks a total of 340k sats was spent. This
>>> may seem to violate the 200k limit per 100 blocks, but this is the resu=
lt
>>> of using a per-epoch limit. This allows a maximum of 400k to be spent i=
n 2
>>> blocks llke so: 200k in the last block of an epoch and another 200k in =
the
>>> first block of the next epoch. However this is inconsequential for the
>>> intended goal of rate-limiting which is to enable small spends over tim=
e
>>> from a large amount and to prevent theft of a large amount with a singl=
e
>>> transaction.
>>>
>>> To explain the proposed design more clearly, I have renamed the params
>>> as follows:
>>>
>>> epochStart: block height of first block of the current epoch (was: h0);
>>> epochEnd: block height of last block of the current epoch (was: h1);
>>> limit: the maximum total amount allowed to be spent within the current
>>> epoch (was: a);
>>> remain: the remaining amount allowed to be spent within the current
>>> epoch (was: a_remaining);
>>>
>>> Also, to illustrate that the params are specific to a transaction, I
>>> will hence precede the param with the transaction name like so:
>>> tx8_limit, tx31c_remain, tx42z_epochStart, ... etc.
>>>
>>> For simplicity, only transactions with no more than one rate-limited
>>> input are considered, and with no more than two outputs: one rate-limit=
ed
>>> change output, and a normal (not rate-limited) output.
>>>
>>> Normally, a simple transaction generates two outputs: one for a payment
>>> to a third party and one for the change address. Again for simplicity, =
we
>>> demand that a transaction which introduces rate-limiting must have only=
a
>>> single, rate-limited output. The validation rule might be: if a transac=
tion
>>> has rate-limiting params and none of its inputs are rate-limited, then
>>> there must be only a single (rate-limited) output (and no second or cha=
nge
>>> output).
>>>
>>> Consider rate limiting transactions tx1 having one or more normal (non
>>> rate-limited) inputs:
>>>
>>> tx1 gets included at block height 800004;
>>> The inputs of tx1 are not rate-limited =3D> tx1 must have only a single
>>> output which will become rate-limited;
>>> params: tx1_epochStart=3D800001, tx1_epochEnd=3D800100, tx1_limit=3D200=
k,
>>> tx1_remain=3D200k;
>>> =3D> This defines that an epoch has 100 blocks and no more than 200k sa=
ts
>>> may be spent in any one epoch. Within the current epoch, 200k sats may
>>> still be spent.
>>>
>>> This transaction begins to rate-limit a set of inputs, so it has a
>>> single rate-limited output.
>>> Let's explore transactions that have the output of tx1 as their input. =
I
>>> will denote the output of tx1 as "out1".
>>>
>>> tx2a has out1 as its only input;
>>> tx2a spends 50k sats and gets included at block height 803050;
>>> tx2a specifies the following params for its change output "chg2a":
>>> chg2a_epochStart=3D803001, chg2a_epochEnd=3D803100;
>>> chg2a_limit=3D200k, chg2a_remain=3D150k.
>>>
>>> To enforce rate-limiting, the system must validate the params of the
>>> change output chg2a to ensure that overspending is not allowed.
>>>
>>> The above params are allowed because:
>>> =3D> 1. the epoch does not become smaller than 100 blocks [(chg2a_epoch=
End
>>> - chg2a_epochStart) >=3D (tx1_epochEnd - tx1_epochStart)]
>>> =3D> 2. tx1_limit has not been increased (ch2a_limit <=3D tx1_limit)
>>> =3D> 3. the amount spent (50k sats) does not exceed tx1_remain AND does
>>> not exceed chg2a_limit;
>>> =3D> 4. chg2a_remain" is 50k sats less than chg2a_limit.
>>>
>>> A transaction may also further constrain further spending like so:
>>>
>>> tx2b has out1as its only input;
>>> tx2b spends 8k sats and gets included at block height 808105;
>>> tx2b specifies the following params for its change output "chg2b":
>>> chg2b_epochStart=3D808101, chg2b_epochEnd=3D808250;
>>> chg2b_limit=3D10k, chg2b_remain=3D0.
>>>
>>> These params are allowed because:
>>> =3D> 1. the epoch does not become smaller than100 blocks. It is fine to
>>> increase the epoch to 150 blocks because it does not enable exceeding t=
he
>>> original rate-limit;
>>> =3D> 2. the limit (chg2b_limit) has been decreased to 10k sats, further
>>> restricting the maximum amount allowed to be spent within the current a=
nd
>>> any subsequent epochs;
>>> =3D> 3. the amount spent (10k sats) does not exceed tx1_remain AND does
>>> not exceed chg2b_limit;
>>> =3D> 4. chg2b_remain has been set to zero, meaning that within the curr=
ent
>>> epoch (block height 808101 to and including 808250), tx2b cannot be use=
d as
>>> a spending input to any transaction.
>>>
>>> Starting from block height 808251, a new epoch will start and the
>>> rate-limited output of tx2b may again be used as an input for a subsequ=
ent
>>> rate-limited transaction tx3b. This transaction tx3b must again be
>>> accompanied by params that do not violate the rate-limit as defined by =
the
>>> params of tx2b and which are stored with output out2b. So, the epoch of
>>> tx3b must be at minimum 150 blocks, the maximum that is allowed to be s=
pent
>>> per epoch is at most 10k sats, and chg3b_remain must be decreased by at
>>> least the amount spent by tx3b.
>>>
>>> From the above, the rate-limiting mechanics should hopefully be clear
>>> and full set of validation rules could be defined in a more generalized=
way
>>> with little additional effort.
>>>
>>> Note that I conveniently avoided talking about how to represent the
>>> parameters within transactions or outputs, simply because I currently l=
ack
>>> enough understanding to reason about this. I am hoping that others may
>>> offer help.
>>>
>>> Zac
>>>
>>>
>>> On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud <billy.tetrud@gmail.com>
>>> wrote:
>>>
>>>> > 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 specify=
ing
>>>> block ranges simplifies the logic - wouldn't this complicate the logic=
with
>>>> additional user-specified constraints? It also prevents the output fro=
m
>>>> 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 walle=
ts
>>>> (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 si=
mply
>>>> remain unspendable for the rest of the epoch. That way these things do=
n't
>>>> need to be tied together. However, that doesn't solve the problem of 3=
rd
>>>> 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 th=
at
>>>> are not intuitively related to their purpose (eg if a rate-limited wal=
let
>>>> 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 s=
end
>>>> money into their wallet) or require a lot of technical complexity in
>>>> applications (eg to support something like cooperatively connecting wi=
th
>>>> 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 t=
o
>>>> 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 i=
f the
>>>> BIP isn't adopted, it could be a starting point or inspiration for som=
eone
>>>> 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 wind=
ow (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 addres=
s with
>>>>>> the original address, meaning they would have completely separate ra=
te
>>>>>> 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 i=
s only
>>>>> valid if its output is itself rate-limited such that it does not viol=
ate
>>>>> 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=3D800000, h1=3D800143, a=3D500k, a_remaining=3D=
300k;
>>>>>
>>>>> Transaction t2:
>>>>> Included at block height 800200
>>>>> Spend: 400k + fees.
>>>>> Rate-limiting params: h0=3D800144, h1=3D800287, a=3D500k, a_remaining=
=3D100k.
>>>>>
>>>>> Note how transaction t2 re-specifies the rate-limiting parameters.
>>>>> Validation must ensure that the re-specified parameters are within bo=
unds,
>>>>> 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=3D800144, h1=3D800287,
>>>>> a=3D500k, a_remaining=3D100k.
>>>>>
>>>>> 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 an=
y
>>>>> 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 pe=
r
>>>>> 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 t=
est
>>>>> the waters and to keep things relatively simple, I chose not to go in=
to
>>>>> 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 al=
low
>>>>> any transaction having more than one rate-limited input. One could im=
agine
>>>>> complex logic to handle transactions having multiple rate-limited inp=
uts by
>>>>> creating multiple rate-limited change addresses. However at first gla=
nce 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 tremendo=
us
>>>>> value in this functionality. Favorable feedback of the list regarding=
the
>>>>> usefulness and the technical feasibility of rate-limiting functionali=
ty
>>>>> would of course be an encouragement for me to descend further down th=
e
>>>>> 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 scriptin=
g
>>>>>> 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 f=
rom 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 cert=
ain
>>>>>> 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 user=
s'
>>>>>> 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 r=
educe
>>>>>> 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 "se=
t" of
>>>>>> keys meaning "one or more" keys). One set of private keys allows onl=
y for
>>>>>> sending with rate-limiting restrictions in place, and a second set o=
f
>>>>>> 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 ha=
s
>>>>>> been rate-limited with parameters (h0, h1, a, a_remaining) of (80000=
0,
>>>>>> 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 on=
e day
>>>>>> ignoring block time variance) and that the full amount of 500k is st=
ill
>>>>>> sendable. These rate-limiting parameters ensure that it takes at min=
imum
>>>>>> 100m / 500k =3D 200 transactions and 200 x 144 blocks or about 200 d=
ays to
>>>>>> spend the full 100m sats. As noted earlier, in a typical setup a use=
r
>>>>>> should retain the option to transact the entire amount using a secon=
d (set
>>>>>> of) private key(s).
>>>>>>
>>>>>> For rate-limiting to work, any change output created by a transactio=
n
>>>>>> from a rate-limited address must itself be rate-limited as well. For
>>>>>> instance, expanding on the above example, assume that the user spend=
s 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=3D800000, h1=3D800143, a=3D500k,
>>>>>> a_remaining=3D500k;
>>>>>>
>>>>>> Transaction t1:
>>>>>> Included at block height 800100;
>>>>>> Spend: 200k + fee;
>>>>>> Rate limiting params: h0=3D800000, h1=3D800143, a=3D500k, a_remainin=
g=3D300k.
>>>>>>
>>>>>> 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=3D800000, h1=3D800143,
>>>>>> a=3D500k, a_remaining=3D300k.
>>>>>>
>>>>>> In order to properly enforce rate limiting, the change address must
>>>>>> be rate-limited such that the original rate limit of 500k sats per 1=
44
>>>>>> blocks cannot be exceeded. In this example, the change address a2 we=
re
>>>>>> given the same rate limiting parameters as the transaction that serv=
ed as
>>>>>> its input. As a result, from block 800100 up until and including blo=
ck
>>>>>> 800143, a maximum amount of 300k sats is allowed to be spent from th=
e
>>>>>> change address.
>>>>>>
>>>>>> Example continued:
>>>>>> a2: 99.8 sats at height 800100;
>>>>>> Rate-limit params: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=
=3D300k;
>>>>>>
>>>>>> Transaction t2:
>>>>>> Included at block height 800200
>>>>>> Spend: 400k + fees.
>>>>>> Rate-limiting params: h0=3D800144, h1=3D800287, a=3D500k, a_remainin=
g=3D100k.
>>>>>>
>>>>>> 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=3D800144, h1=3D800287,
>>>>>> a=3D500k, a_remaining=3D100k.
>>>>>>
>>>>>> 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 tha=
t 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=3D800000, h1=3D800143, a=3D500k,
>>>>>> a_remaining=3D300k;
>>>>>>
>>>>>> Transaction t2a:
>>>>>> Included at block height 800200;
>>>>>> Spend: 400k + fees;
>>>>>> Rate-limit params: h0=3D800124, h1=3D800267, a=3D500k, a_remaining=
=3D100k.
>>>>>>
>>>>>> This transaction t2a attempts to shift the epoch forward by 20 block=
s
>>>>>> 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 woul=
d
>>>>>> 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 w=
ish to
>>>>>> enforce not spending more during an epoch. A second advantage of exp=
licitly
>>>>>> specifying the four rate-limiting parameters with each transaction i=
s that
>>>>>> it allows the system to fully validate the transaction without havin=
g 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 wo=
rk jump
>>>>>> to mind:
>>>>>>
>>>>>> Define all validations;
>>>>>> Describe aggregate behaviour of multiple (rate-limited) inputs, proo=
f
>>>>>> that two rate-limited addresses cannot spend more than the sum of th=
eir
>>>>>> individual limits.
>>>>>>
>>>>>> Zac
>>>>>>
>>>>>
--00000000000022355a05c929c3e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0
<span style=3D"color:rgb(0,0,0)">By explicitly specifying the start and end=
block of an epoch, the user has more flexibility in shifting the epoch</sp=
an><div><span style=3D"color:rgb(0,0,0)"><br></span></div><div><span style=
=3D"color:rgb(0,0,0)">Ok I see.=C2=A0</span><span style=3D"color:rgb(0,0,0)=
">I think I understand your proposal better now. If the output is spent wit=
hin the range epochStart - epochEnd, the limit holds, if it is spent outsid=
e=C2=A0that range the change output must also have a range of the same leng=
th (or shorter?).=C2=A0</span><span style=3D"color:rgb(0,0,0)">So you want =
there to be the ability for the user to precisely define the length and sta=
rting block of the rate-limiting-period (epoch). I'd say it'd be cl=
earer to specify the window length and the starting block in that case. The=
same semantics can be kept.=C2=A0</span></div><div><br></div><div>>=C2=
=A0<span style=3D"color:rgb(0,0,0)">This would require the system to bookke=
ep how much was spent since the first rate-limited output</span></div><div>=
<span style=3D"color:rgb(0,0,0)"><br></span></div><div><span style=3D"color=
:rgb(0,0,0)">Yes, for the length of the epoch, after which the bookkeeping=
=C2=A0can be discarded/reset until a new transaction is sent.=C2=A0</span>Y=
our proposal also requires bookkeeping tho - it needs to store the 'rem=
ain' value with the UTXO as well because its not efficient to go back a=
nd re-execute the script just to grab that value.=C2=A0</div><div><br></div=
><div>>=C2=A0<span style=3D"color:rgb(0,0,0)">using an address as input =
for a transaction will always spends the full amount at that address</span>=
</div><div><span style=3D"color:rgb(0,0,0)"><br></span></div><div><span sty=
le=3D"color:rgb(0,0,0)">Using a UTXO will spend the full UTXO. The address =
may contain many UTXOs. I'm not suggesting that a change address isn=
9;t needed - I'm suggesting that the *same* address be used as the chan=
ge address for the change output. Eg consider the following UTXO info:</spa=
n></div><div><span style=3D"color:rgb(0,0,0)"><br></span></div><div><span s=
tyle=3D"color:rgb(0,0,0)">Address X:=C2=A0</span><span style=3D"color:rgb(0=
,0,0)">rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats)</span></di=
v><div><span style=3D"color:rgb(0,0,0)">* UTXO 1: 100k sats, 50k spent by a=
ncestor inputs since epochStart 800100</span></div><div><span style=3D"colo=
r:rgb(0,0,0)">* UTXO 2: 200k sats, 10k spent since epochStart</span></div><=
div><span style=3D"color:rgb(0,0,0)"><br></span></div><div><span style=3D"c=
olor:rgb(0,0,0)">When sending a transaction using UTXO 2, a node would look=
up the list of UTXOs in Address X, add up the amount spent since epochStar=
t (60k) and ensure that at most 40k is going to an address that isn't a=
ddress X. So a valid transaction might look like:</span></div><div><span st=
yle=3D"color:rgb(0,0,0)"><br></span></div><div><span style=3D"color:rgb(0,0=
,0)">Input: UTXO 2</span></div><div><span style=3D"color:rgb(0,0,0)">Output=
1: 30k -> Address A</span></div><div><span style=3D"color:rgb(0,0,0)">O=
utput 2: 170k -> Address X</span></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 5, 2021 at 7:22 AM Za=
c Greenwood <<a href=3D"mailto:zachgrw@gmail.com" target=3D"_blank">zach=
grw@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"auto">Hi Billy,</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">>=C2=A0<span style=3D"color:rgb(0,0,0)">It sounds like =
you're proposing an opcode</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)">No. I don=E2=80=99t have enough knowledge of Bitcoin to be able=
to tell how (and if) rate-limiting can be implemented as I suggested. I am=
not able to reason about opcodes, so I kept my description at a more funct=
ional level.</span></div><div dir=3D"auto"><br></div><div dir=3D"auto">>=
=C2=A0<span style=3D"color:rgb(0,0,0)">I still don't understand why its=
=C2=A0useful to specify those as absolute block heights</span></div><div di=
r=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><div dir=3D"au=
to"><span style=3D"color:rgb(0,0,0)">I feel that this a rather uninterestin=
g data representation aspect that=E2=80=99s not worth going back and forth =
about. Sure, specifying the length of the epoch may also be an option, alth=
ough at the price of giving up some functionality, and without much if any =
gains.</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)">By explicitl=
y specifying the start and end block of an epoch, the user has more flexibi=
lity in shifting the epoch (using alternate values for epochStart and epoch=
End) and simultaneously increasing the length of an epoch. These seem rathe=
r exotic features, but there=E2=80=99s no harm in retaining them.</span></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">><span style=3D"color:r=
gb(0,0,0)">=C2=A0if you have a UTXO encumbered by rateLimit(epochStart =3D =
800100, epochEnd =3D 800200, limit =3D 100k, remain =3D 100k), what happens=
if you don't spend that UTXO before block 800200?</span></div><div dir=
=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><div style=3D"b=
ackground-color:rgba(0,0,0,0);border-color:rgb(255,255,255);color:rgb(255,2=
55,255)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">The rate limit remai=
ns in place. So if this UTXO is spent in block 900000, then at most 100k ma=
y be spent. Also, the new epoch must be at least 100 blocks and remain must=
correctly account for the actual amount spent.</font></div><div dir=3D"aut=
o"><span style=3D"color:rgb(0,0,0)"><br></span></div><div dir=3D"auto"><spa=
n style=3D"color:rgb(0,0,0)">>=C2=A0</span><span style=3D"color:rgb(0,0,=
0)">This is how I'd imagine creating an opcode like this:</span></div><=
div style=3D"border-color:rgb(0,0,0);color:rgb(0,0,0)" dir=3D"auto"><br></d=
iv><div style=3D"border-color:rgb(0,0,0);color:rgb(0,0,0)" dir=3D"auto">>=
; rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats)</div><div dir=
=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><div style=3D"b=
ackground-color:rgba(0,0,0,0);border-color:rgb(255,255,255);color:rgb(255,2=
55,255)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">This would require t=
he system to bookkeep how much was spent since the first rate-limited outpu=
t. It is a more intuitive way of rate-limiting but it may be much more diff=
icult to implement, which is why I went with the epoch-based rate limiting =
solution. In terms of functionality, I believe the two solutions are nearly=
identical for all practical purposes.</font></div><div style=3D"background=
-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir=3D"auto"><font styl=
e=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);color:rgb(255,255,255)" dir=3D"auto"><=
font style=3D"color:rgb(0,0,0)">Your next section confuses me. As I underst=
and it, using an address as input for a transaction will always spends the =
full amount at that address. That=E2=80=99s why change addresses are requir=
ed, no? If Bitcoin were able to pay exact amounts then there wouldn=E2=80=
=99t be any need for change outputs.</font></div><div style=3D"background-c=
olor: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);border-color:rgb(32,33,36)" dir=3D"auto"><font style=3D"color:rgb(0,0,=
0)">Zac</font></div><div dir=3D"auto"><span style=3D"color:rgb(0,0,0)"><br>=
</span></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Thu, 5 Aug 2021 at 08:39, Billy Tetrud <<a href=3D"mailto=
:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>> w=
rote:<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"><div dir=
=3D"ltr">>=C2=A0
=C2=A0A maximum amount is allowed to be spent within EVERY epoch.<div><br><=
/div><div>It sounds like you're proposing an opcode that takes in epoch=
Start and epochEnd as parameters. I still don't understand why its=C2=
=A0useful to specify those as absolute block heights. You mentioned=C2=A0th=
at this enables more straightforward validation logic, but I don't see =
how. Eg, if you have a UTXO encumbered by rateLimit(epochStart =3D 800100, =
epochEnd =3D 800200, limit =3D 100k, remain =3D 100k), what happens if you =
don't spend that UTXO before block 800200? Is the output no longer rate=
limited then? Or is the opcode calculating 800200-800100 =3D 100 and apply=
ing a rate limit for the next epoch? If the first, then the UTXO must be sp=
ent within one epoch to remain rate limited. If the second, then it seems n=
early identical to simply specifying window=3D100 as a parameter instead of=
epochStart and epochEnd.</div><div><br></div><div>> then there must be =
only a single (rate-limited) output</div><div><br></div><div>This rule woul=
d make transactions tricky if you're sending money into someone else=
9;s wallet that may be rate limited. If the requirement is that only you yo=
urself can send money into a rate limited wallet, then this point is moot b=
ut it would be ideal to not have such a requirement.</div><div><br></div><d=
iv>This is how I'd imagine creating an opcode like this:</div><div><br>=
</div><div>rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats)</div><=
div><br></div><div>This would define that the epoch is 1 day's worth of=
blocks. This would evenly divide bitcoin's retarget period and so each=
window would start and end at those dividing lines (eg the first 144 block=
s of the retargetting period, then the second, then the third, etc).=C2=A0<=
/div><div><br></div><div>When this output is spent, it ensures that there&#=
39;s a maximum of 100k sats is sent to addresses other than the originating=
address. It also records the amount spent in the current 144 block window =
for that address (eg by simply recording the already-spent amount on the re=
sulting UTXO and having an index that allows looking up UTXOs by address an=
d adding them up). That way, when any output from that address is spent aga=
in, if a new 144 block window has started, the limit is reset, but if its s=
till within the same window, the already-spent amounts for UTXOs from that =
address are added up and subtracted from the limit, and that number is the =
remaining limit a subsequent transaction needs to adhere to.=C2=A0</div><di=
v><br></div><div>This way, 3rd party could send transactions into an addres=
s like this, and multiple outputs can be combined and used to spend to arbi=
trary outputs (up to the rate limit of course).</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 4, 2021 =
at 3:48 AM Zac Greenwood <<a href=3D"mailto:zachgrw@gmail.com" target=3D=
"_blank">zachgrw@gmail.com</a>> wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div>> Ah I =
see, this is all limited to within a single epoch.</div><div><br></div><div=
>No, that wouldn't be useful. A maximum amount is allowed to be spent w=
ithin EVERY epoch.</div><div><br></div><div>Consider an epoch length of 100=
blocks with a spend limit of 200k per epoch. The following is allowed:</di=
v><div><br></div><div>epoch1 (800101 - 800200): spend 120k in block 800140.=
Remaining for epoch1: 80k;</div><div>epoch1 (800101 - 800200): spend anoth=
er 60k in block 800195. Remaining for epoch1: 20k;</div><div>epoch2 (800201=
- 800300): spend 160k in block 800201. Remaining for epoch2: 40k.</div><di=
v><br></div><div>Since the limit pertains to each individual epoch, it is a=
llowed to spend up to the full limit at the start of any new epoch. In this=
example, the spending was as follows:</div><div><br></div><div>800140: 120=
k</div><div>800195: 60k</div><div>800201: 160k.</div><div><br></div><div>No=
te that in a span of 62 blocks a total of 340k sats was spent. This may see=
m to violate the 200k limit per 100 blocks, but this is the result of using=
a per-epoch limit. This allows a maximum of 400k to be spent in 2 blocks l=
lke so: 200k in the last block of an epoch and another 200k in the first bl=
ock of the next epoch. However this is inconsequential for the intended goa=
l of rate-limiting which is to enable small spends over time from a large a=
mount and to prevent theft of a large amount with a single transaction.</di=
v><div><br></div><div>To explain the proposed design more clearly, I have r=
enamed the params as follows:</div><div><br></div><div>epochStart: block he=
ight of first block of the current epoch (was: h0);</div><div>epochEnd: blo=
ck height of last block of the current epoch (was: h1);</div><div>limit: th=
e maximum total amount allowed to be spent within the current epoch (was: a=
);</div><div>remain: the remaining amount allowed to be spent within the cu=
rrent epoch (was: a_remaining);</div><div><br></div><div>Also, to illustrat=
e that the params are specific to a transaction, I will hence precede the p=
aram with the transaction name like so:</div><div>tx8_limit, tx31c_remain, =
tx42z_epochStart, ... etc.</div><div><br></div><div>For simplicity, only tr=
ansactions with no more than one rate-limited input are considered, and wit=
h no more than two outputs: one rate-limited change output, and a normal (n=
ot rate-limited) output.<br></div><div><br></div><div>Normally, a simple tr=
ansaction generates two outputs: one for a payment to a third party and one=
for the change address. Again for simplicity, we demand that a transaction=
which introduces rate-limiting must have only a single, rate-limited outpu=
t. The validation rule might be: if a transaction has rate-limiting params =
and none of its inputs are rate-limited, then there must be only a single (=
rate-limited) output (and no second or change output).<br></div><div><br></=
div><div><div>Consider rate limiting transactions tx1 having one or more no=
rmal (non rate-limited) inputs:</div><div><br></div><div>tx1 gets included =
at block height 800004;</div><div>The inputs of tx1 are not rate-limited =
=3D> tx1 must have only a single output which will become rate-limited;<=
/div><div>params: tx1_epochStart=3D800001, tx1_epochEnd=3D800100, tx1_limit=
=3D200k, tx1_remain=3D200k;</div><div>=3D> This defines that an epoch ha=
s 100 blocks and no more than 200k sats may be spent in any one epoch. With=
in the current epoch, 200k sats may still be spent.</div><div><br></div><di=
v>This transaction begins to rate-limit a set of inputs, so it has a single=
rate-limited output.</div></div><div>Let's explore transactions that h=
ave the output of tx1 as their input. I will denote the output of tx1 as &q=
uot;out1".</div><div><br></div><div>tx2a has out1 as its only input;</=
div><div>tx2a spends 50k sats and gets included at block height 803050;</di=
v><div>tx2a specifies the following params for its change output "chg2=
a":</div><div>chg2a_epochStart=3D803001, chg2a_epochEnd=3D803100;</div=
><div>chg2a_limit=3D200k, chg2a_remain=3D150k.</div><div><br></div><div>To =
enforce rate-limiting, the system must validate the params of the change ou=
tput chg2a to ensure that overspending is not allowed.</div><div><br></div>=
<div>The above params are allowed because:</div><div>=3D> 1. the epoch d=
oes not become smaller than 100 blocks [(chg2a_epochEnd - chg2a_epochStart)=
>=3D (tx1_epochEnd - tx1_epochStart)]</div><div>=3D> 2. tx1_limit ha=
s not been increased (ch2a_limit <=3D tx1_limit)</div><div>=3D> 3. th=
e amount spent (50k sats) does not exceed tx1_remain AND does not exceed ch=
g2a_limit;</div><div>=3D> 4. chg2a_remain" is 50k sats less than ch=
g2a_limit.</div><div><br></div><div>A transaction may also further constrai=
n further spending like so:</div><div><br></div><div>tx2b has out1as its on=
ly input;</div><div><div>tx2b spends 8k sats and gets included at block hei=
ght 808105;</div><div>tx2b specifies the following params for its change ou=
tput "chg2b":</div><div>chg2b_epochStart=3D808101, chg2b_epochEnd=
=3D808250;</div><div>chg2b_limit=3D10k, chg2b_remain=3D0.<br></div><div><br=
></div><div>These params are allowed because:<br></div><div>=3D> 1. the =
epoch does not become smaller than100 blocks. It is fine to increase the ep=
och to 150 blocks because it does not enable exceeding the original rate-li=
mit;</div><div>=3D> 2. the limit (chg2b_limit) has been decreased to 10k=
sats, further restricting the maximum amount allowed to be spent within th=
e current and any subsequent epochs;</div><div>=3D> 3. the amount spent =
(10k sats) does not exceed tx1_remain AND does not exceed chg2b_limit;</div=
><div>=3D> 4. chg2b_remain has been set to zero, meaning that within the=
current epoch (block height 808101 to and including 808250), tx2b cannot b=
e used as a spending input to any transaction.</div><div><br></div></div><d=
iv>Starting from block height 808251, a new epoch will start and the rate-l=
imited output of tx2b may again be used as an input for a subsequent rate-l=
imited transaction tx3b. This transaction tx3b must again be accompanied by=
params that do not violate the rate-limit as defined by the params of tx2b=
and which are stored with output out2b. So, the epoch of tx3b must be at m=
inimum 150 blocks, the maximum that is allowed to be spent per epoch is at =
most 10k sats, and chg3b_remain must be decreased by at least the amount sp=
ent by tx3b.</div><div><br></div><div>From the above, the rate-limiting mec=
hanics should hopefully be clear and full set of validation rules could be =
defined in a more generalized way with little additional effort.</div><div>=
<br></div><div>Note that I conveniently avoided talking about how to repres=
ent the parameters within transactions or outputs, simply because I current=
ly lack enough understanding to reason about this. I am hoping that others =
may offer help.</div><div><br></div><div>Zac</div><div><br></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Au=
g 3, 2021 at 8:12 PM Billy Tetrud <<a href=3D"mailto:billy.tetrud@gmail.=
com" target=3D"_blank">billy.tetrud@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">> To enabl=
e more straightforward validation logic.<div>> within the current epoch<=
/div><div><br></div><div>Ah I see, this is all limited to within a single e=
poch. I think that sufficiently limits the window of time in which nodes ha=
ve to store information for rate limited outputs. However, I don't see =
how specifying block ranges simplifies the logic - wouldn't this compli=
cate the logic with additional user-specified constraints? It also prevents=
the output from being able to be rate limited over the span of multiple ep=
ochs, which would seem to make it a lot more difficult to use for certain t=
ypes of wallets (eg cold wallets).=C2=A0</div><div><br></div><div>I think I=
see the logic of your 'remaining' parameter there. If you start wi=
th 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 nee=
d to be tied together. However, that doesn't solve the problem of 3rd p=
arties being able to send money into the wallet.=C2=A0</div><div><br></div>=
<div>> I don't believe that the marginal added functionality would j=
ustify the increased implementation complexity</div><div><br></div><div>Per=
haps, but I think there is a lot of benefit in allowing these kinds of thin=
gs to operate as similarly as possible to normal transactions, for one beca=
use of usability reasons. If each opcode has its own quirks that are not in=
tuitively 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 t=
heir wallet) or require a lot of technical complexity in applications (eg t=
o support something like cooperatively connecting with their wallet so that=
a transaction can be made that creates a new single-output=C2=A0for the wa=
llet). A little complexity in this opcode can save a lot of external comple=
xity 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 w=
ho is. Even if the BIP isn't adopted, it could be a starting point or i=
nspiration for someone else to write an improved version.=C2=A0</div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" 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>> wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">[Note: I've mo=
ved your reply to the newly started thread]<div><br></div><div>Hi Billy,<di=
v><br></div><div>Thank you for your kind and encouraging feedback.</div><di=
v><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">I don't q=
uite 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 cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">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 comp=
letely separate rate limits, which wouldn't work since the change outpu=
t would ignore the previous rate limit.</blockquote><div><br></div><div>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 outpu=
t is itself rate-limited such that it does not violate the rate-limiting co=
nstraints of its input.</div><div><br></div><div>In my thread-starter, I ga=
ve the below example of a rate-limited address a2 that serves as input for =
transaction t2:</div><div><br></div><div><div>a2: 99.8 sats at height=C2=A0=
800100;</div><div>Rate-limit params: h0=3D800000, h1=3D800143, a=3D500k, a_=
remaining=3D300k;</div><div><br></div><div>Transaction t2:</div><div>Includ=
ed at block height 800200</div><div>Spend: 400k=C2=A0+ fees.</div><div>Rate=
-limiting params: h0=3D800144, h1=3D800287, a=3D500k, a_remaining=3D100k.<b=
r></div><div><br></div><div>Note how transaction t2 re-specifies the rate-l=
imiting parameters. Validation must ensure that the re-specified parameters=
are within bounds, i.e., do not allow more spending per epoch than the rat=
e-limiting parameters of its input address a2. Re-specifying the rate-limit=
ing parameters offers the flexibility to further restrict spending, or to d=
isable any additional spending within the current epoch by setting a_remain=
ing to zero.</div><div><br></div><div><div>Result:</div><div>Value at desti=
nation address: 400k sats;</div><div>Rate limiting params at destination ad=
dress: none;</div><div>Value at change address a3: 99.4m sats;</div><div>Ra=
te 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 prin=
ciple 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 how=
ever enable more sophisticated rate-limiting (such as rate-limiting per sli=
ding 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 parameter=
s 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.</div><=
div><br></div><div>I haven't gone into how to process a transaction hav=
ing 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 cou=
ld imagine complex logic to handle transactions having multiple rate-limite=
d inputs by creating multiple rate-limited change addresses. However at fir=
st glance I don't believe that the marginal added functionality would j=
ustify the increased implementation complexity.</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">=C2=A0I'd be interested in s=
eeing you write a BIP for this.</blockquote><div><br></div><div>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 funct=
ionality. Favorable feedback of the list regarding the usefulness and the t=
echnical feasibility of rate-limiting functionality would of course be an e=
ncouragement 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_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 1, 2021 at 10:09 AM Za=
c Greenwood <<a href=3D"mailto:zachgrw@gmail.com" target=3D"_blank">zach=
grw@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>[Resubmitting to list with minor edits. =
My previous submission ended up inside an existing thread, apologies.]</div=
><div><br></div><div>Hi list,</div><div><br></div><div>I'd like to expl=
ore whether it is feasible to implement new scripting capabilities in Bitco=
in that enable limiting the output amount of a transaction based on the tot=
al value of its inputs. In other words, to implement the ability to limit t=
he maximum amount that can be sent from an address.</div><div><br></div><di=
v>Two use cases come to mind:</div><div><br></div><div>UC1: enable a user t=
o add additional protection their funds by rate-limiting the amount that th=
ey are allowed to send during a certain period (measured in blocks). A typi=
cal 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 t=
he user to become aware of the theft and intervene to prevent further theft=
s.</div><div><br></div><div>UC2: exchanges may wish to rate-limit addresses=
containing large amounts of bitcoin, adding warm- or hot-wallet functional=
ity 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 key=
s that give access to the full amount.</div><div><br></div><div>In a typica=
l 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 m=
eaning "one or more" keys). One set of private keys allows only f=
or sending with rate-limiting restrictions in place, and a second set of pr=
ivate keys allowing for sending any amount without rate-limiting, effective=
ly overriding such restriction.</div><div><br></div><div>The parameters tha=
t define in what way an output is rate-limited 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 height of an epoch;</div><div>Par=
am 3: an amount "a" in satoshi indicating the maximum amount that=
is allowed to be sent in any epoch;<br></div><div>Param 4: an amount "=
;a_remaining" (in satoshi) indicating the maximum amount that is allow=
ed to be sent within the current epoch.</div></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_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 80=
0000 and ends at height 800143 (or about one day ignoring block time varian=
ce) and that the full amount of 500k is still sendable. These rate-limiting=
parameters ensure that it takes at minimum 100m / 500k =3D 200 transaction=
s and 200 x 144 blocks or about 200 days to spend the full 100m sats. As no=
ted earlier, in a typical setup a user should 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 change output created by a transact=
ion from a rate-limited address must itself be rate-limited as well. For in=
stance, expanding on the above example, assume that the user spends 200k sa=
ts from a rate-limited address a1 containing 100m sats:</div><div><br></div=
><div>Start situation:</div><div>At block height 800000: rate-limited addre=
ss a1 is created;</div><div>Value of a1: 100.0m sats;</div><div>Rate limiti=
ng params of a1: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D500k;</d=
iv><div><br></div><div>Transaction t1:</div><div>Included at block height 8=
00100;</div><div>Spend: 200k + fee;</div><div>Rate limiting params: h0=3D80=
0000, h1=3D800143, a=3D500k, a_remaining=3D300k.</div><div><br></div><div>R=
esult:</div><div>Value at destination address: 200k sats;</div><div>Rate li=
miting params at destination address: none;</div><div>Value at change addre=
ss a2: 99.8m sats;</div><div>Rate limiting params at change address a2: h0=
=3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k.</div><div><br></div><=
div>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 s=
ame rate limiting parameters as the transaction that served as its input. A=
s a result, from block 800100 up until and including block 800143, a maximu=
m 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>Inc=
luded at block height 800200</div><div>Spend: 400k=C2=A0+ fees.</div><div>R=
ate-limiting params: h0=3D800144, h1=3D800287, a=3D500k, a_remaining=3D100k=
.<br></div><div><br></div><div><div>Result:</div><div>Value at destination =
address: 400k sats;</div><div>Rate limiting params at destination address: =
none;</div><div>Value at change address a3: 99.4m sats;</div><div>Rate limi=
ting params at change address a3: h0=3D800144, h1=3D800287, a=3D500k, a_rem=
aining=3D100k.</div><div><br></div><div>Transaction t2 is allowed because i=
t falls within the next epoch (running from 800144 to 800287) so a spend of=
400k does not violate the constraint of 500k per epoch.</div><div><br></di=
v><div>As could be seen, the rate limiting parameters are part of the trans=
action and chosen by the user (or their wallet). This means that the parame=
ters must be validated to ensure that they do not violate the intended cons=
traints.</div><div><br></div><div>For instance, 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=3D=
300k;</div><div><br></div><div>Transaction t2a:</div><div>Included at block=
height 800200;</div><div>Spend: 400k=C2=A0+ fees;</div><div><div>Rate-limi=
t params: h0=3D800124, h1=3D800267, a=3D500k, a_remaining=3D100k.</div><div=
><br></div></div><div>This transaction t2a attempts to shift the epoch forw=
ard 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></div><div><br></div><div>t1: spend 200=
k at 800100 (epoch 1: total: 200k);</div><div>t2a: spend 400k at 800200 (ep=
och 2: total: 400k);</div><div>t3a: spend 100k at 800201 (epoch 2: total: 5=
00k);</div><div>t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspend=
ing for epoch 2).</div><div><br></div><div>Specifying the rate-limiting par=
ameters explicitly at every transaction allows the user to tighten the spen=
ding 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 a=
dvantage of explicitly specifying the four rate-limiting parameters with ea=
ch transaction is that it allows the system to fully validate the transacti=
on without having to consider any previous transactions within an epoch.</d=
iv><div><br></div><div>I will stop here because I would like to gauge inter=
est in this idea first before continuing work on other aspects. Two main pi=
eces 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 cannot spend more than the sum of the=
ir individual limits.</div><font style=3D"color:rgb(136,136,136)"><div><br>=
</div><div>Zac</div></font></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
--00000000000022355a05c929c3e7--
|