path: root/6a/2f594a0d26e1714a216f2724d1c072e9d21f7f

Return-Path: <zachgrw@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 58ECFC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Aug 2021 09:32:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 47A49403D9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Aug 2021 09:32:50 +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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id KAIVHlMOo_Gt
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Aug 2021 09:32:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com
 [IPv6:2607:f8b0:4864:20::d32])
 by smtp4.osuosl.org (Postfix) with ESMTPS id AFDB6403C3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Aug 2021 09:32:48 +0000 (UTC)
Received: by mail-io1-xd32.google.com with SMTP id m13so19496738iol.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 02 Aug 2021 02:32:48 -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=vqG1Fsl6diFhd2o8p5KRXRpYpGecisUhEdVYj0NBomM=;
 b=j4lyVtX0Vzzylj0cjc5YcV7ir7+zmHD3NHGBV7rpcn/5bvUCQBwed/kHW9MlSlPHSF
 4LwK8zR6Kumq+yvrH8de/RDjwnDmiMN2lvvwPOqa7YcerWiXynFEcGBbr63x8MUeeNGz
 Rlx2eQwzIZun8YNRJjBEpZ/W1am/mhBTEtt1QZtVqVbAFaLhKrfJpfiQ6FTz81sYnbfW
 SSU8mQi7LJOBu3Wiii6pDtpkcsVu1iIpPW8eH9LRP8CDMGjNHmQ1na4HaMJ5WQgpU93r
 GAVb7HnUoZeOIw4r8Owb/4iOH6IZc6FUbwaD7fiCkEHD6rcdLdaFvaWde3gJOR/wdAP7
 R6LA==
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=vqG1Fsl6diFhd2o8p5KRXRpYpGecisUhEdVYj0NBomM=;
 b=sOPzkKQlMBOVA8ctqmnPTli/8uvVCE3mkwO6mGKyFbit4hN/o3ddaAjA/7tOjFdQ+k
 3kZlKDd22RtlMH0Cwc1FRSOdjZ94y/R4dRJPAj8Jj3Pb77B4x9vGn+mmrAtvT76BrEAz
 5/E7xkiCVhR4uc0riM9ZI4xxMP8ccKZfh6LK92MUPScAUASIESjGMYJ+2YOSNhNKZM+v
 6UOEVrynlRgoZBOX9AUkySga4vVpaOb7k6EYiGbkh/LepkyoTwVhDPAZfVTAARMNXBkE
 23Pdh4EeS+hfhFcVGCXFXmSYLjuuJOkKUXqkownRJZ5YzEUUNFCKiBXNmXEQ8abpH/Xa
 kyEw==
X-Gm-Message-State: AOAM5308AIH9vY7Tc86wCAq801AV8rW9s+pBbqBL82PcRNYumoFVfAjA
 M58Tx1mw8STOJsm5Y9mJtoSd3XaR+cWt76ynVbQ=
X-Google-Smtp-Source: ABdhPJzUpB4dcUSMIlz/7N9AtBRW/Lhu5mZNMZsZi6JN2RHFL3Md9qeGHYlMdqWTqTpFCtm8ilJ5a9latYr3QaI3Rf0=
X-Received: by 2002:a6b:b287:: with SMTP id b129mr517264iof.209.1627896767845; 
 Mon, 02 Aug 2021 02:32:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAJ4-pEAETy7_vOez5H32mZLg9gRpRajvoBjZyBT_v=DEqdQJvQ@mail.gmail.com>
In-Reply-To: <CAJ4-pEAETy7_vOez5H32mZLg9gRpRajvoBjZyBT_v=DEqdQJvQ@mail.gmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Mon, 2 Aug 2021 11:32:36 +0200
Message-ID: <CAJ4-pEAxqvMc89xSp9NXXNwnpJ3NhMqE6p=dRbpYCAB3Gbb14g@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009418aa05c89040a3"
X-Mailman-Approved-At: Mon, 02 Aug 2021 10:26:44 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Exploring: limiting transaction output amount as
 a function of total input value
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2021 09:32:50 -0000

