From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: In-Reply-To: From: Billy Tetrud Date: Mon, 9 Aug 2021 17:30:02 -0700 Message-ID: To: Antoine Riard , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000032aba005c9299b3d" X-Mailman-Approved-At: Tue, 10 Aug 2021 10:13:00 +0000 Cc: lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 >> >> _______________________________________________ >> 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
> 5) should we ever = do confidential transactions we can't prevent it without=C2=A0compromising privacy / allowed transfers

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'm in the camp that we shouldn'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't think that future=C2=A0possibil= ity is a good reason to change the dust limit today.

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'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

On Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev &= lt;bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
I'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 "hard&quo= t; bound, and as such it introduces a trust vector in the reliability of yo= ur peer to not goes
onchain with a commitment heavily-loaded with dust-H= TLC 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...<= 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...

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.
`
Moreover as an operational po= int, 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. O= f 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 asynchro= nously (e.g dynamic upgrade or quiescence protocol [1]).

That said, = as raised by other commentators, I don'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'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 wo= uld be better off to learn from another development cycle before tweaking t= he dust limit in any sense.

Antoine

Le=C2=A0dim. 8 ao=C3=BBt = 2021 =C3=A0=C2=A014:53, Jeremy <jlrubin@mit.edu> a =C3=A9crit=C2=A0:
We should remove the dust limit from Bitcoin. Five reaso= ns:

1) it's not our business what outputs people want to cr= eate
2) dust outputs can be used i= n various authentication/delegation smart contracts
3) dust sized htlcs in lightning (https://bitcoi= n.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typical= ly-be-considered-dust-through-the-light) 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)
4) thinly divisible c= olored coin protocols might make use of sats as value markers for transacti= ons.
5) should we ever do confiden= tial transactions we can't prevent it without compromising=C2=A0privacy= / allowed transfers

The main reasons I'm aware of not allo= w dust creation is that:

1) dust is spam
2) dust fingerprinting attacks

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.

cheers,

jeremy

_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000032aba005c9299b3d--