Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0A909C000E for ; Thu, 5 Aug 2021 14:22:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0584E4033A for ; Thu, 5 Aug 2021 14:22:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_FONT_LOW_CONTRAST=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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrli2lEfn4fG for ; Thu, 5 Aug 2021 14:22:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) by smtp2.osuosl.org (Postfix) with ESMTPS id DC5FB402F0 for ; Thu, 5 Aug 2021 14:22:24 +0000 (UTC) Received: by mail-io1-xd29.google.com with SMTP id h1so6900161iol.9 for ; Thu, 05 Aug 2021 07:22:24 -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=8oRhKaDHVr2ESW9Gcja/XV6otc4TWcn9LI4ylPhD3wI=; b=ChuzEwPmAbskAqnCftOts0zRgRnPeRixWQ9fXJadK7gJtSGJRvBQcBHIEceGb53sJK oNGumyJqMjWX5Mjf5cyjJSQZmBMR+PRH8xct7SaYrUuLzkASieTQ0N90QyG38ejfh0Y9 VBtRy5BYyZObLdScfafc6ItylrnrdkJ5/keQBx48OAwp2vgFiVJP6WrOtGq2Btq1YBf9 TZItlX4mhqW3UrDFen7mUFQTlaq3Sr+25Cr7vEeCZ1Y02cN8jFXYbmrS/pXL1GOUQDOA YH3FHzJEaES8e0W8kiUTs10tDtVfHTVuVttYh1cfLc4kymA4/9ljUfpwLzJtK+vNstpU LMQg== 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=8oRhKaDHVr2ESW9Gcja/XV6otc4TWcn9LI4ylPhD3wI=; b=jcyLe28mzvGHotEKEotMpnqaxyPmu9Kgqp/gNYvDoxow4iKi+wcWqb9uqOR+KED5xm uuGwbWwpOKuwjyAofZBMm5PK7s5VIOziHh7Nz+BVVyTR/77fHQR/CoC92tUagrHINfNs vVsJh+itYcPzsjBLtP8soY1ZR71YUKiyUX7jdt+O7mByyKtbL1WpcSl8aA/nm/i9oEHJ 2KK11tdKWV9mwvoPzLCdILpkwnaA57WAaOeIlemRLtnnIojmEPWwD61x4JbZ1Jv0WWs7 +BX0h0EplDwQlSU3cegQWACXaOZOWk91eiva+GiSFAyCgrE0Nn4GkECb5YFD+2/VEacJ S9vQ== X-Gm-Message-State: AOAM531anPXSfvTl5ikXV+ewIKq5UZhd8H/SDhjm2ahFV8mI0yz4CR1E cPUlw6IL7C3ElAGPME3FytBpBHQ+iHFtS0maQx8= X-Google-Smtp-Source: ABdhPJyxZLkRqcEHfk6xMVe8SIxXqOvSfPq3wa0xHXDhke3tYxroOb13bPRoA4ihS21Ypds8id3K7k/ZJZURTZhp+Yc= X-Received: by 2002:a5d:8d1a:: with SMTP id p26mr74871ioj.178.1628173343413; Thu, 05 Aug 2021 07:22:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zac Greenwood Date: Thu, 5 Aug 2021 16:22:12 +0200 Message-ID: To: Billy Tetrud Content-Type: multipart/alternative; boundary="000000000000c45a3e05c8d0a514" X-Mailman-Approved-At: Thu, 05 Aug 2021 15:06:42 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 14:22:28 -0000 --000000000000c45a3e05c8d0a514 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Billy, > It sounds like you're proposing an opcode No. I don=E2=80=99t have enough knowledge of Bitcoin to be able to tell how= (and if) rate-limiting can be implemented as I suggested. I am not able to reason about opcodes, so I kept my description at a more functional level. > I still don't understand why its useful to specify those as absolute block heights I feel that this a rather uninteresting data representation aspect that=E2= =80=99s not worth going back and forth about. Sure, specifying the length of the epoch may also be an option, although at the price of giving up some functionality, and without much if any gains. By explicitly specifying the start and end block of an epoch, the user has more flexibility in shifting the epoch (using alternate values for epochStart and epochEnd) and simultaneously increasing the length of an epoch. These seem rather exotic features, but there=E2=80=99s no harm in re= taining them. > if you have a UTXO encumbered by rateLimit(epochStart =3D 800100, epochEn= d =3D 800200, limit =3D 100k, remain =3D 100k), what happens if you don't spe= nd that UTXO before block 800200? The rate limit remains in place. So if this UTXO is spent in block 900000, then at most 100k may be spent. Also, the new epoch must be at least 100 blocks and remain must correctly account for the actual amount spent. > This is how I'd imagine creating an opcode like this: > rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats) This would require the system to bookkeep how much was spent since the first rate-limited output. It is a more intuitive way of rate-limiting but it may be much more difficult to implement, which is why I went with the epoch-based rate limiting solution. In terms of functionality, I believe the two solutions are nearly identical for all practical purposes. Your next section confuses me. As I understand it, using an address as input for a transaction will always spends the full amount at that address. That=E2=80=99s why change addresses are required, no? If Bitcoin were able = to pay exact amounts then there wouldn=E2=80=99t be any need for change outputs. Zac On Thu, 5 Aug 2021 at 08:39, Billy Tetrud wrote: > > A maximum amount is allowed to be spent within EVERY epoch. > > It sounds like you're proposing an opcode that takes in epochStart and > epochEnd as parameters. I still don't understand why its useful to specif= y > those as absolute block heights. You mentioned that this enables more > straightforward validation logic, but I don't see how. Eg, if you have a > UTXO encumbered by rateLimit(epochStart =3D 800100, epochEnd =3D 800200, = limit > =3D 100k, remain =3D 100k), what happens if you don't spend that UTXO bef= ore > block 800200? Is the output no longer rate limited then? Or is the opcode > calculating 800200-800100 =3D 100 and applying a rate limit for the next > epoch? If the first, then the UTXO must be spent within one epoch to rema= in > rate limited. If the second, then it seems nearly identical to simply > specifying window=3D100 as a parameter instead of epochStart and epochEnd= . > > > then there must be only a single (rate-limited) output > > This rule would make transactions tricky if you're sending money into > someone else's wallet that may be rate limited. If the requirement is tha= t > only you yourself can send money into a rate limited wallet, then this > point is moot but it would be ideal to not have such a requirement. > > This is how I'd imagine creating an opcode like this: > > rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats) > > This would define that the epoch is 1 day's worth of blocks. This would > evenly divide bitcoin's retarget period and so each window would start an= d > end at those dividing lines (eg the first 144 blocks of the retargetting > period, then the second, then the third, etc). > > When this output is spent, it ensures that there's a maximum of 100k sats > is sent to addresses other than the originating address. It also records > the amount spent in the current 144 block window for that address (eg by > simply recording the already-spent amount on the resulting UTXO and havin= g > an index that allows looking up UTXOs by address and adding them up). Tha= t > way, when any output from that address is spent again, if a new 144 block > window has started, the limit is reset, but if its still within the same > window, the already-spent amounts for UTXOs from that address are added u= p > and subtracted from the limit, and that number is the remaining limit a > subsequent transaction needs to adhere to. > > This way, 3rd party could send transactions into an address like this, an= d > multiple outputs can be combined and used to spend to arbitrary outputs (= up > to the rate limit of course). > > On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood wrote: > >> > Ah I see, this is all limited to within a single epoch. >> >> No, that wouldn't be useful. A maximum amount is allowed to be spent >> within EVERY epoch. >> >> Consider an epoch length of 100 blocks with a spend limit of 200k per >> epoch. The following is allowed: >> >> epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for >> epoch1: 80k; >> epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining >> for epoch1: 20k; >> epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for >> epoch2: 40k. >> >> Since the limit pertains to each individual epoch, it is allowed to spen= d >> up to the full limit at the start of any new epoch. In this example, the >> spending was as follows: >> >> 800140: 120k >> 800195: 60k >> 800201: 160k. >> >> Note that in a span of 62 blocks a total of 340k sats was spent. This ma= y >> seem to violate the 200k limit per 100 blocks, but this is the result of >> using a per-epoch limit. This allows a maximum of 400k to be spent in 2 >> blocks llke so: 200k in the last block of an epoch and another 200k in t= he >> first block of the next epoch. However this is inconsequential for the >> intended goal of rate-limiting which is to enable small spends over time >> from a large amount and to prevent theft of a large amount with a single >> transaction. >> >> To explain the proposed design more clearly, I have renamed the params a= s >> follows: >> >> epochStart: block height of first block of the current epoch (was: h0); >> epochEnd: block height of last block of the current epoch (was: h1); >> limit: the maximum total amount allowed to be spent within the current >> epoch (was: a); >> remain: the remaining amount allowed to be spent within the current epoc= h >> (was: a_remaining); >> >> Also, to illustrate that the params are specific to a transaction, I wil= l >> hence precede the param with the transaction name like so: >> tx8_limit, tx31c_remain, tx42z_epochStart, ... etc. >> >> For simplicity, only transactions with no more than one rate-limited >> input are considered, and with no more than two outputs: one rate-limite= d >> change output, and a normal (not rate-limited) output. >> >> Normally, a simple transaction generates two outputs: one for a payment >> to a third party and one for the change address. Again for simplicity, w= e >> demand that a transaction which introduces rate-limiting must have only = a >> single, rate-limited output. The validation rule might be: if a transact= ion >> has rate-limiting params and none of its inputs are rate-limited, then >> there must be only a single (rate-limited) output (and no second or chan= ge >> output). >> >> Consider rate limiting transactions tx1 having one or more normal (non >> rate-limited) inputs: >> >> tx1 gets included at block height 800004; >> The inputs of tx1 are not rate-limited =3D> tx1 must have only a single >> output which will become rate-limited; >> params: tx1_epochStart=3D800001, tx1_epochEnd=3D800100, tx1_limit=3D200k= , >> tx1_remain=3D200k; >> =3D> This defines that an epoch has 100 blocks and no more than 200k sat= s >> may be spent in any one epoch. Within the current epoch, 200k sats may >> still be spent. >> >> This transaction begins to rate-limit a set of inputs, so it has a singl= e >> rate-limited output. >> Let's explore transactions that have the output of tx1 as their input. I >> will denote the output of tx1 as "out1". >> >> tx2a has out1 as its only input; >> tx2a spends 50k sats and gets included at block height 803050; >> tx2a specifies the following params for its change output "chg2a": >> chg2a_epochStart=3D803001, chg2a_epochEnd=3D803100; >> chg2a_limit=3D200k, chg2a_remain=3D150k. >> >> To enforce rate-limiting, the system must validate the params of the >> change output chg2a to ensure that overspending is not allowed. >> >> The above params are allowed because: >> =3D> 1. the epoch does not become smaller than 100 blocks [(chg2a_epochE= nd >> - chg2a_epochStart) >=3D (tx1_epochEnd - tx1_epochStart)] >> =3D> 2. tx1_limit has not been increased (ch2a_limit <=3D tx1_limit) >> =3D> 3. the amount spent (50k sats) does not exceed tx1_remain AND does = not >> exceed chg2a_limit; >> =3D> 4. chg2a_remain" is 50k sats less than chg2a_limit. >> >> A transaction may also further constrain further spending like so: >> >> tx2b has out1as its only input; >> tx2b spends 8k sats and gets included at block height 808105; >> tx2b specifies the following params for its change output "chg2b": >> chg2b_epochStart=3D808101, chg2b_epochEnd=3D808250; >> chg2b_limit=3D10k, chg2b_remain=3D0. >> >> These params are allowed because: >> =3D> 1. the epoch does not become smaller than100 blocks. It is fine to >> increase the epoch to 150 blocks because it does not enable exceeding th= e >> original rate-limit; >> =3D> 2. the limit (chg2b_limit) has been decreased to 10k sats, further >> restricting the maximum amount allowed to be spent within the current an= d >> any subsequent epochs; >> =3D> 3. the amount spent (10k sats) does not exceed tx1_remain AND does = not >> exceed chg2b_limit; >> =3D> 4. chg2b_remain has been set to zero, meaning that within the curre= nt >> epoch (block height 808101 to and including 808250), tx2b cannot be used= as >> a spending input to any transaction. >> >> Starting from block height 808251, a new epoch will start and the >> rate-limited output of tx2b may again be used as an input for a subseque= nt >> rate-limited transaction tx3b. This transaction tx3b must again be >> accompanied by params that do not violate the rate-limit as defined by t= he >> params of tx2b and which are stored with output out2b. So, the epoch of >> tx3b must be at minimum 150 blocks, the maximum that is allowed to be sp= ent >> per epoch is at most 10k sats, and chg3b_remain must be decreased by at >> least the amount spent by tx3b. >> >> From the above, the rate-limiting mechanics should hopefully be clear an= d >> full set of validation rules could be defined in a more generalized way >> with little additional effort. >> >> Note that I conveniently avoided talking about how to represent the >> parameters within transactions or outputs, simply because I currently la= ck >> enough understanding to reason about this. I am hoping that others may >> offer help. >> >> Zac >> >> >> On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud >> wrote: >> >>> > To enable more straightforward validation logic. >>> > within the current epoch >>> >>> Ah I see, this is all limited to within a single epoch. I think that >>> sufficiently limits the window of time in which nodes have to store >>> information for rate limited outputs. However, I don't see how specifyi= ng >>> block ranges simplifies the logic - wouldn't this complicate the logic = with >>> additional user-specified constraints? It also prevents the output from >>> being able to be rate limited over the span of multiple epochs, which w= ould >>> seem to make it a lot more difficult to use for certain types of wallet= s >>> (eg cold wallets). >>> >>> I think I see the logic of your 'remaining' parameter there. If you >>> start with a single rate-limited input, you can split that into many >>> outputs, only one of which have a 'remaining' balance. The rest can sim= ply >>> remain unspendable for the rest of the epoch. That way these things don= 't >>> need to be tied together. However, that doesn't solve the problem of 3r= d >>> parties being able to send money into the wallet. >>> >>> > I don't believe that the marginal added functionality would justify >>> the increased implementation complexity >>> >>> Perhaps, but I think there is a lot of benefit in allowing these kinds >>> of things to operate as similarly as possible to normal transactions, f= or >>> one because of usability reasons. If each opcode has its own quirks tha= t >>> are not intuitively related to their purpose (eg if a rate-limited wall= et >>> had no way to get a receiving address), it would confuse end-users (eg = who >>> wonder how to get a receiving address and how they can ask people to se= nd >>> money into their wallet) or require a lot of technical complexity in >>> applications (eg to support something like cooperatively connecting wit= h >>> their wallet so that a transaction can be made that creates a new >>> single-output for the wallet). A little complexity in this opcode can s= ave >>> a lot of external complexity here I think. >>> >>> > my understanding of Bitcoin is way too low to be able to write a BIP >>> and do the implementation >>> >>> You might be able to find people willing to help. I would be willing to >>> help write the BIP spec. I'm not the right person to help with the >>> implementation, but perhaps you could find someone else who is. Even if= the >>> BIP isn't adopted, it could be a starting point or inspiration for some= one >>> else to write an improved version. >>> >>> On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood wrote: >>> >>>> [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 windo= w (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 rat= e >>>>> 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-limite= d >>>> input. So, a transaction that has a rate-limited input is only valid i= f 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=3D800000, h1=3D800143, a=3D500k, a_remaining=3D3= 00k; >>>> >>>> Transaction t2: >>>> Included at block height 800200 >>>> Spend: 400k + fees. >>>> Rate-limiting params: h0=3D800144, h1=3D800287, a=3D500k, a_remaining= =3D100k. >>>> >>>> Note how transaction t2 re-specifies the rate-limiting parameters. >>>> Validation must ensure that the re-specified parameters are within bou= nds, >>>> 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=3D800144, h1=3D800287, >>>> a=3D500k, a_remaining=3D100k. >>>> >>>> As a design principle I believe it makes sense if the system is able t= o >>>> 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 e= nable >>>> specifying the rate-limiting parameters more space-efficiently). To te= st >>>> the waters and to keep things relatively simple, I chose not to go int= o >>>> 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 all= ow >>>> any transaction having more than one rate-limited input. One could ima= gine >>>> complex logic to handle transactions having multiple rate-limited inpu= ts by >>>> creating multiple rate-limited change addresses. However at first glan= ce 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 tremendou= s >>>> value in this functionality. Favorable feedback of the list regarding = the >>>> usefulness and the technical feasibility of rate-limiting functionalit= y >>>> 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 >>>> 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, t= o >>>>> implement the ability to limit the maximum amount that can be sent fr= om 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 certa= in >>>>> 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 t= he >>>>> 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 re= duce >>>>> 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 ha= s >>>>> 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 migh= t >>>>> 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 t= hat >>>>> 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 sti= ll >>>>> sendable. These rate-limiting parameters ensure that it takes at mini= mum >>>>> 100m / 500k =3D 200 transactions and 200 x 144 blocks or about 200 da= ys 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=3D800000, h1=3D800143, a=3D500k, >>>>> a_remaining=3D500k; >>>>> >>>>> Transaction t1: >>>>> Included at block height 800100; >>>>> Spend: 200k + fee; >>>>> Rate limiting params: h0=3D800000, h1=3D800143, a=3D500k, a_remaining= =3D300k. >>>>> >>>>> 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=3D800000, h1=3D800143, >>>>> a=3D500k, a_remaining=3D300k. >>>>> >>>>> In order to properly enforce rate limiting, the change address must b= e >>>>> rate-limited such that the original rate limit of 500k sats per 144 b= locks >>>>> cannot be exceeded. In this example, the change address a2 were given= the >>>>> same rate limiting parameters as the transaction that served as its i= nput. >>>>> 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 ad= dress. >>>>> >>>>> Example continued: >>>>> a2: 99.8 sats at height 800100; >>>>> Rate-limit params: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D= 300k; >>>>> >>>>> Transaction t2: >>>>> Included at block height 800200 >>>>> Spend: 400k + fees. >>>>> Rate-limiting params: h0=3D800144, h1=3D800287, a=3D500k, a_remaining= =3D100k. >>>>> >>>>> 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=3D800144, h1=3D800287, >>>>> a=3D500k, a_remaining=3D100k. >>>>> >>>>> Transaction t2 is allowed because it falls within the next epoch >>>>> (running from 800144 to 800287) so a spend of 400k does not violate t= he >>>>> 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=3D800000, h1=3D800143, a=3D500k, >>>>> a_remaining=3D300k; >>>>> >>>>> Transaction t2a: >>>>> Included at block height 800200; >>>>> Spend: 400k + fees; >>>>> Rate-limit params: h0=3D800124, h1=3D800267, a=3D500k, a_remaining=3D= 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 f= orward >>>>> like this must not be allowed because it enables spending more that t= he >>>>> 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 wi= sh to >>>>> enforce not spending more during an epoch. A second advantage of expl= icitly >>>>> 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 wor= k 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 the= ir >>>>> individual limits. >>>>> >>>>> Zac >>>>> >>>> --000000000000c45a3e05c8d0a514 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Billy,

>=C2=A0It sounds like you're pr= oposing an opcode

N= o. I don=E2=80=99t have enough knowledge of Bitcoin to be able to tell how = (and if) rate-limiting can be implemented as I suggested. I am not able to = reason about opcodes, so I kept my description at a more functional level.<= /span>

>=C2=A0I still don't understand why its=C2=A0useful = to specify those as absolute block heights

I feel that this a rather uninteresting data repres= entation aspect that=E2=80=99s not worth going back and forth about. Sure, = specifying the length of the epoch may also be an option, although at the p= rice of giving up some functionality, and without much if any gains.=

<= div dir=3D"auto">By explicitly specifying = the start and end block of an epoch, the user has more flexibility in shift= ing the epoch (using alternate values for epochStart and epochEnd) and simu= ltaneously increasing the length of an epoch. These seem rather exotic feat= ures, but there=E2=80=99s no harm in retaining them.

>= =C2=A0if you have a UTXO encumbered by rateLimit(epochStart =3D 800100, epo= chEnd =3D 800200, limit =3D 100k, remain =3D 100k), what happens if you don= 't spend that UTXO before block 800200?
<= span style=3D"color:rgb(0,0,0)">
T= he rate limit remains in place. So if this UTXO is spent in block 900000, t= hen at most 100k may be spent. Also, the new epoch must be at least 100 blo= cks and remain must correctly account for the actual amount spent.

