Author: Billy Tetrud 2021-08-02 04:40:47
Published on: 2021-08-02T04:40:47+00:00
A proposal has been made to implement 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 for rate-limiting transactions, which could be implemented to reduce the risk of theft or mistake. Two use cases have been identified for this: enabling a user to add additional protection to their funds by rate-limiting the amount they are able to send during a certain period (measured in blocks) and allowing exchanges to rate-limit addresses containing large amounts of bitcoin, adding warm- or hot-wallet functionality to a cold-storage address. In a typical setup, multisig would be used such that the user has two sets of private keys to their encumbered address. One set allows 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 parameters that define in what way an output is rate-limited are described as follows: 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; an amount "a_remaining" (in satoshi) indicating the maximum amount that is allowed to be sent within the current epoch.For rate-limiting to work, any change output created by a transaction from a rate-limited address must itself be rate-limited as well. Three options are suggested for connecting change addresses with the original address to ensure they share the same rate limit. The simplest option is to always send change back to the same address, but this exposes the public key of an address. Another option is to specify connected addresses in the output, but this has an edge case where one of the addresses wouldn't be able to specify all the addresses that it should be connected with. The final option is to specify that rate limits follow a certain output. The proposal suggests that the cost of carrying around and checking these rate limits should be very small, ideally only a very small amount of data carried around in the UTXO set, and be very cheap to verify when the opcode comes up. It is suggested that such an opcode should only be able to track rate-limits over short spans, like a month or less, and that allowing the user to specify an arbitrary window over which to track a rate-limit would probably open up a DOS vector or other node resource usage abuse attacks. The proposal includes examples of transactions and rate-limiting parameters and describes the need for validations to ensure that the parameters are not violated. The author plans to gauge interest in this idea before continuing work on other aspects, including 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:28:09.125570+00:00