path: root/f8/400e01783be1d1129c7d0201a257200e3f56f6

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 182D9C000E;
 Mon,  9 Aug 2021 13:22:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id EC14C82AC3;
 Mon,  9 Aug 2021 13:22:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Y6HoLgfY8toe; Mon,  9 Aug 2021 13:22:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [IPv6:2a00:1450:4864:20::334])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 98B2382AA9;
 Mon,  9 Aug 2021 13:22:43 +0000 (UTC)
Received: by mail-wm1-x334.google.com with SMTP id
 w21-20020a7bc1150000b02902e69ba66ce6so351343wmi.1; 
 Mon, 09 Aug 2021 06:22:43 -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=D9LuxlqGKGvErixFCwZl1/ylgq8Ku7Kb+w5TIboqQUU=;
 b=VB+nxdMgkRf+c6MlCjqJYxVUEzBzKlty1cehzadTsMSE9/Qr4d10qe8b/G/HQY5l8S
 86LqATWjgoPxkeP4kS9X7TrwHQMDOYjbDZ42PlXRPQ/iO054NFZrrANa08lZiybKx1UR
 b4sFkBSRhpLx3Ff2Y1gFjyzt4LoUG3BlUBXzSzrdOiQFycX+VqAw6r/hdxVPN+UoDDyM
 iSd5f3Y5iC9YDji00DrEXEuxlabM1bRPwOYcTgk2Y/tIB7oXofHpZQEoErHZAmF70O+d
 6w3DYQlWcsP3DKdnEHWMGDInyoyvUBsKUNnRSTeuFt8IxP6u0wnas0gXwQrqEnhylG3o
 QFoA==
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=D9LuxlqGKGvErixFCwZl1/ylgq8Ku7Kb+w5TIboqQUU=;
 b=VBJBp6cN4G452+6Tbqkt4r+4ivkZyOUFmcgZx1TgHs3mpSZqfYunavsELoqsde9BOm
 Il1TQjd0DlRUNSnLAbgmdrWFyHxYvTtp3ifweKYWo73IdwgXA+Vhruy6NHG6pyDnZNMe
 vGDmo0kOxiAbdaXJZ2k1Fo6CgbZY1pJ2RWOl4LH/nZi4atz7T6eReDs/fhOEC+yuM+Bj
 WPf1zRMClcNBnsPUiQbZ4kC9VpvdQ1kQclwOPY2do7eO46RAXcVKwuuIVvnirBI3wwug
 wXon25E/gMvJqAS+M68N7052bZ1c0XTmBHLiAPujWu7NPtNeETqSApdQagbmuZwyC/+U
 Mt7g==
X-Gm-Message-State: AOAM5304e2G/LRVb7qwEKB2yN9IAcGhFXDxoUrJwFNunrmjiD2YgSDeU
 zZlWZGrLJjtjwNhEJHLm7erPYtZVIf/9cgkxbRI=
X-Google-Smtp-Source: ABdhPJynehGMTdpMo8gPgJaKmlCCkvKl/8K5WkLyhS5exUPFLvGBajcWOm23fmO2U9QJqC60Kl/dbP0BdBfTHsLU4uE=
X-Received: by 2002:a05:600c:4f42:: with SMTP id
 m2mr34955667wmq.47.1628515361662; 
 Mon, 09 Aug 2021 06:22:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
In-Reply-To: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 9 Aug 2021 09:22:28 -0400
Message-ID: <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000a4a96705c92047dc"
X-Mailman-Approved-At: Mon, 09 Aug 2021 13:24:03 +0000
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: Mon, 09 Aug 2021 13:22:45 -0000

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

I'm pretty conservative about increasing the standard dust limit in any
way. This would convert a higher percentage of LN channels capacity into
dust, which is coming with a lowering of funds safety [0]. Of course, we
can adjust the LN security model around dust handling to mitigate the
safety risk in case of adversarial settings, but ultimately the standard
dust limit creates a  "hard" bound, and as such it introduces a trust
vector in the reliability of your peer to not goes
onchain with a commitment heavily-loaded with dust-HTLC you own.

LN node operators might be willingly to compensate this "dust" trust vector
by relying on side-trust model, such as PKI to authenticate their peers or
API tokens (LSATs, PoW tokens), probably not free from consequences for the
"openness" of the LN topology...

Further, I think any authoritative setting of the dust limit presents the
risk of becoming ill-adjusted  w.r.t to market realities after a few months
or years, and would need periodic reevaluations. Those reevaluations, if
not automated, would become a vector of endless dramas and bikeshedding as
the L2s ecosystems grow bigger...

Note, this would also constrain the design space of newer fee schemes. Such
as negotiated-with-mining-pool and discounted consolidation during low
feerate periods deployed by such producers of low-value outputs.
`
Moreover as an operational point, if we proceed to such an increase on the
base-layer, e.g to 20 sat/vb, we're going to severely damage the
propagation of any LN transaction, where a commitment transaction is built
with less than 20 sat/vb outputs. Of course, core's policy deployment on
the base layer is gradual, but we should first give a time window for the
LN ecosystem to upgrade and as of today we're still devoid of the mechanism
to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence
protocol [1]).

That said, as raised by other commentators, I don't deny we have a
long-term tension between L2 nodes and full-nodes operators about the UTXO
set growth, but for now I would rather solve this with smarter engineering
such as utreexo on the base-layer side or multi-party shared-utxo or
compressed colored coins/authentication smart contracts (e.g
opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than
altering the current equilibrium.

I think the status quo is good enough for now, and I believe we would be
better off to learn from another development cycle before tweaking the dust
limit in any sense.

Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.h=
tml
[1] https://github.com/lightningnetwork/lightning-rfc/pull/869

Le dim. 8 ao=C3=BBt 2021 =C3=A0 14:53, Jeremy <jlrubin@mit.edu> a =C3=A9cri=
t :

> We should remove the dust limit from Bitcoin. Five reasons:
>
> 1) it's not our business what outputs people want to create
> 2) dust outputs can be used in various authentication/delegation smart
> contracts
> 3) dust sized htlcs in lightning (
> https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-th=
at-would-typically-be-considered-dust-through-the-light)
> force channels to operate in a semi-trusted mode which has implications
> (AFAIU) for the regulatory classification of channels in various
> jurisdictions; agnostic treatment of fund transfers would simplify this
> (like getting a 0.01 cent dividend check in the mail)
> 4) thinly divisible colored coin protocols might make use of sats as valu=
e
> markers for transactions.
> 5) should we ever do confidential transactions we can't prevent it withou=
t
> compromising privacy / allowed transfers
>
> The main reasons I'm aware of not allow dust creation is that:
>
> 1) dust is spam
> 2) dust fingerprinting attacks
>
> 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by
> well behaved wallets to not redeem outputs that cost more in fees than th=
ey
> are worth.
>
> cheers,
>
> jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

<div dir=3D"ltr"><div>I&#39;m pretty conservative about increasing the stan=
dard dust limit in any way. This would convert a higher percentage of LN ch=
annels capacity into dust, which is coming with a lowering of funds safety =
[0]. Of course, we can adjust the LN security model around dust handling to=
 mitigate the safety risk in case of adversarial settings, but ultimately t=
he standard dust limit creates a=C2=A0 &quot;hard&quot; bound, and as such =
it introduces a trust vector in the reliability of your peer to not goes<br=
>onchain with a commitment heavily-loaded with dust-HTLC you own.<br><br>LN=
 node operators might be willingly to compensate this &quot;dust&quot; trus=
t vector by relying on side-trust model, such as PKI to authenticate their =
peers or API tokens (LSATs, PoW tokens), probably not free from consequence=
s for the &quot;openness&quot; of the LN topology...<br><br>Further, I thin=
k any authoritative setting of the dust limit presents the risk of becoming=
 ill-adjusted=C2=A0 w.r.t to market realities after a few months or years, =
and would need periodic reevaluations. Those reevaluations, if not automate=
d, would become a vector of endless dramas and bikeshedding as the L2s ecos=
ystems grow bigger...<br><br>Note, this would also constrain the design spa=
ce of newer fee schemes. Such as negotiated-with-mining-pool and discounted=
 consolidation during low feerate periods deployed by such producers of low=
-value outputs.<br>`<br>Moreover as an operational point, if we proceed to =
such an increase on the base-layer, e.g to 20 sat/vb, we&#39;re going to se=
verely damage the propagation of any LN transaction, where a commitment tra=
nsaction is built with less than 20 sat/vb outputs. Of course, core&#39;s p=
olicy deployment on the base layer is gradual, but we should first give a t=
ime window for the LN ecosystem to upgrade and as of today we&#39;re still =
devoid of the mechanism to do it cleanly and asynchronously (e.g dynamic up=
grade or quiescence protocol [1]).<br><br>That said, as raised by other com=
mentators, I don&#39;t deny we have a long-term tension between L2 nodes an=
d full-nodes operators about the UTXO set growth, but for now I would rathe=
r solve this with smarter engineering such as utreexo on the base-layer sid=
e or multi-party shared-utxo or compressed colored coins/authentication sma=
rt contracts (e.g opentimestamp&#39;s merkle tree in OP_RETURN) on the uppe=
r layers rather than altering the current equilibrium.<br><br>I think the s=
tatus quo is good enough for now, and I believe we would be better off to l=
earn from another development cycle before tweaking the dust limit in any s=
ense.<br><br></div>Antoine<br><div><br>[0] <a href=3D"https://lists.linuxfo=
undation.org/pipermail/lightning-dev/2020-May/002714.html">https://lists.li=
nuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html</a><br>[1] <=
a href=3D"https://github.com/lightningnetwork/lightning-rfc/pull/869">https=
://github.com/lightningnetwork/lightning-rfc/pull/869</a><br></div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0=
dim. 8 ao=C3=BBt 2021 =C3=A0=C2=A014:53, Jeremy &lt;<a href=3D"mailto:jlrub=
in@mit.edu">jlrubin@mit.edu</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">We should remove the dust limit from Bitcoin. Five reason=
s:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)">1) it&#39;s not our business what outputs people want to cre=
ate</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)">2) dust outputs can be used in=
 various authentication/delegation smart contracts</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">3) dust sized htlcs in lightning (<a href=3D"https://bitco=
