{"type":"rich","version":"1.0","author_name":"npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","author_url":"https://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-08-09\n📝 Original message:\n\u003e 5) should we ever do confidential transactions we can't prevent it without compromising\nprivacy / allowed transfers\n\nI wanted to mention the dubiousness of adding confidential transactions to\nbitcoin. Because adding CT would eliminate the ability for users to audit\nthe supply of Bitcoin, I think its incredibly unlikely to ever happen. I'm\nin the camp that we shouldn't do anything that prevents people from\nauditing the supply. I think that camp is probably pretty large. Regardless\nof what I think should happen there, and even if CT were to eventually\nhappen in bitcoin, I don't think that future possibility is a good reason\nto change the dust limit today.\n\nIt seems like dust is a scalability problem regardless of whether we use\nUtreexo eventually or not, tho an accumulator would help a ton. One idea\nwould be to destroy/delete dust at some point in the future. However, even\nif we were to plan to do this, I still don't think the dust limit should be\nremoved. But the dust limit should probably be lowered a bit, given that\nthe 546 sats limit is about 7 cents and its very doable to send 1 sat/vbyte\ntransactions, so lowering it to 200 sats seems reasonable.\n\n\nOn Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I'm pretty conservative about increasing the standard dust limit in any\n\u003e way. This would convert a higher percentage of LN channels capacity into\n\u003e dust, which is coming with a lowering of funds safety [0]. Of course, we\n\u003e can adjust the LN security model around dust handling to mitigate the\n\u003e safety risk in case of adversarial settings, but ultimately the standard\n\u003e dust limit creates a  \"hard\" bound, and as such it introduces a trust\n\u003e vector in the reliability of your peer to not goes\n\u003e onchain with a commitment heavily-loaded with dust-HTLC you own.\n\u003e\n\u003e LN node operators might be willingly to compensate this \"dust\" trust\n\u003e vector by relying on side-trust model, such as PKI to authenticate their\n\u003e peers or API tokens (LSATs, PoW tokens), probably not free from\n\u003e consequences for the \"openness\" of the LN topology...\n\u003e\n\u003e Further, I think any authoritative setting of the dust limit presents the\n\u003e risk of becoming ill-adjusted  w.r.t to market realities after a few months\n\u003e or years, and would need periodic reevaluations. Those reevaluations, if\n\u003e not automated, would become a vector of endless dramas and bikeshedding as\n\u003e the L2s ecosystems grow bigger...\n\u003e\n\u003e Note, this would also constrain the design space of newer fee schemes.\n\u003e Such as negotiated-with-mining-pool and discounted consolidation during low\n\u003e feerate periods deployed by such producers of low-value outputs.\n\u003e `\n\u003e Moreover as an operational point, if we proceed to such an increase on the\n\u003e base-layer, e.g to 20 sat/vb, we're going to severely damage the\n\u003e propagation of any LN transaction, where a commitment transaction is built\n\u003e with less than 20 sat/vb outputs. Of course, core's policy deployment on\n\u003e the base layer is gradual, but we should first give a time window for the\n\u003e LN ecosystem to upgrade and as of today we're still devoid of the mechanism\n\u003e to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence\n\u003e protocol [1]).\n\u003e\n\u003e That said, as raised by other commentators, I don't deny we have a\n\u003e long-term tension between L2 nodes and full-nodes operators about the UTXO\n\u003e set growth, but for now I would rather solve this with smarter engineering\n\u003e such as utreexo on the base-layer side or multi-party shared-utxo or\n\u003e compressed colored coins/authentication smart contracts (e.g\n\u003e opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than\n\u003e altering the current equilibrium.\n\u003e\n\u003e I think the status quo is good enough for now, and I believe we would be\n\u003e better off to learn from another development cycle before tweaking the dust\n\u003e limit in any sense.\n\u003e\n\u003e Antoine\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html\n\u003e [1] https://github.com/lightningnetwork/lightning-rfc/pull/869\n\u003e\n\u003e Le dim. 8 août 2021 à 14:53, Jeremy \u003cjlrubin at mit.edu\u003e a écrit :\n\u003e\n\u003e\u003e We should remove the dust limit from Bitcoin. Five reasons:\n\u003e\u003e\n\u003e\u003e 1) it's not our business what outputs people want to create\n\u003e\u003e 2) dust outputs can be used in various authentication/delegation smart\n\u003e\u003e contracts\n\u003e\u003e 3) dust sized htlcs in lightning (\n\u003e\u003e https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)\n\u003e\u003e force channels to operate in a semi-trusted mode which has implications\n\u003e\u003e (AFAIU) for the regulatory classification of channels in various\n\u003e\u003e jurisdictions; agnostic treatment of fund transfers would simplify this\n\u003e\u003e (like getting a 0.01 cent dividend check in the mail)\n\u003e\u003e 4) thinly divisible colored coin protocols might make use of sats as\n\u003e\u003e value markers for transactions.\n\u003e\u003e 5) should we ever do confidential transactions we can't prevent it\n\u003e\u003e without compromising privacy / allowed transfers\n\u003e\u003e\n\u003e\u003e The main reasons I'm aware of not allow dust creation is that:\n\u003e\u003e\n\u003e\u003e 1) dust is spam\n\u003e\u003e 2) dust fingerprinting attacks\n\u003e\u003e\n\u003e\u003e 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by\n\u003e\u003e well behaved wallets to not redeem outputs that cost more in fees than they\n\u003e\u003e are worth.\n\u003e\u003e\n\u003e\u003e cheers,\n\u003e\u003e\n\u003e\u003e jeremy\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210809/84b13e96/attachment-0001.html\u003e"}