path: root/8f/4a724825a05d9aa5f1dc23b0985f819b1c16cd

Return-Path: <zachgrw@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BA25FC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 14:09:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A9FB6402E0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 14:09:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id gE_k4o7Akl40
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 14:09:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com
 [IPv6:2607:f8b0:4864:20::d2e])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 86AF4402C6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 14:09:16 +0000 (UTC)
Received: by mail-io1-xd2e.google.com with SMTP id f6so25066729iox.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 07:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=kPOGVV7QEvIEAHkWCWnxWqRS24nGbPKecw4dIljJ0hY=;
 b=DycxFPD9vYhGRHRxDhB9ZrexGhzeu/WBiUJyZW6x/ankLobiI8hFqAu7UIUgdFNP0E
 4VvIAXddjtrdOtDwqaBUz94xwLfd+f7RsAZEois0wTN9TOg16dUSQgR0ZGQI36T2YT81
 ZbbWg/4GDTzsNfHJguXwBge65lxzk5FtKxmXPEewGB0QQv/3Od7qxxO5n7n0j5DdnoIy
 NJo30Pk7IN6kQjZpcmBX2IqqC3HsUATDEZeC+dXbbzrxyhdwdFMFp701Z5KI64BNfNhZ
 wgCVuzzjQLn6Mm0MCciXA7uvGeXAqlqulVRIjRGUUD0wdutQ8u6p0f7YKCqvmKryyzln
 7fwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=kPOGVV7QEvIEAHkWCWnxWqRS24nGbPKecw4dIljJ0hY=;
 b=eYwk6IrBYt0508YPcnxxom4I1m+b2cjBBGW9PlLm7B6ssRNcg49mUT9E6CNsW86eO8
 qmBChIz0baJrsP+gOP8wc3PkQ3Qz4BMYZSR4S/0YqC8hw9zPQLcvO4B8yA35vVvqESOf
 STk4K2WB4LPrFfLulC4rs9FAbjzCMeuR59V0Qi0HDqTnRO7hNVwiwQgDwhDEkTDqc6SD
 nZyVLbMnRC+cl9eWcXWNPb0U2MJ+bGleQ0kYPWjqbM8ji6DoW7BLlO/uYkdFz+rVdBQ3
 9+bdSkBwFYaXxyHxlo43Y90t1lPf6QZRdXaYM47M0lgvnbIvn3pqMsyZtXED1uGyiiWi
 RPEQ==
X-Gm-Message-State: AOAM533c7KlJ5z2f9kbedgvxkl4xj64gnth1eQPJdsQurPxAVAI3vFXt
 yoHUUnnEVNe3D/YkCDt99wj8lyerR9DlTPh77pM=
X-Google-Smtp-Source: ABdhPJzOoohZkGoOW9MbPFYrLoJT6fmipQMyzTLtySNfyL0N8daoEyA71hFVHaPGLBKWAQkfffBQNTrQm6SJzUYWIZ0=
X-Received: by 2002:a6b:8bcf:: with SMTP id
 n198mr13479365iod.178.1630418955568; 
 Tue, 31 Aug 2021 07:09:15 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <CAGpPWDYMZ+w3VSaLhR68f4WVq7NCUp3SedwW2e8QnRHOgLQqQg@mail.gmail.com>
 <CAJ4-pEAT8Rrf7dN9A+F2SUvaRz0-DqgDw45whtZcWCTPeQ+uxA@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>
In-Reply-To: <RrFU9zB125CEEua75KWb6IfANybTVN9AGfvjxE65Ysa1zOIgM-h48HmdBcfynW7HEd6kOaA5G-FhAVbmrq5DJXJJYHNArJDORGJklnBCU_I=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Tue, 31 Aug 2021 16:09:04 +0200
Message-ID: <CAJ4-pEC_NTScPFg822Va+Sw1_yC87tWBAL4y7y-m7PSx+JcccQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000ae914605cadb7ecc"
X-Mailman-Approved-At: Tue, 31 Aug 2021 14:17:10 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Aug 2021 14:09:17 -0000

--000000000000ae914605cadb7ecc
Content-Type: text/plain; charset="UTF-8"

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 <ZmnSCPxj@protonmail.com> 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 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
>
>

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

<div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>Thank you for your helpful=
 response. We&#39;re on the same page concerning privacy so I&#39;ll focus =
on that. I understand from your mail that privacy would be reduced by this =
proposal because:</div><div><br></div><div>* It requires the introduction o=
f a new type of transaction that is different from a &quot;standard&quot; t=
ransaction (would that be P2TR in the future?), reducing the anonymity set =
for everyone;</div><div>* The payment and change output will be identifiabl=
e because the change output must be marked encumbered on-chain;</div><div>*=
 The specifics of how the output is encumbered must be visible on-chain as =
well reducing privacy even further.</div><div><br></div><div>I don&#39;t ha=
ve the technical skills to judge whether these issues can somehow be resolv=
ed. 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 encumber=
ed. Perhaps some clever MAST-fu could somehow help?</div><div><br></div><di=
v>I imagine that the offered functionality does not justify the above menti=
oned privacy reductions, so unless these can be addressed, without function=
al modification this proposal sadly seems dead in the water.</div><div><br>=
</div><div>Thanks again.</div><div><br></div><div>Zac</div><div><br></div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, Aug 31, 2021 at 11:00 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@pro=
tonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">Good morning Zac,<br>
<br>
<br>
&gt; Perhaps you could help me understand what would be required to impleme=
nt the *unmodified* proposal. That way, the community will be able to bette=
r assess the cost (in terms of effort and risk) and weigh it against the pe=
rceived benefits. Perhaps *then* we find that the cost could be significant=
ly reduced without any significant reduction of the benefits, for instance =
by slightly compromising on the functionality such that no changes to conse=
nsus would be required for its implementation. (I am skeptical that this wo=
uld be possible though). The cost reduction must be carefully weighed again=
st the functional gaps it creates.<br>
<br>
For one, such output need to be explicitly visible, to implement the &quot;=
change outputs must also be rate-limited&quot;.<br>
A tx spending a rate-limited output has to know that one of the outputs is =
also a rate-limited output.<br>
<br>
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 le=
ft if my understanding is correct --- or blessing yet another anyone-can-sp=
end `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 `scriptP=
ubKey` template we bless for a **long** time).<br>
<br>
Explicit flagging is bad as well for privacy, which is another mark against=
 it.<br>
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 indis=
tinguishable from 1-of-1).<br>
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.<br>
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).<br>
<br>
(Yes, people can just decide not to use the privacy-leaking explicitly-flag=
ged outputs, but that reduces the anonymity set of people who *are* interes=
ted in privacy, so people who are interested in privacy will prefer that ot=
her people do not leak their privacy so they can hide among *those* people =
as well.)<br>
<br>
You also probably need to keep some data with each output.<br>
This can be done by explicitly storing that data in the output directly, ra=
ther than a commitment to that data --- again, the &quot;change outputs mus=
t also be rate-limited&quot; requirement needs to check those data.<br>
<br>
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, becaus=
e often a 20-byte commitment is smaller than the data that needs to be stor=
ed.<br>
For example, I imagine that your original proposal requires, for change out=
puts, to store:<br>
<br>
* The actual rate limit.<br>
* The time frame of the rate limit.<br>
* The reduced rate limit, since we spent an amount within a specific time f=
rame (i.e. residual limit) which is why this is a change output.<br>
* How long that time frame lasts.<br>
* A commitment to the keys that can spend this.<br>
<br>
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.<br>
<br>
The commitment to the keys itself takes at least 20 bytes, and if you are p=
lanning a to support k-of-n then that takes at least 32 bytes.<br>
If this was not explicitly tagged, then a 32 byte commitment to all the nec=
essary data would have been enough, but you do need the explicit tagging fo=
r the &quot;change outputs must be rate-limited too&quot;.<br>
<br>
Note as well that the residual needs to be kept with the output.<br>
Bitcoin Core does not store transactions in a lookup table, it stores indiv=
idual *outputs*.<br>
While the residual can be derived from the transaction, we do not have a tr=
ansaction table.<br>
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 transacti=
ons.<br>
<br>
(well there is `txindex` but that is an option for each node, not something=
 consensus code can rely on)<br>
<br>
So yes, that &quot;change outputs must also be rate-limited&quot; is the bi=
g sticking point, and a lot of the &quot;gaps&quot; you worry about occur w=
hen we drop this bit.<br>
Drop this bit and you can implement it today without any consensus code cha=
nge, and with privacy good enough to prevent people with random letters as =
pseudonym from trying to stop you.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div>

--000000000000ae914605cadb7ecc--