>=C2=A0This is how I'd imagine creating an opcode like = this:

> rateLimit(windowSize =3D 144 blocks, limit =3D 100k sa= ts)

This would require the system to bookkeep how mu= ch was spent since the first rate-limited output. It is a more intuitive wa= y of rate-limiting but it may be much more difficult to implement, which is= why I went with the epoch-based rate limiting solution. In terms of functi= onality, I believe the two solutions are nearly identical for all practical= purposes.

<= /font>
Your next section confuses me. As I under= stand it, using an address as input for a transaction will always spends th= e full amount at that address. That=E2=80=99s why change addresses are requ= ired, no? If Bitcoin were able to pay exact amounts then there wouldn=E2=80= =99t be any need for change outputs.

Zac

=

On Thu, 5 Aug 2021 at 08:39, Billy Tetrud <billy.tetrud@gmail.com> wrote:
>=C2=A0 =C2=A0A maximum amount is allowed to be spent within EVERY epoch.

<= /div>
It sounds like you're proposing an opcode that takes in epoch= Start and epochEnd as parameters. I still don't understand why its=C2= =A0useful to specify those as absolute block heights. You mentioned=C2=A0th= at this enables more straightforward validation logic, but I don't see = how. Eg, if you have a UTXO encumbered by rateLimit(epochStart =3D 800100, = epochEnd =3D 800200, limit =3D 100k, remain =3D 100k), what happens if you = don't spend that UTXO before block 800200? Is the output no longer rate= limited then? Or is the opcode calculating 800200-800100 =3D 100 and apply= ing a rate limit for the next epoch? If the first, then the UTXO must be sp= ent within one epoch to remain rate limited. If the second, then it seems n= early identical to simply specifying window=3D100 as a parameter instead of= epochStart and epochEnd.

