From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1950BC000E for ; Wed, 4 Aug 2021 10:49:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id E358D40665 for ; Wed, 4 Aug 2021 10:48:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIR46RsFRmOp for ; Wed, 4 Aug 2021 10:48:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by smtp4.osuosl.org (Postfix) with ESMTPS id CD04740667 for ; Wed, 4 Aug 2021 10:48:56 +0000 (UTC) Received: by mail-io1-xd2e.google.com with SMTP id d22so1837918ioy.11 for ; Wed, 04 Aug 2021 03:48:56 -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=KRTMoH5vAoYdfTFG/5WFUXTNxWNJo7DvO99yNUhfGRc=; b=WYfrLr1erD/ITpHdl5c/uFqFaht+d39PVt1f2Jz59bT/PS/eEx18Ff2n731XGXx9B6 XvFZ2wvKv6q6CZV9O67xHq17yqVKgIw6JGukn4caeHANQhr8UsctEnmqZEqsmB1dgueW lmZfQqzb3bfEcuOed5/xqwvlczAnWvsdFoAasKHYlCmCrrZCY7VvgC5a2qwUN8o1AFUl gCWQJ+8wRji7NBcCSuC6LRXfSSIX3UPRp8uzXsvXlAHtgeNZUNLERfKJ+TxoZnsmzdCV WJ47mzPuopKnXPVFUvIZhb8u1zfT8ebtylSkZH9rN33zUVfeUl7R0GHo+rzFxcQa63FC 88Yw== 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=KRTMoH5vAoYdfTFG/5WFUXTNxWNJo7DvO99yNUhfGRc=; b=GBA//cUt510f3kPOd++vGzBcZ1487hIHJeDO1XpFhbW19g99uq37X7nixTNDrSY3Ey q6/BWqUXl279+Ez8FIvU8Nc4eZVxSpbVT6CaKAMnu/IGhN5YThuR1mDVcu97uRRXt5hQ GDKARWNADl7DRhAKJ4r1IMfY/XqmOPQyhqy2aqt+PWkUyy0yva847TDubSDTbvySm9Nt J5g4RwDVXB2JCxJ/LGdB9O3aSRcRZJHWnW+R8Acvy94x6rl6ORGFcE+6PP4mWZh52O7v tmQf5dvcXysITKRc5Hev7f4FEvTFxQo83qulSTvn99CvKzZ8cNCsSy7U6Ef7UPXRM8e1 3Law== X-Gm-Message-State: AOAM533qmtXOph1w+NWlIAv0EpPur0swYdGBF8Zmkw8ljHElJwesqKDZ aLcnL28e45YF40hLNSO2EAF5/NZ5bqDM+lLpUadJU1GjX64= X-Google-Smtp-Source: ABdhPJxV1g6Rs3ZT/IpgiwCcEuxyqm0tHnw5s2NFK3E5iQ5fq5WYJB7Rc86hXUZBmRDBaUWfXiG1dfv71Dp6fPGPu98= X-Received: by 2002:a05:6638:974:: with SMTP id o20mr10287393jaj.10.1628074135945; Wed, 04 Aug 2021 03:48:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zac Greenwood Date: Wed, 4 Aug 2021 12:48:44 +0200 Message-ID: To: Billy Tetrud Content-Type: multipart/alternative; boundary="0000000000008a896c05c8b98cf6" X-Mailman-Approved-At: Wed, 04 Aug 2021 12:09:47 +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: Wed, 04 Aug 2021 10:49:03 -0000 --0000000000008a896c05c8b98cf6 Content-Type: text/plain; charset="UTF-8" > 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 spend 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 may 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 the 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 as 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 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 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-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 for simplicity, we demand that a transaction which introduces rate-limiting must 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-limited, then there must be only a single (rate-limited) output (and no second or change 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 => tx1 must have only a single output which will become rate-limited; params: tx1_epochStart=800001, tx1_epochEnd=800100, tx1_limit=200k, tx1_remain=200k; => 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-limit a set of inputs, so it has a single 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=803001, chg2a_epochEnd=803100; chg2a_limit=200k, chg2a_remain=150k. 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: => 1. the epoch does not become smaller than 100 blocks [(chg2a_epochEnd - chg2a_epochStart) >= (tx1_epochEnd - tx1_epochStart)] => 2. tx1_limit has not been increased (ch2a_limit <= tx1_limit) => 3. the amount spent (50k sats) does not exceed tx1_remain AND does not exceed chg2a_limit; => 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=808101, chg2b_epochEnd=808250; chg2b_limit=10k, chg2b_remain=0. These params are allowed because: => 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 the original rate-limit; => 2. the limit (chg2b_limit) has been decreased to 10k sats, further restricting the maximum amount allowed to be spent within the current and any subsequent epochs; => 3. the amount spent (10k sats) does not exceed tx1_remain AND does not exceed chg2b_limit; => 4. chg2b_remain has been 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 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 subsequent rate-limited transaction tx3b. This transaction tx3b must again be accompanied by params that do not violate the rate-limit as defined by the 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 spent 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 and 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 lack 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 specifying > 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 would > seem to make it a lot more difficult to use for certain types of wallets > (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 simply 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 3rd 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, for one > because of usability reasons. If each opcode has its own quirks that are > 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 > wonder how to get a receiving address and how they can ask people to send > money into their wallet) or require a lot of technical complexity in > applications (eg to support something like cooperatively connecting with > 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 save > 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 someone > 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 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 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 >>> >> --0000000000008a896c05c8b98cf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Ah I see, this is all limited t= o 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:

