MIME-Version: 1.0
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <T9dyi_J_ZLwT8hXaxOBlCEhdoB9hsBcvFZX3r1JrtxunUTnFe7wefV6hi3Itw8z84drqAn64ZCJhfSfz7Aw0cqx4Aa8DtN1irvE-d4JPoeE=@protonmail.com>
 <CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com>
 <1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com>
 <CAJ4-pECSE=by2ag4QmqrXbX_R0sk6HOL1KH0z2h=+915jaEE6Q@mail.gmail.com>
 <wdlRrp4fZxH79mzVpTQWp99V9uI8jLvRU40mwdJ8lZ5A2mGMsxUK1TmZEZTV7O4_eUnNyq3feEGv5BUN-ecPSlbL-EYR6ZyLxk9ErsFiPlE=@protonmail.com>
 <CAJ4-pECwGfrrB15oS0t-+vsjn11sC=9Bz6JGsGsicUorCjuYpA@mail.gmail.com>
 <RrFU9zB125CEEua75KWb6IfANybTVN9AGfvjxE65Ysa1zOIgM-h48HmdBcfynW7HEd6kOaA5G-FhAVbmrq5DJXJJYHNArJDORGJklnBCU_I=@protonmail.com>
 <CAJ4-pEC_NTScPFg822Va+Sw1_yC87tWBAL4y7y-m7PSx+JcccQ@mail.gmail.com>
 <A8O_5wbTwq48sO02LAHT_t0RN0GVY0yrygt2DiSPrCavXCYu_0LsZWKf3jEQUyBbboW7zQnXyVSHkNJV7CP-VliKOYXjmmnfQIF2Q6E4pl8=@protonmail.com>
In-Reply-To: <A8O_5wbTwq48sO02LAHT_t0RN0GVY0yrygt2DiSPrCavXCYu_0LsZWKf3jEQUyBbboW7zQnXyVSHkNJV7CP-VliKOYXjmmnfQIF2Q6E4pl8=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Wed, 1 Sep 2021 17:15:30 +0200
Message-ID: <CAJ4-pECwa6UTWy+xPp8xr8fRA9CZt=aCCA8tMPODdWsPkX+wNw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000001e1b7105caf08abf"
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
Precedence: list

--0000000000001e1b7105caf08abf
Content-Type: text/plain; charset="UTF-8"

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
>

--0000000000001e1b7105caf08abf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>The rate-=
limiting algorithm would be relatively straightforward. I documented the ra=
te-limiting part of the algorithm below, perhaps they can evoke new ideas o=
f how to make this MAST-able or otherwise implement this in a privacy prese=
rving way.</div><div><br></div><div>Something like the following:</div><div=
><br></div><div>=3D&gt; Create an output at block height [h0] with the foll=
owing properties:</div><div><br></div><div><div>Serving as input at any blo=
ck height, the maximum amount is limited to [limit] sats;=C2=A0 // This rul=
e introduces [limit] and is permanent and always copied over to a change ou=
tput</div><div>Serving as input at a block height &lt; [h0 + window], the m=
aximum amount is limited to [limit - 0] sats;=C2=A0 // [limit - 0] to empha=
size that nothing was spent yet and no window has started.</div></div><div>=
<br></div><div>=3D&gt; A transaction occurs at block height [h1], spending =
[h1_spent].</div><div>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</div><div><br></div><div>The=
 change output created at block height [h1] must be encumbered as follows:<=
/div><div><div>Serving as input at any block height, the maximum amount is =
limited to [limit] sats;=C2=A0 // Permanent rule repeats</div><div>Serving =
as input at a block height &lt; [h1 + window], the maximum amount is limite=
d to [limit - h1_spent]=C2=A0 // Second permanent rule reduces spendable am=
ount until height [h1 + window] by [h1_spent]</div><div><br></div><div>=3D&=
gt; A second transaction occurs at block height [h2], spending [h2_spent].<=
/div><div><div><div>The payment output created at [h2] is not encumbered an=
d of value [h2_spent]; // Second transaction, so a second window starts at =
[h2]</div><div><br></div></div><div>The change output created at block heig=
ht [h2] must be encumbered as follows:</div><div>Serving as input at any bl=
ock height, the maximum amount is limited to [limit] sats;=C2=A0 // Permane=
nt rule repeats<br></div><div>Serving as input at a block height &lt; [h1=
=C2=A0+ window], the max amount is limited to [limit - h1_spent - h2_spent]=
 // Reduce spendable amount between [h1] and [h1=C2=A0+ window] by an addit=
ional [h2_spent]</div><div>Serving as input in range [h1 + window] &lt;=3D =
block height &lt; [h2 + window], the max amount is limited to [limit - h2_s=
pent]=C2=A0 // First payment no longer inside this window so [h1_spent] no =
longer subtracted</div><div><br></div><div>... and so on. A rule that perta=
ins to a block height &lt; the current block height can be abandoned, keepi=
ng the number of rules equal to the number of transactions that exist withi=
n the oldest still active window.</div></div></div><div><br></div><div>Zac<=
/div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Tue, Aug 31, 2021 at 4:22 PM ZmnSCPxj &lt;<a href=3D=
"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Zac,<b=
r>
<br>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; Thank you for your helpful response. We&#39;re on the same page concer=
ning privacy so I&#39;ll focus on that. I understand from your mail that pr=
ivacy would be reduced by this proposal because:<br>
&gt;<br>
&gt; * It requires the introduction of a new type of transaction that is di=
fferent from a &quot;standard&quot; transaction (would that be P2TR in the =
future?), reducing the anonymity set for everyone;<br>
&gt; * The payment and change output will be identifiable because the chang=
e output must be marked encumbered on-chain;<br>
&gt; * The specifics of how the output is encumbered must be visible on-cha=
in as well reducing privacy even further.<br>
&gt;<br>
&gt; I don&#39;t have the technical skills to judge whether these issues ca=
n 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 s=
till being encumbered. Perhaps some clever MAST-fu could somehow help?<br>
<br>
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 dev=
eloping these (aj I think? RubenSomsen?) might be able to accommodate this =
or some subset of the desired feature in a sufficiently clever covenant sch=
eme.<br>
<br>
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.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>

--0000000000001e1b7105caf08abf--