Zac Greenwood [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-01 📝 Original message:Hi ZmnSCPxj, The ...
📅 Original date posted:2021-09-01
📝 Original message: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 <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210901/cf80c2eb/attachment.html>;
📝 Original message: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 <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210901/cf80c2eb/attachment.html>;