epoc= h1 (800101 - 800200): spend 120k in block 800140. Remaining for epoch1: 80k= ;
epoch1 (800101 - 800200): spend another 60k in block 800195. Re= maining 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 spend 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 bl= ocks a total of 340k sats was spent. This may seem to violate the 200k limi= t per 100 blocks, but this is the result of using a per-epoch limit. This a= llows a maximum of 400k to be spent in 2 blocks llke so: 200k in the last b= lock of an epoch and another 200k in the first block of the next epoch. How= ever this is inconsequential for the intended goal of rate-limiting which i= s to enable small spends over time from a large amount and to prevent theft= of a large amount with a single transaction.

To e= xplain the proposed design more clearly, I have renamed the params as follo= ws:

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 all= owed to be spent within the current epoch (was: a);
remain: the r= emaining amount allowed to be spent within the current epoch (was: a_remain= ing);

Also, to illustrate that the params are spec= ific to a transaction, I will hence precede the param with the transaction = name like so:
tx8_limit, tx31c_remain, tx42z_epochStart, ... etc.=

For simplicity, only transactions with no more th= an one rate-limited input are considered, and with no more than two outputs= : one rate-limited change output, and a normal (not rate-limited) output.

Normally, a simple transaction generates two ou= tputs: one for a payment to a third party and one for the change address. A= gain for simplicity, we demand that a transaction which introduces rate-lim= iting must have only a single, rate-limited output. The validation rule mig= ht be: if a transaction 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 change output).

Consider rat= e limiting transactions tx1 having one or more normal (non rate-limited) in= puts:

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_epochS= tart=3D800001, tx1_epochEnd=3D800100, tx1_limit=3D200k, tx1_remain=3D200k;<= /div>
=3D> This defines that an epoch has 100 blocks and no more tha= n 200k sats may be spent in any one epoch. Within the current epoch, 200k s= ats may still be spent.

This transaction begins to= rate-limit a set of inputs, so it has a single rate-limited output.
<= /div>
Let's explore transactions that have the output of tx1 as the= ir input. I will denote the output of tx1 as "out1".
tx2a has out1 as its only input;
tx2a spends 50k sat= s and gets included at block height 803050;
tx2a specifies the fo= llowing params for its change output "chg2a":
chg2a_epo= chStart=3D803001, chg2a_epochEnd=3D803100;
chg2a_limit=3D200k, ch= g2a_remain=3D150k.

To enforce rate-limiting, the s= ystem must validate the params of the change output chg2a to ensure that ov= erspending is not allowed.

The above params are al= lowed because:
=3D> 1. the epoch does not become smaller than = 100 blocks [(chg2a_epochEnd - chg2a_epochStart) >=3D (tx1_epochEnd - tx1= _epochStart)]
=3D> 2. tx1_limit has not been increased (ch2a_l= imit <=3D tx1_limit)
=3D> 3. the amount spent (50k sats) do= es 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:<= /div>

tx2b has out1as its only input;
tx2= b spends 8k sats and gets included at block height 808105;
tx2b s= pecifies the following params for its change output "chg2b":
chg2b_epochStart=3D808101, chg2b_epochEnd=3D808250;
chg2b_l= imit=3D10k, chg2b_remain=3D0.

These params are= allowed because:
=3D> 1. the epoch does not become smalle= r than100 blocks. It is fine to increase the epoch to 150 blocks because it= does not enable exceeding the original rate-limit;
=3D> 2. th= e limit (chg2b_limit) has been decreased to 10k sats, further restricting t= he maximum amount allowed to be spent within the current and any subsequent= epochs;
=3D> 3. the amount spent (10k sats) does not exceed t= x1_remain AND does not exceed chg2b_limit;
=3D> 4. chg2b_remai= n has been set to zero, meaning that within the current epoch (block height= 808101 to and including 808250), tx2b cannot be used as a spending input t= o any transaction.

Starting from block heigh= t 808251, a new epoch will start and the rate-limited output of tx2b may ag= ain be used as an input for a subsequent rate-limited transaction tx3b. Thi= s transaction tx3b must again be accompanied by params that do not violate = the rate-limit as defined by the params of tx2b and which are stored with o= utput out2b. So, the epoch of tx3b must be at minimum 150 blocks, the maxim= um that is allowed to be spent per epoch is at most 10k sats, and chg3b_rem= ain must be decreased by at least the amount spent by tx3b.

<= /div>
From the above, the rate-limiting mechanics should hopefully be c= lear and full set of validation rules could be defined in a more generalize= d way with little additional effort.

Note that I c= onveniently avoided talking about how to represent the parameters within tr= ansactions or outputs, simply because I currently lack enough understanding= to reason about this. I am hoping that others may offer help.
Zac


<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 3, 2021 at 8:12 PM Billy T= etrud <billy.tetrud@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">> To enable more straightforward validation logic.
&= gt; within the current epoch

Ah I see, this is all= limited to within a single epoch. I think that sufficiently limits the win= dow of time in which nodes have to store information for rate limited outpu= ts. However, I don't see how specifying block ranges simplifies the log= ic - 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 would seem to make it a lot more d= ifficult to use for certain types of wallets (eg cold wallets).=C2=A0
=

I think I see the logic of your 'remaining' par= ameter there. If you start with a single rate-limited input, you can split = that into many outputs, only one of which have a 'remaining' balanc= e. The rest can simply remain unspendable for the rest of the epoch. That w= ay these things don't need to be tied together. However, that doesn'= ;t solve the problem of 3rd parties being able to send money into the walle= t.=C2=A0

> I don't believe that the margina= l 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 norm= al transactions, for one because of usability reasons. If each opcode has i= ts own quirks that are not intuitively related to their purpose (eg if a ra= te-limited wallet 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 as= k people to send money into their wallet) or require a lot of technical com= plexity in applications (eg to support something like cooperatively connect= ing with their wallet so that a transaction can be made that creates a new = single-output=C2=A0for the wallet). A little complexity in this opcode can = save a lot of external complexity here I think.=C2=A0

<= div>> my understanding of Bitcoin is way too low to be able to write a B= IP and do the implementation