> then there must be = only a single (rate-limited) output

This rule woul= d make transactions tricky if you're sending money into someone else= 9;s wallet that may be rate limited. If the requirement is that only you yo= urself can send money into a rate limited wallet, then this point is moot b= ut it would be ideal to not have such a requirement.

This is how I'd imagine creating an opcode like this:

=
rateLimit(windowSize =3D 144 blocks, limit =3D 100k sats)
<= div>
This would define that the epoch is 1 day's worth of= blocks. This would evenly divide bitcoin's retarget period and so each= window would start and end at those dividing lines (eg the first 144 block= s of the retargetting period, then the second, then the third, etc).=C2=A0<= /div>

When this output is spent, it ensures that there&#= 39;s a maximum of 100k sats is sent to addresses other than the originating= address. It also records the amount spent in the current 144 block window = for that address (eg by simply recording the already-spent amount on the re= sulting UTXO and having an index that allows looking up UTXOs by address an= d adding them up). That way, when any output from that address is spent aga= in, if a new 144 block window has started, the limit is reset, but if its s= till within the same window, the already-spent amounts for UTXOs from that = address are added up and subtracted from the limit, and that number is the = remaining limit a subsequent transaction needs to adhere to.=C2=A0

This way, 3rd party could send transactions into an addres= s like this, and multiple outputs can be combined and used to spend to arbi= trary outputs (up to the rate limit of course).

