From: Zac Greenwood <zachgrw@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value
Date: Wed, 1 Sep 2021 17:15:30 +0200 [thread overview]
Message-ID: <CAJ4-pECwa6UTWy+xPp8xr8fRA9CZt=aCCA8tMPODdWsPkX+wNw@mail.gmail.com> (raw)
In-Reply-To: <A8O_5wbTwq48sO02LAHT_t0RN0GVY0yrygt2DiSPrCavXCYu_0LsZWKf3jEQUyBbboW7zQnXyVSHkNJV7CP-VliKOYXjmmnfQIF2Q6E4pl8=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3982 bytes --]
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@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
>
[-- Attachment #2: Type: text/html, Size: 4778 bytes --]
next prev parent reply other threads:[~2021-09-01 15:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-21 5:56 [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud
2021-07-25 5:38 ` David A. Harding
2021-07-25 19:49 ` Billy Tetrud
2021-07-26 0:05 ` David A. Harding
[not found] ` <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com>
2021-07-26 20:18 ` Billy Tetrud
2021-07-26 21:08 ` James MacWhyte
2021-07-27 0:41 ` Billy Tetrud
2021-07-27 11:18 ` Zac Greenwood
2021-07-27 17:21 ` Billy Tetrud
2021-07-28 4:57 ` Zac Greenwood
2021-07-28 17:57 ` Billy Tetrud
2021-07-28 22:30 ` Jeremy
2021-07-30 18:42 ` Billy Tetrud
2021-11-01 1:19 ` Billy Tetrud
2021-07-31 20:01 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood
2021-08-02 4:40 ` Billy Tetrud
2021-08-10 2:17 ` ZmnSCPxj
2021-08-13 11:02 ` Zac Greenwood
2021-08-14 1:50 ` ZmnSCPxj
2021-08-16 11:17 ` Zac Greenwood
2021-08-16 11:48 ` ZmnSCPxj
2021-08-30 14:43 ` Zac Greenwood
2021-08-31 9:00 ` ZmnSCPxj
2021-08-31 14:09 ` Zac Greenwood
2021-08-31 14:22 ` ZmnSCPxj
2021-09-01 15:15 ` Zac Greenwood [this message]
2021-08-01 8:09 Zac Greenwood
2021-08-02 9:32 ` Zac Greenwood
2021-08-03 18:12 ` Billy Tetrud
2021-08-04 10:48 ` Zac Greenwood
2021-08-05 6:39 ` Billy Tetrud
2021-08-05 14:22 ` Zac Greenwood
2021-08-10 0:41 ` Billy Tetrud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ4-pECwa6UTWy+xPp8xr8fRA9CZt=aCCA8tMPODdWsPkX+wNw@mail.gmail.com' \
--to=zachgrw@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox