Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

Hi ZmnSCPxj,

The rate-limiting algorithm would be relatively straightforward. I
documented the rate-limiting part of the algorithm below, perhaps they can
evoke new ideas of how to make this MAST-able or otherwise implement this
in a privacy preserving way.

Something like the following:

=> Create an output at block height [h0] with the following properties:

Serving as input at any block height, the maximum amount is limited to
[limit] sats;  // This rule introduces [limit] and is permanent and always
copied over to a change output
Serving as input at a block height < [h0 + window], the maximum amount is
limited to [limit - 0] sats;  // [limit - 0] to emphasize that nothing was
spent yet and no window has started.

=> A transaction occurs at block height [h1], spending [h1_spent].
The payment output created at [h1] is not encumbered and of value
[h1_spent]; // Note, this is the first encumbered transaction so [h1] is
the first block of the first window

The change output created at block height [h1] must be encumbered as
follows:
Serving as input at any block height, the maximum amount is limited to
[limit] sats;  // Permanent rule repeats
Serving as input at a block height < [h1 + window], the maximum amount is
limited to [limit - h1_spent]  // Second permanent rule reduces spendable
amount until height [h1 + window] by [h1_spent]

=> A second transaction occurs at block height [h2], spending [h2_spent].
The payment output created at [h2] is not encumbered and of value
[h2_spent]; // Second transaction, so a second window starts at [h2]

The change output created at block height [h2] must be encumbered as
follows:
Serving as input at any block height, the maximum amount is limited to
[limit] sats;  // Permanent rule repeats
Serving as input at a block height < [h1 + window], the max amount is
limited to [limit - h1_spent - h2_spent] // Reduce spendable amount between
[h1] and [h1 + window] by an additional [h2_spent]
Serving as input in range [h1 + window] <= block height < [h2 + window],
the max amount is limited to [limit - h2_spent]  // First payment no longer
inside this window so [h1_spent] no longer subtracted

... and so on. A rule that pertains to a block height < the current block
height can be abandoned, keeping the number of rules equal to the number of
transactions that exist within the oldest still active window.

Zac


On Tue, Aug 31, 2021 at 4:22 PM ZmnSCPxj  wrote:

> Good morning Zac,
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your helpful response. We're on the same page concerning
> privacy so I'll focus on that. I understand from your mail that privacy
> would be reduced by this proposal because:
> >
> > * It requires the introduction of a new type of transaction that is
> different from a "standard" transaction (would that be P2TR in the
> future?), reducing the anonymity set for everyone;
> > * The payment and change output will be identifiable because the change
> output must be marked encumbered on-chain;
> > * The specifics of how the output is encumbered must be visible on-chain
> as well reducing privacy even further.
> >
> > I don't have the technical skills to judge whether these issues can
> somehow be resolved. In functional terms, the output should be spendable in
> a way that does not reveal that the output is encumbered, and produce a
> change output that cannot be distinguished from a non-change output while
> still being encumbered. Perhaps some clever MAST-fu could somehow help?
>
> I believe some of the covenant efforts may indeed have such clever MAST-fu
> integrated into them, which is why I pointed you to them --- the people
> developing these (aj I think? RubenSomsen?) might be able to accommodate
> this or some subset of the desired feature in a sufficiently clever
> covenant scheme.
>
> There are a number of such proposals, though, so I cannot really point you
> to one that seems likely to have a lot of traction.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[ZmnSCPxj via bitcoin-dev]

Good morning Zac,

> Hi ZmnSCPxj,
>
> Thank you for your helpful response. We're on the same page concerning 
> privacy so I'll focus on that. I understand from your mail that privacy would 
> be reduced by this proposal because:
>
> * It requires the introduction of a new type of transaction that is different 
> from a "standard" transaction (would that be P2TR in the future?), reducing 
> the anonymity set for everyone;
> * The payment and change output will be identifiable because the change 
> output must be marked encumbered on-chain;
> * The specifics of how the output is encumbered must be visible on-chain as 
> well reducing privacy even further.
>
> I don't have the technical skills to judge whether these issues can somehow 
> be resolved. In functional terms, the output should be spendable in a way 
> that does not reveal that the output is encumbered, and produce a change 
> output that cannot be distinguished from a non-change output while still 
> being encumbered. Perhaps some clever MAST-fu could somehow help?

I believe some of the covenant efforts may indeed have such clever MAST-fu 
integrated into them, which is why I pointed you to them --- the people 
developing these (aj I think? RubenSomsen?) might be able to accommodate this 
or some subset of the desired feature in a sufficiently clever covenant scheme.

There are a number of such proposals, though, so I cannot really point you to 
one that seems likely to have a lot of traction.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

Hi ZmnSCPxj,

Thank you for your helpful response. We're on the same page concerning
privacy so I'll focus on that. I understand from your mail that privacy
would be reduced by this proposal because:

* It requires the introduction of a new type of transaction that is
different from a "standard" transaction (would that be P2TR in the
future?), reducing the anonymity set for everyone;
* The payment and change output will be identifiable because the change
output must be marked encumbered on-chain;
* The specifics of how the output is encumbered must be visible on-chain as
well reducing privacy even further.

I don't have the technical skills to judge whether these issues can somehow
be resolved. In functional terms, the output should be spendable in a way
that does not reveal that the output is encumbered, and produce a change
output that cannot be distinguished from a non-change output while still
being encumbered. Perhaps some clever MAST-fu could somehow help?

