diff options
| author | Zac Greenwood <zachgrw@gmail.com> | 2021-08-01 10:09:26 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-08-01 08:09:39 +0000 |
| commit | 5ee604f555de4c8c698247ff2b3e3cadb05e6ff1 (patch) | |
| tree | c50d40e0fe6ddada61ecee690756d632f6294629 /16 | |
| parent | 4a3bc80b04e41c8972f4619a439644d5a0707077 (diff) | |
| download | pi-bitcoindev-5ee604f555de4c8c698247ff2b3e3cadb05e6ff1.tar.gz pi-bitcoindev-5ee604f555de4c8c698247ff2b3e3cadb05e6ff1.zip | |
[bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value
Diffstat (limited to '16')
| -rw-r--r-- | 16/0475d9578af188c9f7747c5195b5360a428db3 | 344 |
1 files changed, 344 insertions, 0 deletions
diff --git a/16/0475d9578af188c9f7747c5195b5360a428db3 b/16/0475d9578af188c9f7747c5195b5360a428db3 new file mode 100644 index 000000000..c67490c93 --- /dev/null +++ b/16/0475d9578af188c9f7747c5195b5360a428db3 @@ -0,0 +1,344 @@ +Return-Path: <zachgrw@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 0A42EC000E + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 1 Aug 2021 08:09:39 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id F3E6C4022B + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 1 Aug 2021 08:09:38 +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 AyP2Un7cUv2N + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 1 Aug 2021 08:09:38 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com + [IPv6:2607:f8b0:4864:20::12f]) + by smtp4.osuosl.org (Postfix) with ESMTPS id E22764021C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 1 Aug 2021 08:09:37 +0000 (UTC) +Received: by mail-il1-x12f.google.com with SMTP id a14so13784665ila.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 01 Aug 2021 01:09:37 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:from:date:message-id:subject:to; + bh=hjn/88igarBHPfWU1A2S+6MJRSvZzWGNuo3XIsDMoEU=; + b=OQ/FxQvt5z9ljld7nlIlOdSo45UC1rgaBa9VPWf42c1Ov9uXqH3csfCEc2oSao59em + rQ5W3YRbXNviNlJhFXGIsFedjsa81DwNDkNYmehXv5FM8LcfZleJeBYqWqiFaJLju5Ru + RTRNJVsdMAx8NC2S49FEqx+dpKP4944JnsvvMGDomwuCKD45L4QRPXstURcHWjHjiaBi + Y8OiP79FjiWW3ITefs5UjPcb1KcUu2w7t40r0edYQc83iPUnE3K/gBbhwGc/w+yJaSVL + igfQ+pWjHfIHAiZfxngF+fceR8SEO67kPZnhuh78SBMe9w5w5cOzaTwt/+liruT0k26r + uorg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:from:date:message-id:subject:to; + bh=hjn/88igarBHPfWU1A2S+6MJRSvZzWGNuo3XIsDMoEU=; + b=he47DSgaqi6Yj4u8bLPenl+HdPe96q1C/T2PTklAo/RMWPpS3zQOlPGAm1WSzz5R5y + FROiLXJHDh4vazaHfDIbdHHhhrlxBfDib6EmrKiI3JbZ/9zmwTTDr2eLT9m+jB1H8XsN + 9EnNQ7aa45XLn48GmFpLjHsUV6siEHuu4MhzseCCUrXLd80JD3xN4lxOvMbnQri9fnUJ + xdiFjR5eVet14p8m6KzZfWx7NvOPZUYwg4UOM5qpdS7jUX+ZIasMnjxN58/os9GpFshD + r1VZnKErFXs3wkbbn1ogkNhXc1dMdFhyB0yUFji6BTtFarzCN+KsjCkDGcTUCCC3jVPk + 0AcQ== +X-Gm-Message-State: AOAM530+GHZpuZqtB/m9KYyLG6DeVTheHV5HOKWkL4HhTsOlTaPSDGMz + PF/bR964/sdNnDosBsIJ00cb0gZ7wlspSBGocLymGYV+GK4= +X-Google-Smtp-Source: ABdhPJzZiojDp9WvGAXJIObXTIJk8Dp/6Y0vbRK+VTSFx07nu1i4bunXFPcZlNj/O6OxzjmInbpUKeWhYOx4sVTYAcU= +X-Received: by 2002:a92:7d08:: with SMTP id y8mr5319588ilc.111.1627805376903; + Sun, 01 Aug 2021 01:09:36 -0700 (PDT) +MIME-Version: 1.0 +From: Zac Greenwood <zachgrw@gmail.com> +Date: Sun, 1 Aug 2021 10:09:26 +0200 +Message-ID: <CAJ4-pEAETy7_vOez5H32mZLg9gRpRajvoBjZyBT_v=DEqdQJvQ@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000041002705c87af934" +X-Mailman-Approved-At: Sun, 01 Aug 2021 16:32:05 +0000 +Subject: [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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 01 Aug 2021 08:09:39 -0000 + +--00000000000041002705c87af934 +Content-Type: text/plain; charset="UTF-8" + +[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 + +--00000000000041002705c87af934 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>[Resubmitting to list with minor edits. My previous s= +ubmission ended up inside an existing thread, apologies.]</div><div><br></d= +iv><div>Hi list,</div><div><br></div><div>I'd like to explore whether i= +t is feasible to implement new scripting capabilities in Bitcoin that enabl= +e limiting the output amount of a transaction based on the total value of i= +ts inputs. In other words, to implement the ability to limit the maximum am= +ount that can be sent from an address.</div><div><br></div><div>Two use cas= +es come to mind:</div><div><br></div><div>UC1: enable a user to add additio= +nal protection their funds by rate-limiting the amount that they are allowe= +d 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 occ= +asionally send small amounts. Rate-limiting avoids an attacker from sweepin= +g all the users' funds in a single transaction, allowing the user to be= +come aware of the theft and intervene to prevent further thefts.</div><div>= +<br></div><div>UC2: exchanges may wish to rate-limit addresses containing l= +arge amounts of bitcoin, adding warm- or hot-wallet functionality to a cold= +-storage address. This would enable an exchange to drastically reduce the n= +umber of times a cold wallet must be accessed with private keys that give a= +ccess to the full amount.</div><div><br></div><div>In a typical setup, I= +9;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 wi= +th rate-limiting restrictions in place, and a second set of private keys al= +lowing for sending any amount without rate-limiting, effectively overriding= + such restriction.</div><div><br></div><div>The parameters that define in w= +hat way an output is rate-limited might be defined as follows:</div><div><b= +r></div><div>Param 1: a block height "h0" indicating the first bl= +ock height of an epoch;</div><div><div>Param 2: a block height "h1&quo= +t; indicating the last block height of an epoch;</div><div>Param 3: an amou= +nt "a" in satoshi indicating the maximum amount that is allowed t= +o be sent in any epoch;<br></div><div>Param 4: an amount "a_remaining&= +quot; (in satoshi) indicating the maximum amount that is allowed to be sent= + within the current epoch.</div></div><div><br></div><div>For example, cons= +ider 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 e= +nsure that it takes at minimum 100m / 500k =3D 200 transactions and 200 x 1= +44 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 a= +mount using a second (set of) private key(s).</div><div><br></div><div>For = +rate-limiting to work, any change output created by a transaction from a ra= +te-limited address must itself be rate-limited as well. For instance, expan= +ding on the above example, assume that the user spends 200k sats from a rat= +e-limited address a1 containing 100m sats:</div><div><br></div><div>Start s= +ituation:</div><div>At block height 800000: rate-limited address a1 is crea= +ted;</div><div>Value of a1: 100.0m sats;</div><div>Rate limiting params of = +a1: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D500k;</div><div><br><= +/div><div>Transaction t1:</div><div>Included at block height 800100;</div><= +div>Spend: 200k + fee;</div><div>Rate limiting params: h0=3D800000, h1=3D80= +0143, a=3D500k, a_remaining=3D300k.</div><div><br></div><div>Result:</div><= +div>Value at destination address: 200k sats;</div><div>Rate limiting params= + at destination address: none;</div><div>Value at change address a2: 99.8m = +sats;</div><div>Rate limiting params at change address a2: h0=3D800000, h1= +=3D800143, a=3D500k, a_remaining=3D300k.</div><div><br></div><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 exc= +eeded. In this example, the change address a2 were given the same rate limi= +ting parameters as the transaction that served as its input. As a result, f= +rom block 800100 up until and including block 800143, a maximum amount of 3= +00k sats is allowed to be spent from the change address.</div><div><br></di= +v><div>Example continued:</div><div>a2: 99.8 sats at height=C2=A0800100;</d= +iv><div>Rate-limit params: h0=3D800000, h1=3D800143, a=3D500k, a_remaining= +=3D300k;</div><div><br></div><div>Transaction t2:</div><div>Included at blo= +ck height 800200</div><div>Spend: 400k=C2=A0+ fees.</div><div>Rate-limiting= + params: h0=3D800144, h1=3D800287, a=3D500k, a_remaining=3D100k.<br></div><= +div><br></div><div><div>Result:</div><div>Value at destination address: 400= +k sats;</div><div>Rate limiting params at destination address: none;</div><= +div>Value at change address a3: 99.4m sats;</div><div>Rate limiting params = +at change address a3: h0=3D800144, h1=3D800287, a=3D500k, a_remaining=3D100= +k.</div><div><br></div><div>Transaction t2 is allowed because it falls with= +in the next epoch (running from 800144 to 800287) so a spend of 400k does n= +ot violate the constraint of 500k per epoch.</div><div><br></div><div>As co= +uld be seen, the rate limiting parameters are part of the transaction and c= +hosen by the user (or their wallet). This means that the parameters must be= + validated to ensure that they do not violate the intended constraints.</di= +v><div><br></div><div>For instance, this transaction should not be allowed:= +</div><div><div>a2: 99.8 sats at height=C2=A0800100;</div><div>Rate-limit p= +arams of a2: h0=3D800000, h1=3D800143, a=3D500k, a_remaining=3D300k;</div><= +div><br></div><div>Transaction t2a:</div><div>Included at block height 8002= +00;</div><div>Spend: 400k=C2=A0+ fees;</div><div><div>Rate-limit params: h0= +=3D800124, h1=3D800267, a=3D500k, a_remaining=3D100k.</div><div><br></div><= +/div><div>This transaction t2a attempts to shift the epoch forward by 20 bl= +ocks such that it starts at 800124 instead of 800144. Shifting the epoch fo= +rward 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 en= +able overspending:</div></div><div><br></div><div>t1: spend 200k at 800100 = +(epoch 1: total: 200k);</div><div>t2a: spend 400k at 800200 (epoch 2: total= +: 400k);</div><div>t3a: spend 100k at 800201 (epoch 2: total: 500k);</div><= +div>t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoc= +h 2).</div><div><br></div><div>Specifying the rate-limiting parameters expl= +icitly at every transaction allows the user to tighten the spending limit b= +y setting tighter limits or for instance by setting a_remainder to 0 if the= +y wish to enforce not spending more during an epoch. A second advantage of = +explicitly specifying the four rate-limiting parameters with each transacti= +on is that it allows the system to fully validate the transaction without h= +aving to consider any previous transactions within an epoch.</div><div><br>= +</div><div>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:</div><div><br></div><div>Define all validations;</div><div>D= +escribe aggregate behaviour of multiple (rate-limited) inputs, proof that t= +wo rate-limited addresses cannot spend more than the sum of their individua= +l limits.</div><font color=3D"#888888"><div><br></div><div>Zac</div></font>= +</div></div> + +--00000000000041002705c87af934-- + |