Date: Thu, 30 Sep 2021 22:07:08 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Reply-To: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net>
In-Reply-To: <20210808215101.wuaidu5ww63ajx6h@ganymede>
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <20210808215101.wuaidu5ww63ajx6h@ganymede>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Precedence: list

Jumping in late to this thread.

I very much agree with how David Harding presents things, with a few commen=
ts inline.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev <b=
itcoin-dev@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 conse=
nsus rules fail to account
for. Having a relay policy that avoids at the very least economically irrat=
ional 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 t=
ransactions getting
a size/weight bonus/penalty, but that's both very hardforky, and hard to ge=
t 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-amou=
nts-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 v=
alue
> >     markers for transactions.

My personal, and possibly controversial, opinion is that colored coin proto=
cols 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 to=
ken 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 be=
nefit what I consider misguided use.

> > 5.  should we ever do confidential transactions we can't prevent it wit=
hout
> >     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