I imagine that the offered functionality does not justify the above
mentioned privacy reductions, so unless these can be addressed, without
functional modification this proposal sadly seems dead in the water.

Thanks again.

Zac


On Tue, Aug 31, 2021 at 11:00 AM ZmnSCPxj  wrote:

> Good morning Zac,
>
>
> > Perhaps you could help me understand what would be required to implement
> the *unmodified* proposal. That way, the community will be able to better
> assess the cost (in terms of effort and risk) and weigh it against the
> perceived benefits. Perhaps *then* we find that the cost could be
> significantly reduced without any significant reduction of the benefits,
> for instance by slightly compromising on the functionality such that no
> changes to consensus would be required for its implementation. (I am
> skeptical that this would be possible though). The cost reduction must be
> carefully weighed against the functional gaps it creates.
>
> For one, such output need to be explicitly visible, to implement the
> "change outputs must also be rate-limited".
> A tx spending a rate-limited output has to know that one of the outputs is
> also a rate-limited output.
>
> This flagging needs to be done by either allocating a new SegWit version
> --- a resource that is not lightly allocated, there being only 30 versions
> left if my understanding is correct --- or blessing yet another
> anyone-can-spend `scriptPubKey` template, something we want to avoid which
> is why SegWit has versions (i.e. we want SegWit to be the last
> anyone-can-spend `scriptPubKey` template we bless for a **long** time).
>
> Explicit flagging is bad as well for privacy, which is another mark
> against it.
> Notice how Taproot improves privacy by making n-of-n indistinguishable
> from 1-of-1 (and with proper design or a setup ritual, k-of-n can be made
> indistinguishable from 1-of-1).
> Notice as well that my first counterproposal is significantly more private
> than explicit flagging, and my second coutnerproposal is also more private
> if wallets change their anti-fee-sniping mitigation.
> This privacy loss represented by explicit flagging will be resisted by
> some people, especially those that use a bunch of random letters as a
> pseudonym (because duh, privacy).
>
> (Yes, people can just decide not to use the privacy-leaking
> explicitly-flagged outputs, but that reduces the anonymity set of people
> who *are* interested in privacy, so people who are interested in privacy
> will prefer that other people do not leak their privacy so they can hide
> among *those* people as well.)
>
> You also probably need to keep some data with each output.
> This can be done by explicitly storing that data in the output directly,
> rather than a commitment to that data --- again, the "change outputs must
> also be rate-limited" requirement needs to check those data.
>
> The larger data stored with the output is undesirable, ideally we want
> each output to just be a commitment rather than contain any actual data,
> because often a 20-byte commitment is smaller than the data that needs to
> be stored.
> For example, I imagine that your original proposal requires, for change
> outputs, to store:
>
> * The actual rate limit.
> * The time frame of the rate limit.
> * The reduced rate limit, since we spent an amount within a specific time
> frame (i.e. residual limit) which is why this is a change output.
> * How long that time frame lasts.
> * A commitment to the keys that can spend this.
>
> Basically, until the residual limit expires, we impose the residual limit,
> then after the expiry of the residual limit we go back to the original rate
> limit.
>
> The commitment to the keys itself takes at least 20 bytes, and if you are
> planning a to support k-of-n then that takes at least 32 bytes.
> If this was not explicitly tagged, then a 32 byte commitment to all the
> necessary data would have been enough, but you do need the explicit tagging
> for the "change outputs must be rate-limited 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[ZmnSCPxj via bitcoin-dev]

Good morning Zac,


> Perhaps you could help me understand what would be required to implement the 
> *unmodified* proposal. That way, the community will be able to better assess 
> the cost (in terms of effort and risk) and weigh it against the perceived 
> benefits. Perhaps *then* we find that the cost could be significantly reduced 
> without any significant reduction of the benefits, for instance by slightly 
> compromising on the functionality such that no changes to consensus would be 
> required for its implementation. (I am skeptical that this would be possible 
> though). The cost reduction must be carefully weighed against the functional 
> gaps it creates.

For one, such output need to be explicitly visible, to implement the "change 
outputs must also be rate-limited".
A tx spending a rate-limited output has to know that one of the outputs is also 
a rate-limited output.

This flagging needs to be done by either allocating a new SegWit version --- a 
resource that is not lightly allocated, there being only 30 versions left if my 
understanding is correct --- or blessing yet another anyone-can-spend 
`scriptPubKey` template, something we want to avoid which is why SegWit has 
versions (i.e. we want SegWit to be the last anyone-can-spend `scriptPubKey` 
template we bless for a **long** time).

Explicit flagging is bad as well for privacy, which is another mark against it.
Notice how Taproot improves privacy by making n-of-n indistinguishable from 
1-of-1 (and with proper design or a setup ritual, k-of-n can be made 
indistinguishable from 1-of-1).
Notice as well that my first counterproposal is significantly more private than 
explicit flagging, and my second coutnerproposal is also more private if 
wallets change their anti-fee-sniping mitigation.
This privacy loss represented by explicit flagging will be resisted by some 
people, especially those that use a bunch of random letters as a pseudonym 
(because duh, privacy).

(Yes, people can just decide not to use the privacy-leaking explicitly-flagged 
outputs, but that reduces the anonymity set of people who *are* interested in 
privacy, so people who are interested in privacy will prefer that other people 
do not leak their privacy so they can hide among *those* people as well.)

You also probably need to keep some data with each output.
This can be done by explicitly storing that data in the output directly, rather 
than a commitment to that data --- again, the "change outputs must also be 
rate-limited" requirement needs to check those data.

The larger data stored with the output is undesirable, ideally we want each 
output to just be a commitment rather than contain any actual data, because 
often a 20-byte commitment is smaller than the data that needs to be stored.
For example, I imagine that your original proposal requires, for change 
outputs, to store:

* The actual rate limit.
* The time frame of the rate limit.
* The reduced rate limit, since we spent an amount within a specific time frame 
(i.e. residual limit) which is why this is a change output.
* How long that time frame lasts.
* A commitment to the keys that can spend this.

Basically, until the residual limit expires, we impose the residual limit, then 
after the expiry of the residual limit we go back to the original rate limit.

The commitment to the keys itself takes at least 20 bytes, and if you are 
planning a to support k-of-n then that takes at least 32 bytes.
If this was not explicitly tagged, then a 32 byte commitment to all the 
necessary data would have been enough, but you do need the explicit tagging for 
the "change outputs must be rate-limited too".

Note as well that the residual needs to be kept with the output.
Bitcoin Core does not store transactions in a lookup table, it stores 
individual *outputs*.
While the residual can be derived from the transaction, we do not have a 
transaction table.
Thus, we need to explicitly put it on the output itself, directly, since we 
only have a lookup table for the unspent outputs, not individual transactions.

(well there is `txindex` but that is an option for each node, not something 
consensus code can rely on)

So yes, that "change outputs must also be rate-limited" is the big sticking 
point, and a lot of the "gaps" you worry about occur when we drop this bit.
Drop this bit and you can implement it today without any consensus code change, 
and with privacy good enough to prevent people with random letters as pseudonym 
from trying to stop you.

Regards,
ZmnSCPxj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

Hi ZmnSCPxj,

> I suggest looking into the covenant opcodes and supporting those instead
of your own proposal, as your application is very close to one of the
motivating examples for covenants in the first place.

I believe it is not the right approach to take a proposal, chop off key
aspects of its functionality, and rely to some future change in Bitcoin
that may perhaps enable implementing some watered down version of the
intended functionality. In my opinion the right order would be to first
discuss the unmodified proposal on a functional level and gauge community
interest, then move forward to discuss technical challenges for the
*unmodified* proposal instead of first knee-capping the proposal in order
to (presumably) reduce cost of implementation.

I believe that we both recognize that the proposed functionality would be
beneficial. I believe that your position is that functionality close to
what I have in mind can be implemented using covenants, albeit with some
gaps. For me personally however these gaps would not be acceptable because
they severely hurt the predictability and intuitiveness of the behavior of
the functionality for the end-user. But as noted, I believe at this point
it is premature to have this discussion.

Perhaps you could help me understand what would be required to implement
the *unmodified* proposal. That way, the community will be able to better
assess the cost (in terms of effort and risk) and weigh it against the
perceived benefits. Perhaps *then* we find that the cost could be
significantly reduced without any significant reduction of the benefits,
for instance by slightly compromising on the functionality such that no
changes to consensus would be required for its implementation. (I am
skeptical that this would be possible though). The cost reduction must be
carefully weighed against the functional gaps it creates.

I am aware that my proposal must be well-defined functionally before being
able to reason about its benefits and implementational aspects. I believe
that the proposed functionality is pretty straightforward, but I am happy
to come up with a more precise functional spec. However, such effort would
be wasted if there is no community interest for this functionality. So far
only few people have engaged with this thread, and I am not sure that this
is because there is no interest in the proposal or because most people just
lurk here and do not feel like giving their opinion on random proposals. It
would be great however to learn about more people's opinions.

As a reminder, the proposed functionality is to enable a user to limit the
amount that they able to spent from an address within a certain time-frame
or window (defined in number of blocks) while retaining the ability to
spend arbitrary amounts using a secondary private key (or set of private
keys). The general use case is to prevent theft of large amounts while
still allowing a user to spend small amounts over time. Hodlers as well as
exchanges dealing with cold, warm and hot wallets come to mind as users who
could materially benefit from this functionality.

Zac



On Mon, Aug 16, 2021 at 1:48 PM ZmnSCPxj  wrote:

> Good morning Zac,
>
> > Thank you for your counterproposal. I fully agree that as a first step
> we must establish whether the proposed functionality can be implemented
> without making any changes to consensus.
> >
> > Your counterproposal is understandably more technical in nature because
> it explores an implementation on top of Bitcoin as-is. However I feel that
> for a fair comparison of the functionality of both proposals a purely
> functional description of your proposal is essential.
> >
> > If I understand your proposal correctly, then I believe there are some
> major gaps between yours and mine:
> >
> > Keys for unrestricted spending: in my proposal, they never have to come
> online unless spending more than the limit is desired. In your proposal,
> these keys are required to come online in several situations.
>
> Correct, that is indeed a weakness.
>
> It is helpful to see https://zmnscpxj.github.io/bitcoin/unchained.html
> Basically: any quorum of signers can impose any rules that are not
> implementable on the base layer, including the rules you desire.
> That quorum is the "offline keyset" in my proposal.
>
> >
> > Presigning transactions: not required in my proposal. Wouldn’t such
> presigning requirement be detrimental for the usability of your proposal?
> Does it mean that for instance the amount and window in which the
> transaction can be spent is determined at the time of signing? In my
> proposal, there is no limit in the number of transactions per window.
>
> No.
> Remember, the output is a simple 1-of-1 or k-of-n of the online keyset.
> The online keyset can spend that wherever and however, including paying it
> out to N parties, or paying part of the limit to 1 party and then paying
> the remainder back to the same onchain keyset so it can access the funds in
> the future.
> 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

Hi ZmnSCPxj,

Thank you for your counterproposal. I fully agree that as a first step we
must establish whether the proposed functionality can be implemented
without making any changes to consensus.

Your counterproposal is understandably more technical in nature because it
explores an implementation on top of Bitcoin as-is. However I feel that for
a fair comparison of the functionality of both proposals a purely
functional description of your proposal is essential.

If I understand your proposal correctly, then I believe there are some
major gaps between yours and mine:

Keys for unrestricted spending: in my proposal, they never have to come
online unless spending more than the limit is desired. In your proposal,
these keys are required to come online in several situations.

Presigning transactions: not required in my proposal. Wouldn’t such
presigning requirement be detrimental for the usability of your proposal?
Does it mean that for instance the amount and window in which the
transaction can be spent is determined at the time of signing? In my
proposal, there is no limit in the number of transactions per window.

Number of windows: limited in your proposal, unlimited in mine.

There are probably additional gaps that I am currently not technically able
to recognize.

I feel that the above gaps are significant enough to state that your
proposal does not meet the basic requirements of my proposal.

Next to consider is whether the gap is acceptable, weighing the effort to
implement the required consensus changes against the effort and feasibility
of implementing your counterproposal.

I feel that your counterproposal has little chance of being implemented
because of the still considerable effort required and the poor result in
functional terms. I also wonder if your proposal is feasible considering
wallet operability.

Considering all the above, I believe that implementing consensus changes in
order to support the proposed functionality would preferable  over your
counterproposal.

I acknowledge that a consensus change takes years and is difficult to
achieve, but that should not be any reason to stop exploring the appetite
for the proposed functionality and perhaps start looking at possible
technical solutions.

Zac


On Sat, 14 Aug 2021 at 03:50, ZmnSCPxj  wrote:

> Good morning Zac,
>
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your insightful response.
> >
> > Perhaps I should take a step back and take a strictly functional angle.
> Perhaps the list could help me to establish whether the proposed
> functionality is:
> >
> > Desirable;
> > Not already possible;
> > Feasible to implement.
> >
> > The proposed functionality is as follows:
> >
> > The ability to control some coin with two private keys (or two sets of
> private keys) such that spending is limited over time for one private key
> (i.e., it is for instance not possible to spend all coin in a single
> transaction) while spending is unrestricted for the other private key (no
> limits apply). No limits must apply to coin transacted to a third party.
> >
> > Also, it must be possible never having to bring the unrestricted private
> key online unless more than the limit imposed on the restrictive private
> key is desired to be spent.
> >
> > Less generally, taking the perspective of a hodler: the user must be
> able to keep one key offline and one key online. The offline key allows
> unrestricted spending, the online key is limited in how much it is allowed
> to spend over time.
> >
> > Furthermore, the spending limit must be intuitive. Best candidate I
> believe would be a maximum spend per some fixed number of blocks. For
> instance, the restrictive key may allow a maximum of 100k sats per any
> window of 144 blocks. Ofcourse the user must be able to set these
> parameters freely.
>
> My proposal does not *quite* implement a window.
> However, that is because it uses `nLockTime`.
>
> With the use of `nSequence` in relative-locktime mode, however, it *does*
> implement a window, sort of.
> More specifically, it implements a timeout on spending --- if you spend
> using a presigned transaction (which creates an unencumbered
> specific-valued TXO that can be arbitrarily spent with your online keyset)
> then you cannot get another "batch" of funds until the `nSequence` relative
> locktime passes.
> However, this *does* implement a window that limits a maximum value
> spendable per any window of the relative timelock you select.
>
> The disadvantage is that `nSequence` use is a lot more obvious and
> discernible than `nLockTime` use.
> Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that
> is a good cover for `nLockTime` transactions.
> I believe Dave Harding proposed that wallets should also use, at random,
> (say 50-50) `nSequence`-in-relative-locktime-mode as an alternate
> anti-fee-sniping mechanism.
> This alternate anti-fee-sniping would help cover `nSequence` use.
>
> Note that my proposal does impose a maximum limit on the 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[ZmnSCPxj via bitcoin-dev]

Good morning Zac,

> Thank you for your counterproposal. I fully agree that as a first step we 
> must establish whether the proposed functionality can be implemented without 
> making any changes to consensus.
>
> Your counterproposal is understandably more technical in nature because it 
> explores an implementation on top of Bitcoin as-is. However I feel that for a 
> fair comparison of the functionality of both proposals a purely functional 
> description of your proposal is essential.
>
> If I understand your proposal correctly, then I believe there are some major 
> gaps between yours and mine:
>
> Keys for unrestricted spending: in my proposal, they never have to come 
> online unless spending more than the limit is desired. In your proposal, 
> these keys are required to come online in several situations.

Correct, that is indeed a weakness.

It is helpful to see https://zmnscpxj.github.io/bitcoin/unchained.html
Basically: any quorum of signers can impose any rules that are not 
implementable on the base layer, including the rules you desire.
That quorum is the "offline keyset" in my proposal.

>
> Presigning transactions: not required in my proposal. Wouldn’t such 
> presigning requirement be detrimental for the usability of your proposal? 
> Does it mean that for instance the amount and window in which the transaction 
> can be spent is determined at the time of signing? In my proposal, there is 
> no limit in the number of transactions per window.

No.
Remember, the output is a simple 1-of-1 or k-of-n of the online keyset.
The online keyset can spend that wherever and however, including paying it out 
to N parties, or paying part of the limit to 1 party and then paying the 
remainder back to the same onchain keyset so it can access the funds in the 
future.
Both cases are also available in your proposal, and the latter case (pay out 
part of the limit to a single output, then keep the rest back to the same 
onchain keyset) can be used to add an indefinite number of transactions per 
window.

>
> Number of windows: limited in your proposal, unlimited in mine.

Correct, though you can always have a fairly large number of windows ("640kB 
ought to be enough for anybody").

>
> There are probably additional gaps that I am currently not technically able 
> to recognize.

It requires a fair amount of storage for the signatures at minimum, though that 
may be as small as 64 bytes per window.
1Mb of storage for signatures would allow 16,384 windows, assuming you use 
1-day windows that is about 44.88 years, probably more than enough that a 
one-time onlining of the offline keys (or just print out the signatures on 
paper or display as a QR code, whatever) is acceptable.

> I feel that the above gaps are significant enough to state that your proposal 
> does not meet the basic requirements of my proposal.
>
> Next to consider is whether the gap is acceptable, weighing the effort to 
> implement the required consensus changes against the effort and feasibility 
> of implementing your counterproposal.
>
> I feel that your counterproposal has little chance of being implemented 
> because of the still considerable effort required and the poor result in 
> functional terms. I also wonder if your proposal is feasible considering 
> wallet operability.

See above, particularly the gap that does not, in fact, exist.

>
> Considering all the above, I believe that implementing consensus changes in 
> order to support the proposed functionality would preferable  over your 
> counterproposal.
>
> I acknowledge that a consensus change takes years and is difficult to 
> achieve, but that should not be any reason to stop exploring the appetite for 
> the proposed functionality and perhaps start looking at possible technical 
> solutions.

You can also look into the "covenant" opcodes (`OP_CHECKSIGFROMSTACK`, 
`OP_CHECKTEMPLATEVERIFY`, etc.), I think JeremyRubin has a bunch of them listed 
somewhere, which may be used to implement something similar without requiring 
presigning.

Since the basic "just use `nSequence`" scheme already implements what you need, 
what the covenant opcodes buy you is that you do not need the offline keyset to 
be onlined and there is no need to keep signatures, removing the remaining gaps 
you identified.
With a proper looping covenant opcode, there is also no limit on the number of 
windows.

The issue with the covenant opcodes is that there are several proposals with 
overlapping abilities and different tradeoffs.
This is the sort of thing that invites bikeshed-painting.

I suggest looking into the covenant opcodes and supporting those instead of 
your own proposal, as your application is very close to one of the motivating 
examples for covenants in the first place.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[ZmnSCPxj via bitcoin-dev]

Good morning Zac,


> Hi ZmnSCPxj,
>
> Thank you for your insightful response.
>
> Perhaps I should take a step back and take a strictly functional angle. 
> Perhaps the list could help me to establish whether the proposed 
> functionality is:
>
> Desirable;
> Not already possible;
> Feasible to implement.
>
> The proposed functionality is as follows:
>
> The ability to control some coin with two private keys (or two sets of 
> private keys) such that spending is limited over time for one private key 
> (i.e., it is for instance not possible to spend all coin in a single 
> transaction) while spending is unrestricted for the other private key (no 
> limits apply). No limits must apply to coin transacted to a third party.
>
> Also, it must be possible never having to bring the unrestricted private key 
> online unless more than the limit imposed on the restrictive private key is 
> desired to be spent.
>
> Less generally, taking the perspective of a hodler: the user must be able to 
> keep one key offline and one key online. The offline key allows unrestricted 
> spending, the online key is limited in how much it is allowed to spend over 
> time.
>
> Furthermore, the spending limit must be intuitive. Best candidate I believe 
> would be a maximum spend per some fixed number of blocks. For instance, the 
> restrictive key may allow a maximum of 100k sats per any window of 144 
> blocks. Ofcourse the user must be able to set these parameters freely.

My proposal does not *quite* implement a window.
However, that is because it uses `nLockTime`.

With the use of `nSequence` in relative-locktime mode, however, it *does* 
implement a window, sort of.
More specifically, it implements a timeout on spending --- if you spend using a 
presigned transaction (which creates an unencumbered specific-valued TXO that 
can be arbitrarily spent with your online keyset) then you cannot get another 
"batch" of funds until the `nSequence` relative locktime passes.
However, this *does* implement a window that limits a maximum value spendable 
per any window of the relative timelock you select.

The disadvantage is that `nSequence` use is a lot more obvious and discernible 
than `nLockTime` use.
Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that is a 
good cover for `nLockTime` transactions.
I believe Dave Harding proposed that wallets should also use, at random, (say 
50-50) `nSequence`-in-relative-locktime-mode as an alternate anti-fee-sniping 
mechanism.
This alternate anti-fee-sniping would help cover `nSequence` use.

Note that my proposal does impose a maximum limit on the number of windows.
With `nSequence`-in-relative-locktime-mode the limit is the number of times 
that the online keyset can spend.
After spending that many windows, the offline keyset has to be put back online 
to generate a new set of transactions.

It has the massive massive advantage that you can implement it today without 
any consensus change, and I think you can expect that consensus change will 
take a LONG time (xref SegWit, Taproot).

Certainly the functionality is desirable.
But it seems it can be implemented with Bitcoin today.

Regards,
ZmnSCPxj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

Hi ZmnSCPxj,

Thank you for your insightful response.

Perhaps I should take a step back and take a strictly functional angle.
Perhaps the list could help me to establish whether the proposed
functionality is:

Desirable;
Not already possible;
Feasible to implement.

The proposed functionality is as follows:

The ability to control some coin with two private keys (or two sets of
private keys) such that spending is limited over time for one private key
(i.e., it is for instance not possible to spend all coin in a single
transaction) while spending is unrestricted for the other private key (no
limits apply). No limits must apply to coin transacted to a third party.

Also, it must be possible never having to bring the unrestricted private
key online unless more than the limit imposed on the restrictive private
key is desired to be spent.

Less generally, taking the perspective of a hodler: the user must be able
to keep one key offline and one key online. The offline key allows
unrestricted spending, the online key is limited in how much it is allowed
to spend over time.

Furthermore, the spending limit must be intuitive. Best candidate I believe
would be a maximum spend per some fixed number of blocks. For instance, the
restrictive key may allow a maximum of 100k sats per any window of 144
blocks. Ofcourse the user must be able to set these parameters freely.

I look forward to any feedback you may have.

Zac



On Tue, 10 Aug 2021 at 04:17, ZmnSCPxj  wrote:

>  fromGood morning Zac,
>
>
> With some work, what you want can be implemented, to some extent, today,
> without changes to consensus.
>
> The point you want, I believe, is to have two sets of keys:
>
> * A long-term-storage keyset, in "cold" storage.
> * A short-term-spending keyset, in "warm" storage, controlling only a
> small amount of funds.
>
> What you can do would be:
>
> * Put all your funds in a single UTXO, with an k-of-n of your cold keys
> (ideally P2TR, or some P2WSH k-of-n).
> * Put your cold keys online, and sign a transaction spending the above
> UTXO, and spending most of it to a new address that is a tweaked k-of-n of
> your cold keys, and a smaller output (up to the limit you want) controlled
> by the k-of-n of your warm keys.
>   * Keep this transaction offchain, in your warm storage.
> * Put your cold keys back offline.
> * When you need to spend using your warm keys, bring the above transaction
> onchain, then spend from the budget as needed.
>
>
> If you need to have some estimated amount of usable funds for every future
> unit of time, just create a chain of transactions with future `nLockTime`.
>
>   nLocktime +1day  nLockTime +2day
>   ++   ++   ++
>  cold UTXO -->|cold TXO|-->|cold TXO|-->|cold TXO|--> etc.
>   ||   ||   ||
>   |warm TXO|   |warm TXO|   |warm TXO|
>   ++   ++   ++
>
> Pre-sign the above transactions, store the pre-signed transactions in warm
> storage together with your warm keys.
> Then put the cold keys back offline.
>
> Then from today to tomorrow, you can spend only the first warm TXO.
> From tomorrow to the day after, you can spend only the first two warm TXOs.
> And so on.
>
> If tomorrow your warm keys are stolen, you can bring the cold keys online
> to claim the second cold TXO and limit your fund loss to only just the
> first two warm TXOs.
>
> The above is bulky, but it has the advantage of not using any special
> opcodes or features (improving privacy, especially with P2TR which would in
> theory allow k-of-n/n-of-n to be indistinguishable from 1-of-1), and using
> just `nLockTime`, which is much easier to hide since most modern wallets
> will set `nLockTime` to recent block heights.
>
> Regards,
> ZmnSCPxj
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Billy Tetrud via bitcoin-dev]

>  By explicitly specifying the start and end block of an epoch, the user
has more flexibility in shifting the epoch

Ok I see. I think I understand your proposal better now. If the output is
spent within the range epochStart - epochEnd, the limit holds, if it is
spent outside that range the change output must also have a range of the
same length (or shorter?). So you want there to be the ability for the user
to precisely define the length and starting block of the
rate-limiting-period (epoch). I'd say it'd be clearer to specify the window
length and the starting block in that case. The same semantics can be kept.

> This would require the system to bookkeep how much was spent since the
first rate-limited output

Yes, for the length of the epoch, after which the bookkeeping can be
discarded/reset until a new transaction is sent. Your proposal also
requires bookkeeping tho - it needs to store the 'remain' value with the
UTXO as well because its not efficient to go back and re-execute the script
just to grab that value.

> using an address as input for a transaction will always spends the full
amount at that address

Using a UTXO will spend the full UTXO. The address may contain many UTXOs.
I'm not suggesting that a change address isn't needed - I'm suggesting that
the *same* address be used as the change address for the change output. Eg
consider the following UTXO info:

Address X: rateLimit(windowSize = 144 blocks, limit = 100k sats)
* UTXO 1: 100k sats, 50k spent by ancestor inputs since epochStart 800100
* UTXO 2: 200k sats, 10k spent since epochStart

When sending a transaction using UTXO 2, a node would look up the list of
UTXOs in Address X, add up the amount spent since epochStart (60k) and
ensure that at most 40k is going to an address that isn't address X. So a
valid transaction might look like:

Input: UTXO 2
Output 1: 30k -> Address A
Output 2: 170k -> Address X

On Thu, Aug 5, 2021 at 7:22 AM Zac Greenwood  wrote:

> Hi Billy,
>
> > It sounds like you're proposing an opcode
>
> No. I don’t have enough knowledge of Bitcoin to be able to tell how (and
> if) rate-limiting can be implemented as I suggested. I am not able to
> reason about opcodes, so I kept my description at a more functional level.
>
> > I still don't understand why its useful to specify those as absolute
> block heights
>
> I feel that this a rather uninteresting data representation aspect that’s
> not worth going back and forth about. Sure, specifying the length of the
> epoch may also be an option, although at the price of giving up some
> functionality, and without much if any gains.
>
> By explicitly specifying the start and end block of an epoch, the user has
> more flexibility in shifting the epoch (using alternate values for
> epochStart and epochEnd) and simultaneously increasing the length of an
> epoch. These seem rather exotic features, but there’s no harm in retaining
> them.
>
> > if you have a UTXO encumbered by rateLimit(epochStart = 800100,
> epochEnd = 800200, limit = 100k, remain = 100k), what happens if you don't
> spend that UTXO before block 800200?
>
> The rate limit remains in place. So if this UTXO is spent in block 90,
> then at most 100k may be spent. Also, the new epoch must be at least 100
> blocks and remain must correctly account for the actual amount spent.
>
> > This is how I'd imagine creating an opcode like this:
>
> > rateLimit(windowSize = 144 blocks, limit = 100k sats)
>
> This would require the system to bookkeep how much was spent since the
> first rate-limited output. It is a more intuitive way of rate-limiting but
> it may be much more difficult to implement, which is why I went with the
> epoch-based rate limiting solution. In terms of functionality, I believe
> the two solutions are nearly identical for all practical purposes.
>
> Your next section confuses me. As I understand it, using an address as
> input for a transaction will always spends the full amount at that address.
> That’s why change addresses are required, no? If Bitcoin were able to pay
> exact amounts then there wouldn’t be any need for change outputs.
>
> Zac
>
>
> On Thu, 5 Aug 2021 at 08:39, Billy Tetrud  wrote:
>
>> >   A maximum amount is allowed to be spent within EVERY epoch.
>>
>> It sounds like you're proposing an opcode that takes in epochStart and
>> epochEnd as parameters. I still don't understand why its useful to specify
>> those as absolute block heights. You mentioned that this enables more
>> straightforward validation logic, but I don't see how. Eg, if you have a
>> UTXO encumbered by rateLimit(epochStart = 800100, epochEnd = 800200, limit
>> = 100k, remain = 100k), what happens if you don't spend that UTXO before
>> block 800200? Is the output no longer rate limited then? Or is the opcode
>> calculating 800200-800100 = 100 and applying a rate limit for the next
>> epoch? If the first, then the UTXO must be spent within one epoch to remain
>> rate limited. If the second, then it seems nearly 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[ZmnSCPxj via bitcoin-dev]

 fromGood morning Zac,


With some work, what you want can be implemented, to some extent, today, 
without changes to consensus.

The point you want, I believe, is to have two sets of keys:

* A long-term-storage keyset, in "cold" storage.
* A short-term-spending keyset, in "warm" storage, controlling only a small 
amount of funds.

What you can do would be:

* Put all your funds in a single UTXO, with an k-of-n of your cold keys 
(ideally P2TR, or some P2WSH k-of-n).
* Put your cold keys online, and sign a transaction spending the above UTXO, 
and spending most of it to a new address that is a tweaked k-of-n of your cold 
keys, and a smaller output (up to the limit you want) controlled by the k-of-n 
of your warm keys.
  * Keep this transaction offchain, in your warm storage.
* Put your cold keys back offline.
* When you need to spend using your warm keys, bring the above transaction 
onchain, then spend from the budget as needed.


If you need to have some estimated amount of usable funds for every future unit 
of time, just create a chain of transactions with future `nLockTime`.

  nLocktime +1day  nLockTime +2day
  ++   ++   ++
 cold UTXO -->|cold TXO|-->|cold TXO|-->|cold TXO|--> etc.
  ||   ||   ||
  |warm TXO|   |warm TXO|   |warm TXO|
  ++   ++   ++

Pre-sign the above transactions, store the pre-signed transactions in warm 
storage together with your warm keys.
Then put the cold keys back offline.

Then from today to tomorrow, you can spend only the first warm TXO.
>From tomorrow to the day after, you can spend only the first two warm TXOs.
And so on.

If tomorrow your warm keys are stolen, you can bring the cold keys online to 
claim the second cold TXO and limit your fund loss to only just the first two 
warm TXOs.

The above is bulky, but it has the advantage of not using any special opcodes 
or features (improving privacy, especially with P2TR which would in theory 
allow k-of-n/n-of-n to be indistinguishable from 1-of-1), and using just 
`nLockTime`, which is much easier to hide since most modern wallets will set 
`nLockTime` to recent block heights.

Regards,
ZmnSCPxj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

Hi Billy,

> It sounds like you're proposing an opcode

No. I don’t have enough knowledge of Bitcoin to be able to tell how (and
if) rate-limiting can be implemented as I suggested. I am not able to
reason about opcodes, so I kept my description at a more functional level.

> I still don't understand why its useful to specify those as absolute
block heights

I feel that this a rather uninteresting data representation aspect that’s
not worth going back and forth about. Sure, specifying the length of the
epoch may also be an option, although at the price of giving up some
functionality, and without much if any gains.

By explicitly specifying the start and end block of an epoch, the user has
more flexibility in shifting the epoch (using alternate values for
epochStart and epochEnd) and simultaneously increasing the length of an
epoch. These seem rather exotic features, but there’s no harm in retaining
them.

