path: root/58/fba654c516da03fadba205441524d622a42c93

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BD564C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; Sun, 8 Aug 2021 18:46:38 -0400
Received: by mail-io1-f50.google.com with SMTP id a13so25081848iol.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <20210808215101.wuaidu5ww63ajx6h@ganymede>
In-Reply-To: <20210808215101.wuaidu5ww63ajx6h@ganymede>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 8 Aug 2021 15:46:26 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhbo6yMiNbSSgtjK8o0m5gm+2hmQN54Xj+pX7nu4xtByw@mail.gmail.com>
Message-ID: <CAD5xwhhbo6yMiNbSSgtjK8o0m5gm+2hmQN54Xj+pX7nu4xtByw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="000000000000923dcf05c9140a7a"
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
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 <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: 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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)">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&#39;s business.</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">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&#39;s not my business.</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">Matt proposes that people might use a nominal amount of bitcoin on a ze=
ro value input so that it doesn&#39;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&#39;s collateral be returned.</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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&#39;s a cost borne by society in some respects. Still, if some=
one else decides it&#39;s worth sending a remittance=C2=A0of whichever valu=
e, it is still not my business.</div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b=
r></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)">With respect to CT and using th=
e range proofs to exclude dust, I&#39;m aware that can be done (hence compr=
omising allowed transfers). Again, I don&#39;t think it&#39;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.</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">------=
---------</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">If we really want to create incentives for state clea=
n up, I think it&#39;s a decent design space to consider.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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 &quot;rolling u=
txo&quot; (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&#39;s ratio. This is all without directly interfering with the=
 user&#39;s intent to create whatever outputs they want, it just provides a=
 way of paying miners to clean up the public common.</div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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&#39;s worth thinking through nonet=
heless.</div></div>

--000000000000923dcf05c9140a7a--