On Wed, Aug 4, 2021 = at 3:48 AM Zac Greenwood <zachgrw@gmail.com> wrote:
> Ah I see, this is all limited to withi= n a single epoch.

No, that wouldn't be useful.= A maximum amount is allowed to be spent within EVERY epoch.

=
Consider an epoch length of 100 blocks with a spend limit of 200= k per epoch. The following is allowed:

epoch1 (800= 101 - 800200): spend 120k in block 800140. Remaining for epoch1: 80k;
=
epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining= for epoch1: 20k;
epoch2 (800201 - 800300): spend 160k in block 8= 00201. Remaining for epoch2: 40k.

Since the limit = pertains to each individual epoch, it is allowed to spend up to the full li= mit at the start of any new epoch. In this example, the spending was as fol= lows:

800140: 120k
800195: 60k
800201: 160k.

Note that in a span of 62 blocks a = total of 340k sats was spent. This may seem to violate the 200k limit per 1= 00 blocks, but this is the result of using a per-epoch limit. This allows a= maximum of 400k to be spent in 2 blocks llke so: 200k in the last block of= an epoch and another 200k in the first block of the next epoch. However th= is is inconsequential for the intended goal of rate-limiting which is to en= able small spends over time from a large amount and to prevent theft of a l= arge amount with a single transaction.