--0000000000009418aa05c89040a3
Content-Type: text/plain; charset="UTF-8"

[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
>

--0000000000009418aa05c89040a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">[Note: I&#39;ve moved your reply to the newly started thre=
ad]<div><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_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">I don&#39;t quite understand why you&#39;d want to de=
fine 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?</block=
quote><div><br></div><div>To enable more straightforward validation logic.<=
/div><div><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">You m=
entioned change addresses, however, with the parameters you defined, there =
would be no way to connect together the change address with the original ad=
dress, meaning they would have completely separate rate limits, which would=
n&#39;t work since the change output would ignore the previous rate limit.<=
/blockquote><div><br></div><div>The rate-limiting parameters must be re-spe=
cified for each rate-limited input. So, a transaction that has a rate-limit=
ed input is only valid if its output is itself rate-limited such that it do=
es not 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 a=
ddress 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=
=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>Note how tr=
ansaction t2 re-specifies the rate-limiting parameters. Validation must ens=
ure 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 addr=
ess a2. Re-specifying the rate-limiting parameters offers the flexibility t=
o further restrict spending, or to disable any additional spending within t=
he current epoch by setting a_remaining to zero.</div><div><br></div><div><=
div>Result:</div><div>Value at destination address: 400k sats;</div><div>Ra=
te limiting 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=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 s=
ystem is able to verify the validity of a transaction without having to con=
sider any transactions that precede its inputs. As a side-note, doing away =
with this design principle would however enable more sophisticated rate-lim=
iting (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 red=
ucing the size of per rate-limiting transaction (because it would enable sp=
ecifying the rate-limiting parameters more space-efficiently). To test the =
waters and to keep things relatively simple, I chose not to go into this en=
hanced form of rate-limiting.</div><div><br></div><div>I haven&#39;t gone i=
nto how to process a transaction having multiple rate-limited inputs. The e=
asiest 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 tran=
sactions having multiple rate-limited inputs by creating multiple rate-limi=
ted change addresses. However at first glance I don&#39;t believe that the =
marginal added functionality would justify the increased implementation com=
plexity.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">=C2=A0I&#39;d be interested in seeing you write a BIP for this.</blockq=
uote><div><br></div><div>Thank you, but sadly my understanding of Bitcoin i=
s 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 lis=
t regarding the usefulness and the technical feasibility of rate-limiting f=
unctionality 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></di=
v></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 &lt;<a href=3D"mailto:zachg=
rw@gmail.com">zachgrw@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>[Resubmitting to lis=
t with minor edits. My previous submission ended up inside an existing thre=
ad, apologies.]</div><div><br></div><div>Hi list,</div><div><br></div><div>=
I&#39;d like to explore whether it is feasible to implement new scripting c=
apabilities in Bitcoin that enable limiting the output amount of a transact=
ion based on the total value of its inputs. In other words, to implement th=
e ability to limit the maximum amount that can be sent from an address.</di=
v><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-limitin=
g the amount that they are allowed to send during a certain period (measure=
d 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-limitin=
g avoids an attacker from sweeping all the users&#39; funds in a single tra=
nsaction, allowing the user to become aware of the theft and intervene to p=
revent further thefts.</div><div><br></div><div>UC2: exchanges may wish to =
rate-limit addresses containing large amounts of bitcoin, adding warm- or h=
ot-wallet functionality to a cold-storage address. This would enable an exc=
hange to drastically reduce the number of times a cold wallet must be acces=
sed with private keys that give access to the full amount.</div><div><br></=
div><div>In a typical setup, I&#39;d envision using multisig such that the =
user has two sets of private keys to their encumbered address (with a &quot=
;set&quot; of keys meaning &quot;one or more&quot; keys). One set of privat=
e keys allows only for sending with rate-limiting restrictions in place, an=
d a second set of private keys allowing for sending any amount without rate=
-limiting, effectively overriding such restriction.</div><div><br></div><di=
v>The parameters that define in what way an output is rate-limited might be=
 defined as follows:</div><div><br></div><div>Param 1: a block height &quot=
;h0&quot; indicating the first block height of an epoch;</div><div><div>Par=
am 2: a block height &quot;h1&quot; indicating the last block height of an =
epoch;</div><div>Param 3: an amount &quot;a&quot; in satoshi indicating the=
 maximum amount that is allowed to be sent in any epoch;<br></div><div>Para=
m 4: an amount &quot;a_remaining&quot; (in satoshi) indicating the maximum =
amount that is allowed 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 (8=
00000, 800143, 500k, 500k). These parameters define that the address is rat=
e-limited to sending a maximum of 500k sats in the current epoch that start=
s at block height 800000 and ends at height 800143 (or about one day ignori=
ng 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=
 =3D 200 transactions and 200 x 144 blocks or about 200 days to spend the f=
ull 100m sats. As noted earlier, in a typical setup a user should retain th=
e 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 c=
reated by a transaction from a rate-limited address must itself be rate-lim=
ited 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:=
</div><div><br></div><div>Start situation:</div><div>At block height 800000=
: rate-limited address a1 is created;</div><div>Value of a1: 100.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>Includ=
ed at block height 800100;</div><div>Spend: 200k + fee;</div><div>Rate limi=
ting params: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k.</div><=
div><br></div><div>Result:</div><div>Value at destination address: 200k sat=
s;</div><div>Rate limiting params at destination address: none;</div><div>V=
alue at change address a2: 99.8m sats;</div><div>Rate limiting params at ch=
ange address a2: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k.</d=
iv><div><br></div><div>In order to properly enforce rate limiting, the chan=
ge address must be rate-limited such that the original rate limit of 500k s=
ats per 144 blocks cannot be exceeded. In this example, the change address =
a2 were given the same rate limiting parameters as the transaction that ser=
ved 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 the ch=
ange 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>Transacti=
on t2:</div><div>Included at block height 800200</div><div>Spend: 400k=C2=
=A0+ fees.</div><div>Rate-limiting params: h0=3D800144, h1=3D800287, a=3D50=
0k, 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 sat=
s;</div><div>Rate limiting params at change address a3: h0=3D800144, h1=3D8=
00287, a=3D500k, a_remaining=3D100k.</div><div><br></div><div>Transaction t=
2 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 epo=
ch.</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 wallet). This=
 means that the parameters must be validated to ensure that they do not vio=
late the intended constraints.</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=3D300k;</div><div><br></div><div>Transaction t2a:</di=
v><div>Included at block height 800200;</div><div>Spend: 400k=C2=A0+ fees;<=
/div><div><div>Rate-limit params: h0=3D800124, h1=3D800267, a=3D500k, a_rem=
aining=3D100k.</div><div><br></div></div><div>This transaction t2a attempts=
 to shift the epoch forward by 20 blocks such that it starts at 800124 inst=
ead of 800144. Shifting the epoch forward like this must not be allowed bec=
ause 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 200k at 800100 (epoch 1: total: 200k);</div><div>t2a: =
spend 400k at 800200 (epoch 2: total: 400k);</div><div>t3a: spend 100k at 8=
00201 (epoch 2: total: 500k);</div><div>t4a: spend 500k at 800268 (epoch 2:=
 total: 1000k, overspending for epoch 2).</div><div><br></div><div>Specifyi=
ng the rate-limiting parameters explicitly at every transaction allows the =
user to tighten the spending limit by setting tighter limits or for instanc=
e by setting a_remainder to 0 if they wish to enforce not spending more dur=
ing an epoch. A second advantage of explicitly specifying the four rate-lim=
iting parameters with each transaction is that it allows the system to full=
y validate the transaction without having to consider any previous transact=
ions within an epoch.</div><div><br></div><div>I will stop here because I w=
ould like to gauge interest in this idea first before continuing work on ot=
her 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 cannot 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>

--0000000000009418aa05c89040a3--