[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