To explain = the proposed design more clearly, I have renamed the params as follows:

epochStart: block height of first block of the curren= t epoch (was: h0);
epochEnd: block height of last block of the cu= rrent epoch (was: h1);
limit: the maximum total amount allowed to= be spent within the current epoch (was: a);
remain: the remainin= g amount allowed to be spent within the current epoch (was: a_remaining);

Also, to illustrate that the params are specific to= a transaction, I will hence precede the param with the transaction name li= ke so:
tx8_limit, tx31c_remain, tx42z_epochStart, ... etc.
<= div>
For simplicity, only transactions with no more than one = rate-limited input are considered, and with no more than two outputs: one r= ate-limited change output, and a normal (not rate-limited) output.

Normally, a simple transaction generates two outputs: = one for a payment to a third party and one for the change address. Again fo= r simplicity, we demand that a transaction which introduces rate-limiting m= ust have only a single, rate-limited output. The validation rule might be: = if a transaction has rate-limiting params and none of its inputs are rate-l= imited, then there must be only a single (rate-limited) output (and no seco= nd or change output).

Consider rate limit= ing transactions tx1 having one or more normal (non rate-limited) inputs:

tx1 gets included at block height 800004;
The inputs of tx1 are not rate-limited =3D> tx1 must have only a single= output which will become rate-limited;
params: tx1_epochStart=3D= 800001, tx1_epochEnd=3D800100, tx1_limit=3D200k, tx1_remain=3D200k;
=3D> This defines that an epoch has 100 blocks and no more than 200k = sats may be spent in any one epoch. Within the current epoch, 200k sats may= still be spent.

This transaction begins to rate-l= imit a set of inputs, so it has a single rate-limited output.
Let's explore transactions that have the output of tx1 as their inpu= t. I will denote the output of tx1 as "out1".

tx2a has out1 as its only input;
tx2a spends 50k sats and g= ets included at block height 803050;
tx2a specifies the following= params for its change output "chg2a":
chg2a_epochStart= =3D803001, chg2a_epochEnd=3D803100;
chg2a_limit=3D200k, chg2a_rem= ain=3D150k.

To enforce rate-limiting, the system m= ust validate the params of the change output chg2a to ensure that overspend= ing is not allowed.

The above params are allowed b= ecause:
=3D> 1. the epoch does not become smaller than 100 blo= cks [(chg2a_epochEnd - chg2a_epochStart) >=3D (tx1_epochEnd - tx1_epochS= tart)]
=3D> 2. tx1_limit has not been increased (ch2a_limit &l= t;=3D tx1_limit)
=3D> 3. the amount spent (50k sats) does not = exceed tx1_remain AND does not exceed chg2a_limit;
=3D> 4. chg= 2a_remain" is 50k sats less than chg2a_limit.

A transaction may also further constrain further spending like so:

tx2b has out1as its only input;
tx2b spend= s 8k sats and gets included at block height 808105;
tx2b specifie= s the following params for its change output "chg2b":
c= hg2b_epochStart=3D808101, chg2b_epochEnd=3D808250;
chg2b_limit=3D= 10k, chg2b_remain=3D0.

These params are allowe= d because:
=3D> 1. the epoch does not become smaller than1= 00 blocks. It is fine to increase the epoch to 150 blocks because it does n= ot enable exceeding the original rate-limit;
=3D> 2. the limit= (chg2b_limit) has been decreased to 10k sats, further restricting the maxi= mum amount allowed to be spent within the current and any subsequent epochs= ;
=3D> 3. the amount spent (10k sats) does not exceed tx1_rema= in AND does not exceed chg2b_limit;
=3D> 4. chg2b_remain has b= een set to zero, meaning that within the current epoch (block height 808101= to and including 808250), tx2b cannot be used as a spending input to any t= ransaction.

