Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BD564C000E for ; Sun, 8 Aug 2021 22:46:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id AD8F2402C8 for ; Sun, 8 Aug 2021 22:46:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4H8HPYQhh1Lr for ; Sun, 8 Aug 2021 22:46:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id 8FC8440279 for ; Sun, 8 Aug 2021 22:46:39 +0000 (UTC) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 178MkbTw009582 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 8 Aug 2021 18:46:38 -0400 Received: by mail-io1-f50.google.com with SMTP id a13so25081848iol.5 for ; Sun, 08 Aug 2021 15:46:38 -0700 (PDT) X-Gm-Message-State: AOAM5328h+HvF1vHzyS9J4eyHitdc27755fA41IHhdkwExPu5VNU6Kcc jGCEbf5Os+gDDCwb57WYMSAlBNnH1Tvnula+u4I= X-Received: by 2002:a05:6638:3a12:: with SMTP id j18mt19857259jaj.75.1628462797311; Sun, 08 Aug 2021 15:46:37 -0700 (PDT) MIME-Version: 1.0 References: <20210808215101.wuaidu5ww63ajx6h@ganymede> In-Reply-To: <20210808215101.wuaidu5ww63ajx6h@ganymede> From: Jeremy Date: Sun, 8 Aug 2021 15:46:26 -0700 X-Gmail-Original-Message-ID: Message-ID: Content-Type: multipart/alternative; boundary="000000000000923dcf05c9140a7a" Cc: Bitcoin development mailing list , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 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: Sun, 08 Aug 2021 22:46:41 -0000 --000000000000923dcf05c9140a7a Content-Type: text/plain; charset="UTF-8" Under no circumstances do I think we should *increase* the dust limit. That would have a mildly confiscatory effect on current Lightning Channel operators, among others. Generally, the UTXO set will grow. We should work to accommodate the worst case scenario under current consensus rules. I think this points to using things like Utreexo or similar rather than meddling in the user's business. I am skeptical that 0 value outputs are a real spam problem given the cost to create. Generally one creates an output when one either believes it would make sense to redeem it in the future. So surely this is a market problem, if people want them they can pay what it is worth for them to have it. Again, it's not my business. Matt proposes that people might use a nominal amount of bitcoin on a zero value input so that it doesn't look like dust. What Matt is asking for is that in any protocol you pay for your space not via fees, but instead via an assurance bond that you will eventually redeem it and clean the state up. In my opinion, this is worse than just allowing a zero value input since then you might accrue the need for an additional change output to which the bond's collateral be returned. With respect to the check in the mail analogy, cutting down trees for paper is bad for everyone and shipping things using fossil fuels contributes to climate change. Therefore it's a cost borne by society in some respects. Still, if someone else decides it's worth sending a remittance of whichever value, it is still not my business. With respect to CT and using the range proofs to exclude dust, I'm aware that can be done (hence compromising allowed transfers). Again, I don't think it's quite our business what people do, but on a technical level, this would have the impact of shrinking the anonymity set so is also suspect to me. --------------- If we really want to create incentives for state clean up, I think it's a decent design space to consider. e.g., we could set up a bottle deposit program whereby miners contribute an amount of funds from fee revenue from creating N outputs to a "rolling utxo" (e.g., a coinbase utxo that gets spent each block op_true to op_true under some miner rules) and the rolling utxo can either disperse funds to the miner reward or soak up funds from the fees in order to encourage blocks which have a better ratio of inputs to outputs than the mean. Miners can then apply this rule in the mempool to prioritize transactions that help their block's ratio. This is all without directly interfering with the user's intent to create whatever outputs they want, it just provides a way of paying miners to clean up the public common. Gas Token by Daian et al comes to mind, from Eth, w.r.t. many pitfalls arbing these state space freeing return curves, but it's worth thinking through nonetheless. --000000000000923dcf05c9140a7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Under no circumstances= do I think we should *increase* the dust limit. That would have a mildly c= onfiscatory effect on current Lightning Channel operators, among others.

Generally, the UTXO set will grow. We should work to accommodate = the worst case=C2=A0scenario under current consensus rules. I think this po= ints to using things like Utreexo or similar rather than meddling in the us= er's business.

I am skeptical that 0 value outputs are a re= al spam problem given the cost to create. Generally one creates an output w= hen one either believes=C2=A0it would make sense to redeem it in the future= . So surely this is a market problem, if people want them they can pay what= it is worth for them to have it. Again, it's not my business.

Matt proposes that people might use a nominal amount of bitcoin on a ze= ro value input so that it doesn't look like dust. What Matt is asking f= or is that in any protocol you pay for your space not via fees, but instead= via an assurance bond that you will eventually redeem it and clean the=C2= =A0state up. In my opinion, this is worse than just allowing a zero value i= nput since then you might accrue the need for an additional change output t= o which the bond's collateral be returned.

With respect to = the check in the mail analogy, cutting down trees for paper is bad for ever= yone and shipping things using fossil fuels contributes to climate change. = Therefore it's a cost borne by society in some respects. Still, if some= one else decides it's worth sending a remittance=C2=A0of whichever valu= e, it is still not my business.
With respect to CT and using th= e range proofs to exclude dust, I'm aware that can be done (hence compr= omising allowed transfers). Again, I don't think it's quite our bus= iness what people do, but on a technical level, this would have the impact = of shrinking the anonymity set so is also suspect to me.

------= ---------

If we really want to create incentives for state clea= n up, I think it's a decent design space to consider.

e.g= ., we could set up a bottle deposit program whereby miners contribute an am= ount of funds from fee revenue from creating N outputs to a "rolling u= txo" (e.g., a coinbase utxo that gets spent each block op_true to op_t= rue under some miner rules) and the rolling utxo can either disperse funds = to the miner reward or soak up funds from the fees in order to encourage bl= ocks which have a better ratio of inputs to outputs than the mean. Miners c= an then apply this rule in the mempool to prioritize transactions that help= their block's ratio. This is all without directly interfering with the= user's intent to create whatever outputs they want, it just provides a= way of paying miners to clean up the public common.

Gas Token = by Daian et al comes to mind, from Eth, w.r.t. many pitfalls arbing these s= tate space freeing return curves, but it's worth thinking through nonet= heless.
--000000000000923dcf05c9140a7a--