path: root/27/7ab21204da814afeb864ac6c9a214aaf64a868

Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B3E74C000E;
 Sun,  8 Aug 2021 23:07:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 9B503400AE;
 Sun,  8 Aug 2021 23:07:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 95y3YFmT2Vts; Sun,  8 Aug 2021 23:07:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
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 smtp2.osuosl.org (Postfix) with ESMTPS id 0436A400A8;
 Sun,  8 Aug 2021 23:07:40 +0000 (UTC)
Received: from mail-io1-f48.google.com (mail-io1-f48.google.com
 [209.85.166.48]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 178N7dtc013940
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
 Sun, 8 Aug 2021 19:07:39 -0400
Received: by mail-io1-f48.google.com with SMTP id l20so22962151iom.4;
 Sun, 08 Aug 2021 16:07:39 -0700 (PDT)
X-Gm-Message-State: AOAM5305mbHVJ/GLzkJY9YRUV2pVS9asuplLFFi5APOsitmS6FZff8YY
 XoTlJyM1Zw7FHTOmx7gK5DnRqsZm0CCL/IUbSiE=
X-Google-Smtp-Source: ABdhPJwGvXbvM/Bp9AdU9YnFUZp6vYWcQb6fW0R1MR/RXoCbmfZkV7NI6OyUAcyI50mxWPiibawSWPLokAq2FlLxgBY=
X-Received: by 2002:a6b:8f03:: with SMTP id r3mr185582iod.31.1628464058864;
 Sun, 08 Aug 2021 16:07:38 -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 16:07:27 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgNUuXW=ZnXHgawQrM6ywRrZAR5HFi+kkyUt3bLe1u99Q@mail.gmail.com>
Message-ID: <CAD5xwhgNUuXW=ZnXHgawQrM6ywRrZAR5HFi+kkyUt3bLe1u99Q@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000c2174505c914557c"
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 tarun@gauntlet.network
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 23:07:42 -0000

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

some additional answers/clarifications



> Question for Jeremy: would you also allow zero-value outputs?  Or would
> you just move the dust limit down to a fixed 1-sat?
>

I would remove it entirely -- i don't think there's a difference between
the two realistically.



>
> Allowing 0-value or 1-sat outputs minimizes the cost for polluting the
> UTXO set during periods of low feerates.
>
>
Maybe that incentivizes people to make better use of the low
feerate periods to do more important work like consolidations so that
others do not have the opportunity to pollute (therefore eliminating the
low fee period ;)



> If your stuff is going to slow down my node and possibly reduce my
> censorship resistance, how is that not my business?
>

You don't know that's what I'm doing, it's a guess as to my future behavior.

If it weren't worth it to me, I wouldn't be doing it. Market will solve
what is worth v.s. not worth.



>
> > 2) dust outputs can be used in various authentication/delegation smart
> > contracts
>
> All of which can also use amounts that are economically rational to
> spend on their own.  If you're gonna use the chain for something besides
> value transfer, and you're already wiling to pay X in fees per onchain
> use, why is it not reasonable for us to ask you to put up something on
> the order of X as a bond that you'll actually clean up your mess when
> you're no longer interested in your thing?
>

These authentication/delegation smart contracts can be a part of value
transfer e.g. some type of atomic swaps or other escrowed payment.

A bond to clean it up is a fair reason; but perhaps in a protocol it might
not make sense to clean up the utxo otherwise and so you're creating a
cleanup transaction (potentially has to be presigned in a way it can't be
done as a consolidation) and then some future consolidation to make the
dusts+eps aggregately convenient to spend. So you'd be trading a decent
amount more chainspace v.s. just ignoring the output and writing it to disk
and maybe eventually into a utreexo (e.g. imagine utreexo where the last N
years of outputs are held in memory, but eventually things get tree'd up)
so the long term costs need not be entirely bourne in permanent storage.


>
> Nope, nothing is forced.  Any LN node can simply refuse to accept/route
> HTLCs below the dust limit.
>

I'd love to hear some broad thoughts on the impact of this on routing (cc
Tarun who thinks about these things a decent amount) as this means for
things like multipath routes you have much stricter constraints on which
nodes you can route payments through. The impact on capacity from every
user's pov might be not insubstantial.



>
> I also doubt your proposed solution fixes the problem.  Any LN node that
> accepts an uneconomic HTLC cannot recover that value, so the money is
> lost either way.  Any sane regulation would treat losing value to
> transaction fees the same as losing value to uneconomical conditions.
>
> Finally, if LN nodes start polluting the UTXO set with no economic way
> to clean up their mess, I think that's going to cause tension between
> full node operators and LN node operators.
>



My anticipation is that the LN operators would stick the uneconomic HTLCs
aggregately into a fan out utxo and try to cooperate, but failing that only
pollute the chain by O(1) for O(n) non economic HTLCs. There is a
difference between losing money and knowing exactly where it is but not
claiming it.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)">some additional answers/clarifications</div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex">Question for Jeremy: would you also allow zero-value=
 outputs?=C2=A0 Or would<br>
you just move the dust limit down to a fixed 1-sat?<br></blockquote><div><b=
r></div><div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">I would remove it entirely=
 -- i don&#39;t think there&#39;s a difference between the two realisticall=
y.</div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Allowing 0-value or 1-sat outputs minimizes the cost for polluting the<br>
UTXO set during periods of low feerates.<br>
<br></blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Ma=
ybe that incentivizes people to make better use of the low feerate=C2=A0per=
iods to do more important work like consolidations so that others do not ha=
ve the opportunity to pollute (therefore eliminating the low fee period ;)<=
/div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex">
If your stuff is going to slow down my node and possibly reduce my<br>
censorship resistance, how is that not my business?<br></blockquote><div><b=
r></div><div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">You don&#39;t know that&#3=
9;s what I&#39;m doing, it&#39;s a guess as to my future behavior.</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)">If it weren&#39;t worth it to me, I wouldn&#39;t be doing it. Market wi=
ll solve what is worth v.s. not worth.</div><br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex">
<br>
&gt; 2) dust outputs can be used in various authentication/delegation smart=
<br>
&gt; contracts<br>
<br>
All of which can also use amounts that are economically rational to<br>
spend on their own.=C2=A0 If you&#39;re gonna use the chain for something b=
esides<br>
value transfer, and you&#39;re already wiling to pay X in fees per onchain<=
br>
use, why is it not reasonable for us to ask you to put up something on<br>
the order of X as a bond that you&#39;ll actually clean up your mess when<b=
r>
you&#39;re no longer interested in your thing?<br></blockquote><div><br></d=
iv><div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)">These authentication/delegation=
 smart contracts can be a part of value transfer e.g. some type of atomic s=
waps or other escrowed payment.</div><br></div><div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)">A bond to clean it up is a fair reason; but perhaps in a proto=
col it might not make sense to clean up the utxo otherwise and so you&#39;r=
e creating a cleanup transaction (potentially has to be presigned=C2=A0in a=
 way it can&#39;t be done as a consolidation) and then some future consolid=
ation to make the dusts+eps aggregately convenient to spend. So you&#39;d b=
e trading a decent amount more chainspace v.s. just ignoring the output and=
 writing it to disk and maybe eventually into a utreexo (e.g. imagine utree=
xo where the last N years of outputs are held in memory, but eventually thi=
ngs get tree&#39;d up) so the long term costs need not be entirely bourne i=
n permanent storage.</div></div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Nope, nothing is forced.=C2=A0 Any LN node can simply refuse to accept/rout=
e<br>
HTLCs below the dust limit.<br></blockquote><div><br></div><div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">I&#39;d love to hear some broad thoughts on the i=
mpact of this on routing (cc Tarun who thinks about these things a decent a=
mount) as this means for things like multipath routes you have much stricte=
r constraints on which nodes you can route payments through. The impact on =
capacity from every user&#39;s pov might be not insubstantial.</div><br></d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex"><br>
I also doubt your proposed solution fixes the problem.=C2=A0 Any LN node th=
at<br>
accepts an uneconomic HTLC cannot recover that value, so the money is<br>
lost either way.=C2=A0 Any sane regulation would treat losing value to<br>
transaction fees the same as losing value to uneconomical conditions.<br>
<br>
Finally, if LN nodes start polluting the UTXO set with no economic way<br>
to clean up their mess, I think that&#39;s going to cause tension between<b=
r>
full node operators and LN node operators.<br></blockquote><div><br></div><=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)"><br></div></div><div><br></div><div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">My anticipation is that the LN operato=
rs would stick the uneconomic HTLCs aggregately into a fan out utxo and try=
 to cooperate, but failing that only pollute the chain by O(1) for O(n) non=
 economic HTLCs. There is a difference between losing money and knowing exa=
ctly where it is but not claiming it.</div><br></div><div><br></div></div><=
/div>

--000000000000c2174505c914557c--