On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw@gmail.com&g= t; wrote:
[Note: I've moved your reply to the newly started thread]
Hi Billy,

Thank you for your kind and e= ncouraging 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.
<= div>
You mention= ed 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 inp= ut 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=C2=A0800100;
Rate-limit params: h0=3D8000= 00, h1=3D800143, a=3D500k, a_remaining=3D300k;

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

Note how transact= ion t2 re-specifies the rate-limiting parameters. Validation must ensure th= at the re-specified parameters are within bounds, i.e., do not allow more s= pending per epoch than the rate-limiting parameters of its input address a2= . Re-specifying the rate-limiting parameters offers the flexibility to furt= her restrict spending, or to disable any additional spending within the cur= rent epoch by setting a_remaining to zero.

Re= sult:
Value at destination address: 400k sats;
Rate lim= iting params at destination address: none;
Value at change addres= s 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 syste= m is able to verify the validity of a transaction without having to conside= r any transactions that precede its inputs. As a side-note, doing away with= this design principle would however enable more sophisticated rate-limitin= g (such as rate-limiting per sliding window instead of rate-limiting per ep= och having a fixed start and end block), but while at the same time reducin= g the size of per rate-limiting transaction (because it would enable specif= ying the rate-limiting parameters more space-efficiently). To test the wate= rs and to keep things relatively simple, I chose not to go into this enhanc= ed form of rate-limiting.

I haven't gone into = how to process a transaction having multiple rate-limited inputs. The easie= st 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 transact= ions having multiple rate-limited inputs by creating multiple rate-limited = change addresses. However at first glance I don't believe that the marg= inal added functionality would justify the increased implementation complex= ity.

= =C2=A0I'd be interested in seeing you write a BIP for this.

Thank you, but sadly my understanding of Bitcoin is wa= y too low to be able to write a BIP and do the implementation. However I se= e tremendous value in this functionality. Favorable feedback of the list re= garding the usefulness and the technical feasibility of rate-limiting funct= ionality 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:
[Resubmi= tting to list with minor edits. My previous submission ended up inside an e= xisting 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 o= f 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 per= iod (measured in blocks). A typical use case might be a user that intends t= o 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 in= tervene to prevent further thefts.

UC2: exchanges = may wish to rate-limit addresses containing large amounts of bitcoin, addin= g warm- or hot-wallet functionality to a cold-storage address. This would e= nable an exchange to drastically reduce the number of times a cold wallet m= ust be accessed with private keys that give access to the full amount.

In a typical setup, I'd envision using multisig su= ch that the user has two sets of private keys to their encumbered address (= with a "set" of keys meaning "one or more" keys). One s= et 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.
<= br>
The parameters that define in what way an output is rate-limi= ted might be defined as follows:

Param 1: a block = height "h0" indicating the first block height of an epoch;
<= div>
Param 2: a block height "h1" indicating the last block h= eight of an epoch;
Param 3: an amount "a" in satoshi in= dicating 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_rema= ining) of (800000, 800143, 500k, 500k). These parameters define that the ad= dress is rate-limited to sending a maximum of 500k sats in the current epoc= h that starts at block height 800000 and ends at height 800143 (or about on= e 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 minimum= 100m / 500k =3D 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 shou= ld retain the option to transact the entire amount using a second (set of) = private key(s).

For rate-limiting to work, any cha= nge output created by a transaction from a rate-limited address must itself= be rate-limited as well. For instance, expanding on the above example, ass= ume that the user spends 200k sats from a rate-limited address a1 containin= g 100m sats:

Start situation:
At block h= eight 800000: rate-limited address a1 is created;
Value of a1: 10= 0.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=3D= 300k.

Result:
Value at destination addre= ss: 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_remainin= g=3D300k.

In order to properly enforce rate limiti= ng, the change address must be rate-limited such that the original rate lim= it of 500k sats per 144 blocks cannot be exceeded. In this example, the cha= nge address a2 were given the same rate limiting parameters as the transact= ion that served as its input. As a result, from block 800100 up until and i= ncluding 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=A0800100;
Rate-limit params: h0= =3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k;

<= div>Transaction t2:
Included at block height 800200
Spe= nd: 400k=C2=A0+ fees.
Rate-limiting params: h0=3D800144, h1=3D800= 287, a=3D500k, a_remaining=3D100k.

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

Tr= ansaction t2 is allowed because it falls within the next epoch (running fro= m 800144 to 800287) so a spend of 400k does not violate the constraint of 5= 00k per epoch.

As could be seen, the rate limiting= parameters are part of the transaction and chosen by the user (or their wa= llet). This means that the parameters must be validated to ensure that they= do not violate the intended constraints.

For inst= ance, this transaction should not be allowed:
a2: 99.8 sats = at height=C2=A0800100;
Rate-limit params of a2: h0=3D800000, h1= =3D800143, a=3D500k, a_remaining=3D300k;

Transacti= on t2a:
Included at block height 800200;
Spend: 400k=C2= =A0+ fees;
Rate-limit params: h0=3D800124, h1=3D800267, a=3D= 500k, a_remaining=3D100k.

This transaction t= 2a 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: spen= d 100k at 800201 (epoch 2: total: 500k);
t4a: spend 500k at 80026= 8 (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 spendi= ng more during an epoch. A second advantage of explicitly specifying the fo= ur rate-limiting parameters with each transaction is that it allows the sys= tem to fully validate the transaction without having to consider any previo= us 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 ca= nnot spend more than the sum of their individual limits.

Zac
--0000000000008a896c05c8b98cf6--