> if you have a UTXO encumbered by rateLimit(epochStart = 800100, epochEnd
= 800200, limit = 100k, remain = 100k), what happens if you don't spend
that UTXO before block 800200?

The rate limit remains in place. So if this UTXO is spent in block 90,
then at most 100k may be spent. Also, the new epoch must be at least 100
blocks and remain must correctly account for the actual amount spent.

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

> rateLimit(windowSize = 144 blocks, limit = 100k sats)

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

Your next section confuses me. As I understand it, using an address as
input for a transaction will always spends the full amount at that address.
That’s why change addresses are required, no? If Bitcoin were able to pay
exact amounts then there wouldn’t be any need for change outputs.

Zac


On Thu, 5 Aug 2021 at 08:39, Billy Tetrud  wrote:

> >   A maximum amount is allowed to be spent within EVERY epoch.
>
> It sounds like you're proposing an opcode that takes in epochStart and
> epochEnd as parameters. I still don't understand why its useful to specify
> those as absolute block heights. You mentioned that this enables more
> straightforward validation logic, but I don't see how. Eg, if you have a
> UTXO encumbered by rateLimit(epochStart = 800100, epochEnd = 800200, limit
> = 100k, remain = 100k), what happens if you don't spend that UTXO before
> block 800200? Is the output no longer rate limited then? Or is the opcode
> calculating 800200-800100 = 100 and applying a rate limit for the next
> epoch? If the first, then the UTXO must be spent within one epoch to remain
> rate limited. If the second, then it seems nearly identical to simply
> specifying window=100 as a parameter instead of epochStart and epochEnd.
>
> > then there must be only a single (rate-limited) output
>
> This rule would make transactions tricky if you're sending money into
> someone else's wallet that may be rate limited. If the requirement is that
> only you yourself can send money into a rate limited wallet, then this
> point is moot but it would be ideal to not have such a requirement.
>
> This is how I'd imagine creating an opcode like this:
>
> rateLimit(windowSize = 144 blocks, limit = 100k sats)
>
> This would define that the epoch is 1 day's worth of blocks. This would
> evenly divide bitcoin's retarget period and so each window would start and
> end at those dividing lines (eg the first 144 blocks of the retargetting
> period, then the second, then the third, etc).
>
> When this output is spent, it ensures that there's a maximum of 100k sats
> is sent to addresses other than the originating address. It also records
> the amount spent in the current 144 block window for that address (eg by
> simply recording the already-spent amount on the resulting UTXO and having
> an index that allows looking up UTXOs by address and adding them up). That
> way, when any output from that address is spent again, if a new 144 block
> window has started, the limit is reset, but if its still within the same
> window, the already-spent amounts for UTXOs from that address are added up
> and subtracted from the limit, and that number is the remaining limit a
> subsequent transaction needs to adhere to.
>
> This way, 3rd party could send transactions into an address like this, and
> multiple outputs can be combined and used to spend to arbitrary outputs (up
> to the rate limit of course).
>
> On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood  wrote:
>
>> > Ah I see, this is all limited to within a single epoch.
>>
>> No, that wouldn't be useful. A maximum amount is allowed to be spent
>> within EVERY epoch.
>>
>> Consider an epoch length of 100 blocks with a spend limit of 200k per
>> epoch. 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Billy Tetrud via bitcoin-dev]

>   A maximum amount is allowed to be spent within EVERY epoch.

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

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

This rule would make transactions tricky if you're sending money into
someone else's wallet that may be rate limited. If the requirement is that
only you yourself can send money into a rate limited wallet, then this
point is moot but it would be ideal to not have such a requirement.

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

rateLimit(windowSize = 144 blocks, limit = 100k sats)

This would define that the epoch is 1 day's worth of blocks. This would
evenly divide bitcoin's retarget period and so each window would start and
end at those dividing lines (eg the first 144 blocks of the retargetting
period, then the second, then the third, etc).

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

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

On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood  wrote:

> > Ah I see, this is all limited to within a single epoch.
>
> No, that wouldn't be useful. A maximum amount is allowed to be spent
> within EVERY epoch.
>
> Consider an epoch length of 100 blocks with a spend limit of 200k per
> epoch. The following is allowed:
>
> epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for
> epoch1: 80k;
> epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining for
> epoch1: 20k;
> epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for
> epoch2: 40k.
>
> Since the limit pertains to each individual epoch, it is allowed to 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 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

> 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 84;
The inputs of tx1 are not rate-limited => tx1 must have only a single
output which will become rate-limited;
params: tx1_epochStart=81, 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 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Billy Tetrud via bitcoin-dev]

> 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=80, 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 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

[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=80, 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 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Billy Tetrud via bitcoin-dev]

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 

[bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

[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 (80, 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 80 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 80: rate-limited address a1 is created;
Value of a1: 100.0m sats;
Rate limiting params of a1: h0=80, h1=800143, a=500k, a_remaining=500k;

Transaction t1:
Included at block height 800100;
Spend: 200k + fee;
Rate limiting params: h0=80, 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=80, 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=80, 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 

[bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[Zac Greenwood via bitcoin-dev]

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 (80, 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 80 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 80: rate-limited address a1 is created;
Value of a1: 100.0m sats;
Rate limiting params of a1: h0=80, h1=800143, a=500k, a_remaining=500k;

Transaction t1:
Included at block height 800100;
Spend: 200k + fee;
Rate limiting params: h0=80, 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=80, 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=80, 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=80, h1=800143,