Starting from block height 80825= 1, a new epoch will start and the rate-limited output of tx2b may again be = used as an input for a subsequent rate-limited transaction tx3b. This trans= action tx3b must again be accompanied by params that do not violate the rat= e-limit as defined by the params of tx2b and which are stored with output o= ut2b. So, the epoch of tx3b must be at minimum 150 blocks, the maximum that= is allowed to be spent per epoch is at most 10k sats, and chg3b_remain mus= t be decreased by at least the amount spent by tx3b.

From the above, the rate-limiting mechanics should hopefully be clear an= d full set of validation rules could be defined in a more generalized way w= ith little additional effort.

Note that I convenie= ntly avoided talking about how to represent the parameters within transacti= ons or outputs, simply because I currently lack enough understanding to rea= son about this. I am hoping that others may offer help.

Zac


On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud &= lt;billy.tetrud= @gmail.com> wrote:
> = To enable more straightforward validation logic.
> within the curren= t epoch

Ah I see, this is all limited to within a = single epoch. I think that sufficiently limits the window of time in which = nodes have to store information for rate limited outputs. However, I don= 9;t see how specifying block ranges simplifies the logic - wouldn't thi= s complicate the logic with additional user-specified constraints? It also = prevents the output from being able to be rate limited over the span of mul= tiple epochs, which would seem to make it a lot more difficult to use for c= ertain types of wallets (eg cold wallets).=C2=A0

I= think I see the logic of your 'remaining' parameter there. If you = start with a single rate-limited input, you can split that into many output= s, only one of which have a 'remaining' balance. The rest can simpl= y remain unspendable for the rest of the epoch. That way these things don&#= 39;t need to be tied together. However, that doesn't solve the problem = of 3rd parties being able to send money into the wallet.=C2=A0
> I don't believe that the marginal added functionality= would justify the increased implementation complexity

=
Perhaps, but I think there is a lot of benefit in allowing these kinds= of things to operate as similarly as possible to normal transactions, for = one because of usability reasons. If each opcode has its own quirks that ar= e not intuitively related to their purpose (eg if a rate-limited wallet had= no way to get a receiving address), it would confuse end-users (eg who won= der how to get a receiving address and how they can ask people to send mone= y into their wallet) or require a lot of technical complexity in applicatio= ns (eg to support something like cooperatively connecting with their wallet= so that a transaction can be made that creates a new single-output=C2=A0fo= r the wallet). A little complexity in this opcode can save a lot of externa= l complexity here I think.=C2=A0

> my understan= ding of Bitcoin is way too low to be able to write a BIP and do the impleme= ntation

You might be able to find people willing t= o help. I would be willing to help write the BIP spec. I'm not the righ= t person to help with the implementation, but perhaps you could find someon= e else who is. Even if the BIP isn't adopted, it could be a starting po= int or inspiration for someone else to write an improved version.=C2=A0

On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw@gmail.com> wrote:
[Note: I've moved your reply to the new= ly started thread]

Hi Billy,

Thank yo= u for your kind and encouraging feedback.

I don't quite understand why you'd want to define a specific sp= an of blocks for the rate limit. Why not just specify the size of the windo= w (in blocks) to rate limit within, and the limit?

To enable more straightforward validation logic.

You mentioned change addresses, however, with the parame= ters you defined, there would be no way to connect together the change addr= ess with the original address, meaning they would have completely separate = rate limits, which wouldn't work since the change output would ignore t= he previous rate limit.

The rate-limiting p= arameters must be re-specified for each rate-limited input. So, a transacti= on 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 exa= mple of a rate-limited address a2 that serves as input for transaction t2:<= /div>

a2: 99.8 sats at height=C2=A0800100;
Rate-limit params: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k= ;

Transaction t2:
Included at block heig= ht 800200
Spend: 400k=C2=A0+ fees.
Rate-limiting params= : h0=3D800144, h1=3D800287, a=3D500k, a_remaining=3D100k.
Note how transaction t2 re-specifies the rate-limiting paramete= rs. Validation must ensure that the re-specified parameters are within boun= ds, i.e., do not allow more spending per epoch than the rate-limiting param= eters of its input address a2. Re-specifying the rate-limiting parameters o= ffers the flexibility to further restrict spending, or to disable any addit= ional 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 para= ms at change address a3: h0=3D800144, h1=3D800287, a=3D500k, a_remaining=3D= 100k.

As a design principle I believe = it makes sense if the system is able to verify the validity of a transactio= n 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 inst= ead of rate-limiting per epoch having a fixed start and end block), but whi= le at the same time reducing the size of per rate-limiting transaction (bec= ause it would enable specifying the rate-limiting parameters more space-eff= iciently). 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 rat= e-limited inputs. The easiest way to handle this case is to not allow any t= ransaction having more than one rate-limited input. One could imagine compl= ex logic to handle transactions having multiple rate-limited inputs by crea= ting multiple rate-limited change addresses. However at first glance I don&= #39;t believe that the marginal added functionality would justify the incre= ased implementation complexity.

=C2=A0= 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 trem= endous value in this functionality. Favorable feedback of the list regardin= g the usefulness and the technical feasibility of rate-limiting functionali= ty would of course be an encouragement for me to descend further down the r= abbit hole.

Zac

On Sun, = Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw@gmail.com> wrote:
[Resubmitting to list with minor edits. My prev= ious submission ended up inside an existing thread, apologies.]
<= br>
Hi list,

I'd like to explore whe= ther it is feasible to implement new scripting capabilities in Bitcoin that= enable limiting the output amount of a transaction based on the total valu= e of its inputs. In other words, to implement the ability to limit the maxi= mum amount that can be sent from an address.

Two u= se cases come to mind:

UC1: enable a user to add a= dditional 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 s= weeping 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 contai= ning 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 privat= e keys to their encumbered address (with a "set" of keys meaning = "one or more" keys). One set of private keys allows only for send= ing with rate-limiting restrictions in place, and a second set of private k= eys allowing for sending any amount without rate-limiting, effectively over= riding such restriction.

The parameters that defin= e in what way an output is rate-limited might be defined as follows:
<= div>
Param 1: a block height "h0" indicating the fi= rst block height of an epoch;
Param 2: a block height "= h1" indicating the last block height of an epoch;
Param 3: a= n amount "a" in satoshi indicating the maximum amount that is all= owed to be sent in any epoch;
Param 4: an amount "a_rema= ining" (in satoshi) indicating the maximum amount that is allowed to b= e sent within the current epoch.

For example= , consider an input containing 100m sats (1 BTC) which has been rate-limite= d with parameters (h0, h1, a, a_remaining) of (800000, 800143, 500k, 500k).= These parameters define that the address is rate-limited to sending a maxi= mum of 500k sats in the current epoch that starts at block height 800000 an= d 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 parame= ters ensure that it takes at minimum 100m / 500k =3D 200 transactions and 2= 00 x 144 blocks or about 200 days to spend the full 100m sats. As noted ear= lier, in a typical setup a user should retain the option to transact the en= tire amount using a second (set of) private key(s).

For rate-limiting to work, any change output created by a transaction fro= m 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:

S= tart situation:
At block height 800000: rate-limited address a1 i= s created;
Value of a1: 100.0m sats;
Rate limiting para= ms of a1: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D500k;

Transaction t1:
Included at block height 800100;<= /div>
Spend: 200k + fee;
Rate limiting params: h0=3D800000, h= 1=3D800143, a=3D500k, a_remaining=3D300k.

Result:<= /div>
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=3D80000= 0, h1=3D800143, a=3D500k, a_remaining=3D300k.

In o= rder to properly enforce rate limiting, the change address must be rate-lim= ited such that the original rate limit of 500k sats per 144 blocks cannot b= e 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 resu= lt, 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=C2=A080010= 0;
Rate-limit params: h0=3D800000, h1=3D800143, a=3D500k, a_remai= ning=3D300k;

Transaction t2:
Included at= block height 800200
Spend: 400k=C2=A0+ fees.
Rate-limi= ting params: h0=3D800144, h1=3D800287, a=3D500k, a_remaining=3D100k.

Result:
Value at destination address:= 400k sats;
Rate limiting params at destination address: none;
Value at change address a3: 99.4m sats;
Rate limiting par= ams at change address a3: h0=3D800144, h1=3D800287, a=3D500k, a_remaining= =3D100k.

Transaction t2 is allowed because it fall= s 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 m= ust be validated to ensure that they do not violate the intended constraint= s.

For instance, this transaction should not be al= lowed:
a2: 99.8 sats at height=C2=A0800100;
Rate-l= imit params of a2: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k;<= /div>

Transaction t2a:
Included at block heigh= t 800200;
Spend: 400k=C2=A0+ fees;
Rate-limit para= ms: h0=3D800124, h1=3D800267, a=3D500k, a_remaining=3D100k.

<= /div>
This transaction t2a attempts to shift the epoch forward by= 20 blocks such that it starts at 800124 instead of 800144. Shifting the ep= och 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 wo= uld enable overspending:

t1: spend 200k at 8= 00100 (epoch 1: total: 200k);
t2a: spend 400k at 800200 (epoch 2:= total: 400k);
t3a: spend 100k at 800201 (epoch 2: total: 500k);<= /div>
t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending fo= r epoch 2).

Specifying the rate-limiting parameter= s explicitly at every transaction allows the user to tighten the spending l= imit 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 advanta= ge of explicitly specifying the four rate-limiting parameters with each tra= nsaction is that it allows the system to fully validate the transaction wit= hout 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 o= f 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 ind= ividual limits.

=
Zac
--000000000000c45a3e05c8d0a514--