rich1.0npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnnshttps://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnnsnjumphttps://nostr.ae📅 Original date posted:2021-08-09 📝 Original message: > 5) should we ever do confidential transactions we can't prevent it without 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 at 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 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.html > [1] https://github.com/lightningnetwork/lightning-rfc/pull/869 > > Le dim. 8 août 2021 à 14:53, Jeremy <jlrubin at mit.edu> a écrit : > >> 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-that-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 they >> are worth. >> >> cheers, >> >> jeremy >> >> -- >> @JeremyRubin <https://twitter.com/JeremyRubin> >> <https://twitter.com/JeremyRubin> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210809/84b13e96/attachment-0001.html>