in.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typica=
lly-be-considered-dust-through-the-light" target=3D"_blank">https://bitcoin=
.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typicall=
y-be-considered-dust-through-the-light</a>) force channels to operate in a =
semi-trusted mode which has implications (AFAIU) for the regulatory classif=
ication of channels in various jurisdictions; agnostic treatment of fund tr=
ansfers=C2=A0would simplify this (like getting a 0.01 cent dividend check i=
n the mail)</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">4) thinly divisible co=
lored coin protocols might make use of sats as value markers for transactio=
ns.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)">5) should we ever do confident=
ial transactions we can&#39;t prevent it without compromising=C2=A0privacy =
/ allowed transfers</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=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">The main reasons I&#39;m aware of not allow=
 dust creation is that:</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,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-seri=
f;font-size:small;color:rgb(0,0,0)">1) dust is spam</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">2) dust fingerprinting attacks</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or: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)">1 is (IMO) not=
 valid given the 5 reasons above, and 2 is preventable by well behaved wall=
ets to not redeem outputs that cost more in fees than they are worth.</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;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:small;color:rgb(0=
,0,0)">cheers,</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 clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)">jeremy</div><br clear=3D"all"><div><div dir=3D"l=
tr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" targ=
et=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" t=
arget=3D"_blank"></a></div></div></div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>

--000000000000a4a96705c92047dc--