path: root/5d/23e998363893f08bdfbf5cdc17ad2326870f98

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 09E5CC000E;
 Tue, 10 Aug 2021 00:30:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id D916C40304;
 Tue, 10 Aug 2021 00:30:24 +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: 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 iQdYnewWwyXL; Tue, 10 Aug 2021 00:30:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [IPv6:2a00:1450:4864:20::530])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 48076402CA;
 Tue, 10 Aug 2021 00:30:20 +0000 (UTC)
Received: by mail-ed1-x530.google.com with SMTP id b7so27482212edu.3;
 Mon, 09 Aug 2021 17:30:20 -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=Z5kJdIDROV3tvBBV8MFjVQKc42wnGuIoZ8MVntq6zkw=;
 b=rmRhz8MLcLhivKEuqDQYlgvqH/zjLJYe2ZPKelBayhJ38qC5fGiOsLZjIlvqKP8XCj
 2L5xpuPYaxnnlNXCBPxJU2gpCRq/LdzWLLnSho3/5cSwoUIGJm1jUxbCn/j4asrwgEM9
 yQSbu4QnMOjGp3zwFEVish7d1ZNT4zSD9I5Iw+OCXJmA0f/goMnD4BkvkdVJ6phbAf+R
 DkR5KWmWkrxhZ7MXG1c4/B+FiySXgicBUma0agFr8Uh0w1sBoqfS2X2+6+YO0Kpomc7d
 Y+osLUTZSN5gD8lWhdAS5eteS5+Gj71rky2yF9KRxAmHJvpwbt14hM4QsfhlytKJT/q3
 eeeg==
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=Z5kJdIDROV3tvBBV8MFjVQKc42wnGuIoZ8MVntq6zkw=;
 b=TEz+R3mtBGAASBJDpvhhDE3x7iAN6KHxhvRLMr7mObsfwbMF7aWedVNcEknTEBcKo9
 Zt/gBxxxoAIjbADvpiztTGN0AvPtnZy3+l/GPFZhNflIacOpEyyBquMbO4dM9KwHUhbI
 HclnXQu1DZpnBjJi9vORvBLQZ+ql3i7JW4KOZBRLTVoifIPMPogDGbUowAmwnc2L6yv4
 aSpVIKvO2q5ogR9Bjzmv8tLsVP3sxfCPEzg2uA4G+x4FzdCTH8MiyF5iCi23wElmI6CS
 TwWGJu561RKbcKuefU8g/T28RYaJbZeltBnmDp/+mJUc5cfxeVs3jwUR6wCtk9pBBpLl
 S4/Q==
X-Gm-Message-State: AOAM531WiluHg575fEZVrc9xlnYjGdEHb/nm5VpjuIOzxlY7cFgNyuKq
 R1A96/OwF5r3P3K6Sa3ICy9sc0NmjflS69gDC+4=
X-Google-Smtp-Source: ABdhPJyQ2vxkOePtY0LT5rmch2PXYxWMkFM0BEIsCLS+BjV6ecf6Wx/dK5+mWp2l8t8hl9a0/Tt0CL5ic33DWkheYLY=
X-Received: by 2002:a50:cc06:: with SMTP id m6mr1315021edi.97.1628555418183;
 Mon, 09 Aug 2021 17:30:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
In-Reply-To: <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 9 Aug 2021 17:30:02 -0700
Message-ID: <CAGpPWDZn6dcuEJXRjUP4VYvJbL9u4mmVoS9xTVzBrGWOM5CeZw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000032aba005c9299b3d"
X-Mailman-Approved-At: Tue, 10 Aug 2021 10:13:00 +0000
Cc: 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: Tue, 10 Aug 2021 00:30:25 -0000

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

> 5) should we ever do confidential transactions we can't prevent it withou=
t compromising
privacy / allowed transfers

I wanted to mention the dubiousness of adding confidential transactions to
bitcoin. Because adding CT would eliminate the ability for users to audit
the supply of Bitcoin, I think its incredibly unlikely to ever happen. I'm
in the camp that we shouldn't do anything that prevents people from
auditing the supply. I think that camp is probably pretty large. Regardless
of what I think should happen there, and even if CT were to eventually
happen in bitcoin, I don't think that future possibility is a good reason
to change the dust limit today.

It seems like dust is a scalability problem regardless of whether we use
Utreexo eventually or not, tho an accumulator would help a ton. One idea
would be to destroy/delete dust at some point in the future. However, even
if we were to plan to do this, I still don't think the dust limit should be
removed. But the dust limit should probably be lowered a bit, given that
the 546 sats limit is about 7 cents and its very doable to send 1 sat/vbyte
transactions, so lowering it to 200 sats seems reasonable.


On Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 mont=
hs
> or years, and would need periodic reevaluations. Those reevaluations, if
> not automated, would become a vector of endless dramas and bikeshedding a=
s
> 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 l=
ow
> feerate periods deployed by such producers of low-value outputs.
> `
> Moreover as an operational point, if we proceed to such an increase on th=
e
> 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 buil=
t
> 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 mechani=
sm
> 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 UTX=
O
> set growth, but for now I would rather solve this with smarter engineerin=
g
> 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 du=
st
> limit in any sense.
>
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714=
.html
> [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=A9c=
rit :
>
>> 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-t=
hat-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
>> value markers for transactions.
>> 5) should we ever do confidential transactions we can't prevent it
>> without 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 t=
hey
>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><span style=3D"color:rgb(80,0,80)">&gt; 5) should we ever =
do confidential transactions we can&#39;t prevent it without</span><span st=
yle=3D"color:rgb(80,0,80)">=C2=A0compromising privacy / allowed transfers</=
span><br><div><span style=3D"color:rgb(80,0,80)"><br></span></div>I wanted =
to mention the dubiousness of adding confidential transactions to bitcoin. =
Because=C2=A0adding CT would eliminate the ability=C2=A0for users to audit =
the supply of Bitcoin, I think its=C2=A0incredibly unlikely to ever happen.=
 I&#39;m in the camp that we shouldn&#39;t do anything that prevents people=
 from auditing the supply. I think that camp is probably pretty=C2=A0large.=
 Regardless of what I think should=C2=A0happen there, and even if CT were t=
o eventually happen in bitcoin, I don&#39;t think that future=C2=A0possibil=
ity is a good reason to change the dust limit today.<div><br><div>It seems =
like dust is a scalability problem regardless of whether we use Utreexo eve=
ntually or not, tho an accumulator would help a ton. One idea would be to d=
estroy/delete dust at some point in the future. However, even if we were to=
 plan to do this, I still don&#39;t think the dust limit should be removed.=
 But the dust limit should probably be lowered a bit, given that the 546 sa=
ts limit is about 7 cents and its very doable to send 1 sat/vbyte transacti=
ons, so lowering it to 200 sats seems reasonable.=C2=A0=C2=A0</div><div><br=
></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>I&#39;m pretty conservative abo=
ut increasing the standard dust limit in any way. This would convert a high=
er percentage of LN channels capacity into dust, which is coming with a low=
ering of funds safety [0]. Of course, we can adjust the LN security model a=
round dust handling to mitigate the safety risk in case of adversarial sett=
ings, but ultimately the standard dust limit creates a=C2=A0 &quot;hard&quo=
t; bound, and as such it introduces a trust vector in the reliability of yo=
ur peer to not goes<br>onchain with a commitment heavily-loaded with dust-H=
TLC you own.<br><br>LN node operators might be willingly to compensate this=
 &quot;dust&quot; 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 &quot;openness&quot; of the LN topology...<=
br><br>Further, I think any authoritative setting of the dust limit present=
s 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 reevalua=
tions, if not automated, would become a vector of endless dramas and bikesh=
edding as the L2s ecosystems grow bigger...<br><br>Note, this would also co=
nstrain the design space of newer fee schemes. Such as negotiated-with-mini=
ng-pool and discounted consolidation during low feerate periods deployed by=
 such producers of low-value outputs.<br>`<br>Moreover as an operational po=
int, if we proceed to such an increase on the base-layer, e.g to 20 sat/vb,=
 we&#39;re going to severely damage the propagation of any LN transaction, =
where a commitment transaction is built with less than 20 sat/vb outputs. O=
f course, core&#39;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&#39;re still devoid of the mechanism to do it cleanly and asynchro=
nously (e.g dynamic upgrade or quiescence protocol [1]).<br><br>That said, =
as raised by other commentators, I don&#39;t deny we have a long-term tensi=
on 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 co=
ins/authentication smart contracts (e.g opentimestamp&#39;s merkle tree in =
OP_RETURN) on the upper layers rather than altering the current equilibrium=
.<br><br>I think the status quo is good enough for now, and I believe we wo=
uld be better off to learn from another development cycle before tweaking t=
he dust limit in any sense.<br><br></div>Antoine<br><div><br>[0] <a href=3D=
"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.=
html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightni=
ng-dev/2020-May/002714.html</a><br>[1] <a href=3D"https://github.com/lightn=
ingnetwork/lightning-rfc/pull/869" target=3D"_blank">https://github.com/lig=
htningnetwork/lightning-rfc/pull/869</a><br></div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0dim. 8 ao=C3=BBt =
2021 =C3=A0=C2=A014:53, Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu" targe=
t=3D"_blank">jlrubin@mit.edu</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_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 reaso=
ns:</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;font-size:small;co=
lor:rgb(0,0,0)">1) it&#39;s not our business what outputs people want to cr=
eate</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 i=
n various authentication/delegation smart contracts</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">3) dust sized htlcs in lightning (<a href=3D"https://bitc=
oin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typic=
ally-be-considered-dust-through-the-light" target=3D"_blank">https://bitcoi=
n.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typical=
ly-be-considered-dust-through-the-light</a>) force channels to operate in a=
 semi-trusted mode which has implications (AFAIU) for the regulatory classi=
fication of channels in various jurisdictions; agnostic treatment of fund t=
ransfers=C2=A0would simplify this (like getting a 0.01 cent dividend check =
in the mail)</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">4) thinly divisible c=
olored coin protocols might make use of sats as value markers for transacti=
ons.</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 confiden=
tial 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><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">The main reasons I&#39;m aware of not allo=
w dust creation is that:</div><div class=3D"gmail_default" style=3D"font-fa=
mily: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-ser=
if;font-size:small;color:rgb(0,0,0)">1) dust is spam</div><div class=3D"gma=
il_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_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor: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) no=
t valid given the 5 reasons above, and 2 is preventable by well behaved wal=
lets 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-ser=
if;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:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">jeremy</div><br clear=3D"all"><div><div dir=3D"=
ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" tar=
get=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" =
target=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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000032aba005c9299b3d--