Author: Zac Greenwood 2021-08-05 14:22:12
Published on: 2021-08-05T14:22:12+00:00
The context discusses the concept of rate limiting in Bitcoin transactions. Billy Tetrud and Zac Greenwood exchange emails suggesting various solutions for implementing rate limits in Bitcoin transactions. They discuss epoch-based rate-limiting, which allows for more flexibility in shifting epochs and increasing their length. They also clarify that change addresses are necessary because Bitcoin does not allow exact amounts to be paid to a transaction input address. Billy suggests an opcode that takes in window size and limit as parameters, which is more intuitive but may be harder to implement than the epoch-based solution. They then go on to discuss various scenarios involving rate-limited inputs and outputs, and how they can be validated to ensure overspending is not allowed. The proposed design involves specifying epoch start and end block heights, limit, and remain for each transaction, with a single rate-limited output.The author proposes implementing new scripting capabilities in Bitcoin that enable limiting the output amount of a transaction based on the total value of its inputs. This would allow users to add additional protection to their funds by rate-limiting the amount they are allowed to send during a certain period. Exchanges could also rate-limit addresses containing large amounts of bitcoin, adding warm- or hot-wallet functionality to a cold-storage address. 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 that is allowed to be sent in any epoch, and an amount "a_remaining" (in satoshi) indicating the maximum amount that is allowed to be sent within the current epoch. To make rate-limiting work, any change output created by a transaction from a rate-limited address must itself be rate-limited as well. The author acknowledges that they currently lack enough understanding to reason about how to represent the parameters within transactions or outputs and hopes that others may offer help. The context also explains that in order to enforce rate limiting, the change address must be limited so that the original limit of 500k sats per 144 blocks cannot be exceeded. The parameters for rate limiting are chosen by the user or their wallet and must be validated to ensure they do not violate intended constraints.An example is given where the change address has the same rate limiting parameters as the transaction that served as its input. Specifying rate-limiting parameters explicitly at every transaction allows the user to tighten the spending limit and fully validate the transaction without having to consider any previous transactions within an epoch. Two main pieces of work are mentioned for this idea: defining all validations and describing aggregate behavior of multiple (rate-limited) inputs, proof that two rate-limited addresses cannot spend more than the sum of their individual limits.
Updated on: 2023-06-15T00:35:08.558452+00:00