Author: Billy Tetrud 2021-08-05 06:39:34
Published on: 2021-08-05T06:39:34+00:00
Zac Greenwood, a Bitcoin enthusiast, proposed the implementation of new scripting capabilities that enable limiting the output amount of a transaction based on the total value of its inputs. This functionality could be used to rate-limit the amount that an address is allowed to send during a certain period measured in blocks.The proposal suggests an opcode that takes in epochStart and epochEnd as parameters to limit the spending within every epoch. The proposed design includes defining an epoch length of 1 day's worth of blocks, evenly dividing Bitcoin's retarget period into windows. The rate-limited output ensures that only a maximum amount of satoshis is sent to addresses other than the originating address.To ensure that rate-limiting works, any change output created by a transaction from a rate-limited address must also be rate-limited. The proposed parameters that define in what way an output is rate-limited include a block height "h0" indicating the first block height of an epoch, a block height "h1" indicating the last block height of an epoch, an amount "a" in satoshi indicating the maximum amount allowed to be sent in any epoch, and an amount "a_remaining" (in satoshi) indicating the maximum amount allowed to be sent within the current epoch.For example, if an input contains 100m sats (1 BTC) rate-limited with parameters (h0, h1, a, a_remaining) of (800000, 800143, 500k, 500k), it takes at minimum 200 transactions and 200 x 144 blocks or about 200 days to spend the full 100m sats. The user has two sets of private keys to their encumbered address, one set allowing only for sending with rate-limiting restrictions in place, and a second set allowing for sending any amount without rate-limiting, effectively overriding such restriction.The proposal also discusses various examples to illustrate the rate-limiting mechanics. It explains how transactions can further constrain spending and which validation rules should be defined in a more generalized way. However, it conveniently avoids talking about how to represent the parameters within transactions or outputs, hoping that others may offer help.In this context, a user spent a total of 100k at t3a during epoch 2, bringing the total spending to 500k. Another user spent 500k at 800268 during epoch 2, taking the total spending to 1000k and resulting in overspending for the epoch. The advantage of explicitly specifying the rate-limiting parameters for each transaction is that it allows the user to tighten the spending limit or enforce not spending more during an epoch.Two use cases were identified: (1) a user who intends to hodl their bitcoin but still wishes to occasionally send small amounts and (2) exchanges may wish to rate-limit addresses containing large amounts of bitcoin. As a design principle, the system should be able to verify the validity of a transaction without having to consider any transactions that precede its inputs. However, doing away with this design principle would enable more sophisticated rate-limiting. Zac Greenwood proposed not to go into this enhanced form of rate-limiting to keep things relatively simple.The author of the message suggests gauging interest in this idea before continuing work on other aspects. Two main pieces of work include defining all validations and describing aggregate behavior of multiple rate-limited inputs, along with proof that two rate-limited addresses cannot spend more than the sum of their individual limits. Finally, the proposal emphasizes the importance of allowing these kinds of things to operate similarly to normal transactions for usability reasons.
Updated on: 2023-06-15T00:30:40.383330+00:00