public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Date: Mon, 9 Aug 2021 17:30:02 -0700	[thread overview]
Message-ID: <CAGpPWDZn6dcuEJXRjUP4VYvJbL9u4mmVoS9xTVzBrGWOM5CeZw@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5918 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 9496 bytes --]

  reply	other threads:[~2021-08-10  0:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-08 18:52 [bitcoin-dev] Removing the Dust Limit Jeremy
2021-08-08 21:14 ` Matt Corallo
2021-08-08 21:41   ` Oleg Andreev
2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding
2021-08-08 22:46   ` Jeremy
2021-08-08 23:07   ` Jeremy
2021-09-30 22:07   ` Pieter Wuille
2021-10-01 13:40     ` Erik Aronesty
2021-10-07  4:52       ` ZmnSCPxj
2021-10-07  8:17         ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07  8:34           ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 10:35             ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07  9:13         ` shymaa arafat
2021-10-07 10:01           ` ZmnSCPxj
     [not found]             ` <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>
     [not found]               ` <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
2021-10-08  7:44                 ` shymaa arafat
2021-10-08 10:38                   ` ZmnSCPxj
2021-10-08 22:47     ` ZmnSCPxj
2021-08-09 13:22 ` Antoine Riard
2021-08-10  0:30   ` Billy Tetrud [this message]
2021-08-10  5:04     ` Jeremy
2021-08-10  5:44       ` Billy Tetrud
2021-08-10 11:37         ` ZmnSCPxj
2021-08-10 18:39           ` Charlie Lee
2021-08-10  6:14   ` David A. Harding
2021-08-10 22:37     ` Antoine Riard
2021-08-11  0:46       ` ZmnSCPxj
2021-08-12 22:03       ` Anthony Towns
2021-08-20  4:51         ` Jeremy
2021-08-20  5:45           ` shymaa arafat
2021-08-21  3:10           ` ZmnSCPxj
2021-08-26 21:21             ` Billy Tetrud
2021-08-27  9:07               ` shymaa arafat
2021-08-30  3:31                 ` LORD HIS EXCELLENCY JAMES HRMH
2021-08-18 19:06 shymaa arafat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGpPWDZn6dcuEJXRjUP4VYvJbL9u4mmVoS9xTVzBrGWOM5CeZw@mail.gmail.com \
    --to=billy.tetrud@gmail.com \
    --cc=antoine.riard@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox