<div dir="ltr"><div>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<br>onchain with a commitment heavily-loaded with dust-HTLC you own.<br><br>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...<br><br>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...<br><br>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.<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'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]).<br><br>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.<br><br>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.<br><br></div>Antoine<br><div><br>[0] <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html</a><br>[1] <a href="https://github.com/lightningnetwork/lightning-rfc/pull/869">https://github.com/lightningnetwork/lightning-rfc/pull/869</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 8 août 2021 à 14:53, Jeremy <<a href="mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">We should remove the dust limit from Bitcoin. Five reasons:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1) it's not our business what outputs people want to create</div><div class="gmail_default" style="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="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">3) dust sized htlcs in lightning (<a href="https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light" target="_blank">https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light</a>) 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)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">4) thinly divisible colored coin protocols might make use of sats as value markers for transactions.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The main reasons I'm aware of not allow dust creation is that:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1) dust is spam</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) dust fingerprinting attacks</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="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 wallets to not redeem outputs that cost more in fees than they are worth.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">cheers,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">jeremy</div><br clear="all"><div><div dir="ltr"><div dir="ltr">--<br><a href="https://twitter.com/JeremyRubin" target="_blank">@JeremyRubin</a><a href="https://twitter.com/JeremyRubin" target="_blank"></a></div></div></div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div>