[Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Pieter Wuille]

Jumping in late to this thread.

I very much agree with how David Harding presents things, with a few comments inline.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> > 1.  it's not our business what outputs people want to create
>
> Every additional output added to the UTXO set increases the amount of
> work full nodes need to do to validate new transactions. For miners
> for whom fast validation of new blocks can significantly affect their
> revenue, larger UTXO sets increase their costs and so contributes
> towards centralization of mining.
> Allowing 0-value or 1-sat outputs minimizes the cost for polluting the
> UTXO set during periods of low feerates.
> If your stuff is going to slow down my node and possibly reduce my
> censorship resistance, how is that not my business?

Indeed - UTXO set size is an externality that unfortunately Bitcoin's consensus rules fail to account
for. Having a relay policy that avoids at the very least economically irrational behavior makes
perfect sense to me.

It's also not obvious how consensus rules could deal with this, as you don't want consensus rules
with hardcoded prices/feerates. There are possibilities with designs like transactions getting
a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without
introducing bad incentives.

> > 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
>
> > 4.  thinly divisible colored coin protocols might make use of sats as value
> >     markers for transactions.

My personal, and possibly controversial, opinion is that colored coin protocols have no business being on the Bitcoin chain, possibly
beyond committing to an occasional batched state update or so. Both because there is little benefit for tokens with a trusted
issuer already, and because it competes with using Bitcoin for BTC - the token that pays for its security (at least as long as
the subsidy doesn't run out).

Of course, personal opinions are no reason to dictate what people should or can use the chain for, but I do think it's reason to
voice hesitancy to worsening the system's scalability properties only to benefit what I consider misguided use.

> > 5.  should we ever do confidential transactions we can't prevent it without
> >     compromising privacy / allowed transfers
>
> I'm not an expert, but it seems to me that you can do that with range
> proofs. The range proof for >dust doesn't need to become part of the
> block chain, it can be relay only.

Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, which could be required as part of a relay policy.

Cheers,

--
Pieter