From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id F225BC000E for ; Mon, 2 Aug 2021 04:41:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id DAF5860677 for ; Mon, 2 Aug 2021 04:41:08 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBXfO04b_wEB for ; Mon, 2 Aug 2021 04:41:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by smtp3.osuosl.org (Postfix) with ESMTPS id 79FF960652 for ; Mon, 2 Aug 2021 04:41:06 +0000 (UTC) Received: by mail-ed1-x531.google.com with SMTP id v20so8677653eda.1 for ; Sun, 01 Aug 2021 21:41:06 -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; bh=Btrg3QyzSX/pjPBDg6tiMejGld/2pMlLMeY16SyZsP4=; b=VF1eN2detN3N7CR+shOb7s+EU0O/jgRCbaXPRBUSiHqAEoGSRaWUFo3PaMmnabJG9S Lv3sd2so60GYPPIB7UUwCYyKhVjz6eYgM9bIpZeYsV2sgB8fATtytvP/gPjnLKP0hsW+ mJdR0MJ8fRdghyy61qj+94L4RbDBsd6HKxMtpvKDudRGfawLmyc3IcZ9sTF/OT348ZF4 OS/T+yfjcdwECdpkVgVwqyYsmw2IuOTjt8qvVMeJqqcVkXveIGC9+UX6R529oE+lBcoW nMKljBjnbbO6OfF5RWwQIJurw8cgOXdgaDhRG+Yr35ze2yOIWj8VRyrjda4M9tE0ypSR o/2g== 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; bh=Btrg3QyzSX/pjPBDg6tiMejGld/2pMlLMeY16SyZsP4=; b=ttTUZe5bVBrzIh2U6GF3eJTeGZGcbcBubr+UkA9EHV1io56lCKGsTBKUFF1aGxmLh7 uA7cWZn9aR7tv4c+H4nDL4ehw2akypc5QL3yggS9da8dx6H5hCF0WHL8/aS2FQzD75Zm RqVSfdhBjAg2Efh6JNVfdxBoKnAu1481D5W6tKS+J970VeGdodsQkBJEiX53MV9fBpQz +LeZVf6LPKAOyILNC6oGCXJvRm/p7ebe9nVngzGpxeF5uBP9MxrJpem0mnZ/UdYLYk8K AldwqsoMpr0RGbQr2Ng2z7L2/myB5ElBqUiZEZIbAY8evpFLljcok76WsAT8d0H+S8eW eftA== X-Gm-Message-State: AOAM532Pepxiw1MwMdGu/dQ8FUeZKDhHBMpE0QtqfgUPu+tOs6FMErVc O1u9Ho9Gi8EEGwg1N5+WXsWNc2hYlbIDZUXwnnQ= X-Google-Smtp-Source: ABdhPJzqo6ZDh9K0KDbihL5S2J6wJlj+kqIt0AuHEGw08B31A1bXoWfBQSyzGKRD8VTgl9634sPYnmc4g0x4sBV9UfM= X-Received: by 2002:a50:fb05:: with SMTP id d5mr16514737edq.5.1627879264540; Sun, 01 Aug 2021 21:41:04 -0700 (PDT) MIME-Version: 1.0 References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> In-Reply-To: From: Billy Tetrud Date: Sun, 1 Aug 2021 21:40:47 -0700 Message-ID: To: Zac Greenwood , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000004cdb6c05c88c2dc3" X-Mailman-Approved-At: Mon, 02 Aug 2021 08:02:49 +0000 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: Mon, 02 Aug 2021 04:41:09 -0000 --0000000000004cdb6c05c88c2dc3 Content-Type: text/plain; charset="UTF-8" Hey Zac, I think this could be a useful opcode. It kinda seems like UC1 and UC2 are basically the same use case: using rate-limiting to reduce risk of theft or mistake. I think this could be a helpful addition to a good wallet setup. 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? 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. I can think of the following options: A. You could always send change back to the *same* address. This is the simplest option, and the only downside I can think of is exposing the public key of an address. I'm not quite sure what the consensus is on the dangers of exposing the public key. It theoretically reduces quantum resistance a bit, but I think I read that some of taproot's mechanisms expose the bare public key, so maybe consensus has changed about that in recent years? B. Have some way to specify connected addresses in the output. This has the edge case that one of the addresses wouldn't be able to specify all the addresses that it should be connected with, because it would create a hash loop (ie if you had address A and B that should be connected, you can create address A and then specify that address B be connected to address A, but address A cannot specify its connection to B because A was created before B was created). You wouldn't want one address to be able to simply define a connection to another address, because this would open up attack vectors where people could encumber other people's addresses with rate limits connected to theirs. You could define connections based on signatures, which could be done without creating a hash loop, however it would require exposing the public keys of other addresses when you do that, at which point you might as well go with option A. C. You could specify that rate limits follow a certain output. Eg, if you create a transaction with destination output 1 and change output 2, your rate limiting opcode could specify that output 2 should inherit the rate limit. These inherited rate limits could all be connected together automatically. Another consideration is what to use for a receive-address. I would say the simplest option here is to receive at an address that contains an existing output already. If you allowed receiving at an address that contains no coins, you'd have to specify at least one other address to connect it with. This could work, but I don't see any advantage to it, since you don't gain any privacy by creating a new address if you're going to immediately programmatically tie it to the other addresses. One thing to consider is the cost of carrying around and checking these rate limits. Ideally it should be a very small amount of data carried around in the UTXO set, and be very cheap to verify when the opcode comes up. I think it would make sense for such an opcode to only be able to track rate-limits over short spans, like a month or less. Allowing the user to specify an arbitrary window over which to track a rate-limit seems like something that would probably open up a dos vector or other node resource usage abuse attacks. It might be useful enough to simply rate limit over each epoch (two weeks), but having a small set of options could also be useful (eg 1 day, 1 week, or 1 month). In any case, I'd be interested in seeing you write a BIP for this. Of course, don't take my word as community interest. I'm reasonably new to the bitcoin dev community, so definitely don't jump the gun based on my interest. On Sat, Jul 31, 2021 at 2:51 PM Zac Greenwood via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 they are able 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. > This avoids an attacker from sweeping all their funds in a single > transaction, allowing the user to become aware of the theft and intervene > to prevent further theft. > > 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 enable 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 s 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_remaning) 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. > > 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 > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000004cdb6c05c88c2dc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Zac,

I think this could = be a useful opcode. It kinda seems like UC1 and UC2 are basically=C2=A0the = same use case: using rate-limiting to reduce risk of theft or mistake. I th= ink this could be a helpful addition to a good wallet setup.=C2=A0

I don't quite understand why you'd want to define a spe= cific span of blocks for the rate limit. Why not just specify the size of t= he window (in blocks) to rate limit within, and the limit?=C2=A0

You mentioned change addresses, however, with the parameters you d= efined, there would be no way to connect together the change address with t= he original address, meaning they would have completely separate rate limit= s, which wouldn't work since the change output would ignore the previou= s rate limit. I can think of the following options:=C2=A0

A. You could always send change back to the *same* address. This is= the simplest option, and the only downside I can think of is exposing the = public key of an address. I'm not quite sure what the consensus is on t= he dangers of exposing the public key. It theoretically reduces quantum res= istance a bit, but I think I read that some of taproot's mechanisms exp= ose the bare public key, so maybe consensus has changed about that in recen= t years?

B. Have some way to specify connected add= resses in the output. This has the edge case that one of the addresses woul= dn't be able to specify all the addresses that it should be connected w= ith, because it would create a hash loop (ie if you had address A and B tha= t should be connected, you can create address A and then specify that addre= ss B be connected to address A, but address A cannot specify its connection= to B because A was created before B was created). You wouldn't want on= e address to be able to simply define a connection to another address, beca= use this would open up attack vectors where people could encumber other peo= ple's addresses with rate limits connected to theirs. You could define = connections based on signatures, which could be done without creating a has= h loop, however it would require exposing the public keys of other addresse= s when you do that, at which point you might as well go with option A.=C2= =A0

C. You could specify that rate limits follow a= certain output. Eg, if you create a transaction with destination output 1 = and change output 2, your rate limiting opcode could specify that output 2 = should inherit the rate limit. These inherited rate limits could all be con= nected together automatically.=C2=A0

Another consi= deration is what to use for a receive-address. I would say the simplest opt= ion here is to receive at an address that contains an existing output alrea= dy. If you allowed receiving at an address that contains no coins, you'= d have to specify at least one other address to connect it with. This could= work, but I don't see any advantage to it, since you don't gain an= y privacy by creating a new address if you're going to immediately prog= rammatically tie it to the other addresses.

One th= ing to consider is the cost of carrying around and checking these rate limi= ts. Ideally it should be a very small amount of data carried around in the = UTXO set, and be very cheap to verify when the opcode comes up. I think it = would make sense for such an opcode to only be able to track rate-limits ov= er short spans, like a month or less. Allowing the user to specify an arbit= rary window over which to track a rate-limit seems like something that woul= d probably open up a dos vector or other node resource usage abuse attacks.= It might be useful enough to simply rate limit over each epoch (two weeks)= , but having a small set of options could also be useful (eg 1 day, 1 week,= or 1 month).=C2=A0

In any case, I'd be intere= sted in seeing you write a BIP for this. Of course, don't take my word = as community interest. I'm reasonably new to the bitcoin dev community,= so definitely don't jump the gun based on my interest.=C2=A0

On S= at, Jul 31, 2021 at 2:51 PM Zac Greenwood via bitcoin-dev <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
Hi list,

=
I'd like to explore whether it is feasible to implement new script= ing capabilities in Bitcoin that enable limiting the output amount of a tra= nsaction based on the total value of its inputs. In other words, to impleme= nt 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-li= miting the amount they are able to send during a certain period (measured i= n blocks). A typical use case might be a user that intends to hodl their bi= tcoin, but still wishes to occasionally send small amounts. This avoids an = attacker from sweeping all their funds in a single transaction, allowing th= e user to become aware of the theft and intervene to prevent further theft.=

UC2: exchanges may wish to rate-limit addresses c= ontaining large amounts of bitcoin, adding warm- or hot-wallet functionalit= y to a cold-storage address. This would enable an exchange to drastically r= educe the number of times a cold wallet must be accessed with private keys = that enable access to the full amount.

In a typica= l 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 m= eaning "one or more" keys). One set of private keys allows only f= or sending with rate-limiting restrictions in place, and a s second set of = private keys allowing for sending any amount without rate-limiting, effecti= vely overriding such restriction.

The parameters t= hat define in what way an output is rate-limited might be defined as follow= s:

Param 1: a block height "h0" indicati= ng the first block height of an epoch;
Param 2: a block heig= ht "h1" indicating the last block height of an epoch;
P= aram 3: an amount "a" in satoshi indicating the maximum amount th= at is allowed to be sent in any epoch;
Param 4: an amount &qu= ot;a_remaining" (in satoshi) indicating the maximum amount that is all= owed to be sent within the current epoch.

Fo= r example, consider an input containing 100m sats (1 BTC) which has been ra= te-limited with parameters (h0, h1, a, a_remaning) of (800000, 800143, 500k= , 500k). These parameters define that the address is rate-limited to sendin= g a maximum of 500k sats in the current epoch that starts at block height 8= 00000 and ends at height 800143 (or about one day ignoring block time varia= nce) and that the full amount of 500k is still sendable. These rate-limitin= g parameters ensure that it takes at minimum 100m / 500k =3D 200 transactio= ns and 200 x 144 blocks or about 200 days to spend the full 100m sats. As n= oted earlier, in a typical setup a user should retain the option to transac= t the entire amount using a second (set of) private key(s).

<= /div>
For rate-limiting to work, any change output created by a transac= tion from a rate-limited address must itself be rate-limited as well. For i= nstance, expanding on the above example, assume that the user spends 200k s= ats from a rate-limited address a1 containing 100m sats:

Start situation:
At block height 800000: rate-limited addr= ess a1 is created;
Value of a1: 100.0m sats;
Rate limit= ing 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=3D8= 00000, h1=3D800143, a=3D500k, a_remaining=3D300k.

= Result:
Value at destination address: 200k sats;
Rate l= imiting params at destination address: none;
Value at change addr= ess a2: 99.8m sats;
Rate limiting params at change address a2: h0= =3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k.

<= div>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 s= ame rate limiting parameters as the transaction that served as its input. A= s a result, from block 800100 up until and including block 800143, a maximu= m 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;

Transaction t2:
Inc= luded at block height 800200
Spend: 400k=C2=A0+ fees.
R= ate-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 limi= ting params at change address a3: h0=3D800144, h1=3D800287, a=3D500k, a_rem= aining=3D100k.

Transaction t2 is allowed because i= t 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 trans= action and chosen by the user (or their wallet). This means that the parame= ters must be validated to ensure that they do not violate the intended cons= traints.

For instance, 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=3D= 300k;

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

This transaction t2a attempts to shift the epoch forw= ard 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 200= k at 800100 (epoch 1: total: 200k);
t2a: spend 400k at 800200 (ep= och 2: total: 400k);
t3a: spend 100k at 800201 (epoch 2: total: 5= 00k);
t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspend= ing for epoch 2).

Specifying the rate-limiting par= ameters explicitly at every transaction allows the user to tighten the spen= ding 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.
=
I will stop here because I would like to gauge interest in t= his 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 th= at two rate-limited addresses cannot spend more than the sum of their indiv= idual limits.

Zac






_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000004cdb6c05c88c2dc3--