From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BA25FC000E for ; 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 ; 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 ; 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 ; Tue, 31 Aug 2021 14:09:16 +0000 (UTC) Received: by mail-io1-xd2e.google.com with SMTP id f6so25066729iox.0 for ; 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: <1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com> In-Reply-To: From: Zac Greenwood Date: Tue, 31 Aug 2021 16:09:04 +0200 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000ae914605cadb7ecc" X-Mailman-Approved-At: Tue, 31 Aug 2021 14:17:10 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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 o= f a new type of transaction that is different from a "standard" t= ransaction (would that be P2TR in the future?), reducing the anonymity set = for everyone;
* The payment and change output will be identifiabl= e 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 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?

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.

=
Thanks again.

Zac

<= /div>
O= n 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 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.

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 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).

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 indis= tinguishable 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-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.)

You also probably need to keep some data with each output.
This can be done by explicitly storing that data in the output directly, ra= ther than a commitment to that data --- again, the "change outputs mus= t 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, becaus= e often a 20-byte commitment is smaller than the data that needs to be stor= ed.
For example, I imagine that your original proposal requires, for change out= puts, 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 f= rame (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 p= lanning 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 nec= essary data would have been enough, but you do need the explicit tagging fo= r 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 indiv= idual *outputs*.
While the residual can be derived from the transaction, we do not have a tr= ansaction 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 transacti= ons.

(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 bi= g sticking point, and a lot of the "gaps" you worry about occur w= hen we drop this bit.
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.

Regards,
ZmnSCPxj

--000000000000ae914605cadb7ecc--