public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value
@ 2021-08-01  8:09 Zac Greenwood
  2021-08-02  9:32 ` Zac Greenwood
  0 siblings, 1 reply; 19+ messages in thread
From: Zac Greenwood @ 2021-08-01  8:09 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 6653 bytes --]

[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

[-- Attachment #2: Type: text/html, Size: 7801 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread
* [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)
@ 2021-07-21  5:56 Billy Tetrud
  2021-07-25  5:38 ` David A. Harding
  0 siblings, 1 reply; 19+ messages in thread
From: Billy Tetrud @ 2021-07-21  5:56 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

Hi All,

I have been working on a proposal for an opcode I call
OP_CONSTRAINDESTINATION. The purpose of the opcode is to allow a spend-path
to restrict the destination address that an output's coins can be directed
to. When the destination address is something like a P2SH address, this
allows step-wise covenant scripts (where one script must lead to another).

This involves both specifying particular addresses the output is allowed to
send coins to, as well as constraining the amount of the fee that output is
allowed to contribute to. For example, if you had an output that contains
1000 satoshi, you could specify that a maximum of ~100 sats of that output
go to the miner fee and the other ~900 sats must go to one of a list of
specified addresses (~ meaning approximately, because the fee is specified
relative to recent median fee rates - details in the proposal).

This opcode has a few different applications, but my primary motivation for
creating this opcode is to create more flexible wallet vaults
<https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults>
.

To compare this opcode to OP_CHECKTEMPLATEVERIFY, wallet vaults that can be
created with OP_CTV must be created in specified chunks: the address is
explicitly tied to a particular utxo sent to it. To retrieve coins from the
vault, the output must be spent by one of a specific set of transactions
(potentially one per spend path). Outputs cannot be arbitrarily combined
into a transaction, and there is no flexibility whatsoever in deciding
options at the time of spending from the vault - all options must be
premeditated and encoded into the address itself when sending money to the
vault. This has some related foot-gun scenarios, where the wallet vault has
addresses that if sent to would generally result in burning those coins,
unless done in a very specific way by the owner of the vault.

By contrast, OP_CD allows a lot more flexibility because it only constrains
the address to be sent to from the vault, but doesn't put additional
constraints on the transaction. This means that outputs can be combined
into a single transaction like you would expect in a normal transaction. It
also means that external users (people who don't own the vault) can safely
send money directly into the vault without coins being burned.

*I have the proposal for this opcode up here:
https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>*.
I'd love to hear what people think about it, what problems it might have
that I've missed, or other issues or suggestions surrounding this. I'd also
appreciate any input that would help me improve the presentation of the
opcode.

Thanks!

[-- Attachment #2: Type: text/html, Size: 2964 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2021-09-01 15:15 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-01  8:09 [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood
2021-08-02  9:32 ` Zac Greenwood
2021-08-03 18:12   ` Billy Tetrud
2021-08-04 10:48     ` Zac Greenwood
2021-08-05  6:39       ` Billy Tetrud
2021-08-05 14:22         ` Zac Greenwood
2021-08-10  0:41           ` Billy Tetrud
  -- strict thread matches above, loose matches on Subject: below --
2021-07-21  5:56 [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud
2021-07-25  5:38 ` David A. Harding
2021-07-25 19:49   ` Billy Tetrud
2021-07-26 21:08     ` James MacWhyte
2021-07-27  0:41       ` Billy Tetrud
2021-07-27 11:18         ` Zac Greenwood
2021-07-27 17:21           ` Billy Tetrud
2021-07-28  4:57             ` Zac Greenwood
2021-07-28 17:57               ` Billy Tetrud
2021-07-31 20:01                 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood
2021-08-02  4:40                   ` Billy Tetrud
2021-08-10  2:17                   ` ZmnSCPxj
2021-08-13 11:02                     ` Zac Greenwood
2021-08-14  1:50                       ` ZmnSCPxj
2021-08-16 11:17                         ` Zac Greenwood
2021-08-16 11:48                           ` ZmnSCPxj
2021-08-30 14:43                             ` Zac Greenwood
2021-08-31  9:00                               ` ZmnSCPxj
2021-08-31 14:09                                 ` Zac Greenwood
2021-08-31 14:22                                   ` ZmnSCPxj
2021-09-01 15:15                                     ` Zac Greenwood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox