public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Oleg Andreev <oleganza@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Removing the Dust Limit
Date: Mon, 9 Aug 2021 00:41:32 +0300	[thread overview]
Message-ID: <29C08A0C-E9DA-4D9A-B27A-A5479D2B434E@gmail.com> (raw)
In-Reply-To: <e22dde6c-9a31-60ae-64d0-5e2ff84a6b79@mattcorallo.com>

I agree with Jeremy. Dust limit works due to design accident: that outputs are not encrypted. But outputs are private business and the real issue is only the cost of utxo set storage born by every user. There are two ways to address this:

1) either make ppl pay for renting that storage (which creates a ton of problems of its own)
2) or make storage extremely cheap so it remains cheap at any scale. This is perfectly solved by Utreexo.

But looking at the private data because you can is a hack that creates issues of its own.

> On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead.
> 
> The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like assume-utxo/background history sync it is arguably *the* fundamental scalability constraint of the system. Today's dust limit is incredibly low - its based on a feerate of only 3 sat/vByte in order for claiming the UTXO to have *any* value, not just having enough value to be worth bothering. As feerates have gone up over time, and as we expect them to go up further, we should be considering drastically increasing the 3 sat/vByte basis to something more like 20 sat/vB.
> 
> Matt
> 
>> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote:
>> We should remove the dust limit from Bitcoin. Five reasons:
>> 1) it's not our business what outputs people want to create
> 
> It is precisely our business - the costs are born by us, not the creator. If someone wants to create outputs which don't make sense to spend, they can do so using OP_RETURN, since they won't spend it anyway.
> 
>> 2) dust outputs can be used in various authentication/delegation smart contracts
> 
> So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them outputs.
> 
>> 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 <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)
> 
> This is unrelated to the consensus dust limit. This is related to the practical question about the value of claiming an output. Again, the appropriate way to solve this instead of including spendable dust outputs would be an OP_RETURN output (though I believe this particular problem is actually better solved elsewhere in the lightning protocol).
> 
>> 4) thinly divisible colored coin protocols might make use of sats as value markers for transactions.
> 
> These schemes can and should use values which make them economical to spend. The whole *point* of the dust limit is to encourage people to use values which make sense economically to "clean up" after they're done with them. If people want to use outputs which they will not spend/"clean up" later, they should be using OP_RETURN.
> 
>> 5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers
> 
> This is the reason the dust limit is not a *consensus* limit. If and when CT were to happen we can and would relax the standardness rules around the dust limit to allow for CT.
> 
>> The main reasons I'm aware of not allow dust creation is that:
>> 1) dust is spam
>> 2) dust fingerprinting attacks
> 
> 3) The significant costs to every miner and full node operator.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  reply	other threads:[~2021-08-08 21:41 UTC|newest]

Thread overview: 36+ 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 [this message]
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
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-09 10:25 [bitcoin-dev] " Prayank
2021-08-09 11:58 ` Karl
2022-03-12 13:02 vjudeu

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=29C08A0C-E9DA-4D9A-B27A-A5479D2B434E@gmail.com \
    --to=oleganza@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    --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