path: root/4b/767f9ede27cffbbd07cc964cc6651e8830170d

Return-Path: <dave@dtrt.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D53A8C000E;
 Sun,  8 Aug 2021 21:52:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B0F0C4010F;
 Sun,  8 Aug 2021 21:52:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.075
X-Spam-Level: *
X-Spam-Status: No, score=1.075 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_XBL=0.375,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1]
 autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=dtrt.org
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id d6Su4nrJE3s5; Sun,  8 Aug 2021 21:52:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from newmail.dtrt.org (newmail.dtrt.org
 [IPv6:2600:3c03::f03c:91ff:fe7b:78d1])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 157BC400AE;
 Sun,  8 Aug 2021 21:52:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org;
 s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:
 Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=ZhL0vMJhq5sic081ChPC2E+Q3OiCqHkR8PApQ5/tkt0=; b=VkC9PSyC21BRWI2QQ+BgNxJr98
 cVBzNeH0Ri5nzEvNiat2JJhFfKvzARChdebUeJQthpUUxry+9TwT0ptsSqntoBhckNM5OqJVTPsfU
 7fqmA1WJnkuke0FhazNjp1YWZQWd++g6wv8AWzQWZKp5NzEQOKGA7XxM9/hhZEr6EnzY=;
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
 (envelope-from <dave@dtrt.org>)
 id 1mCqid-0007yI-4k; Sun, 08 Aug 2021 11:52:31 -1000
Date: Sun, 8 Aug 2021 11:51:01 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Jeremy <jlrubin@mit.edu>
Message-ID: <20210808215101.wuaidu5ww63ajx6h@ganymede>
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="doahxmd3go2jqdi4"
Content-Disposition: inline
In-Reply-To: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
User-Agent: NeoMutt/20180716
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Aug 2021 21:52:34 -0000


--doahxmd3go2jqdi4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote:
> We should remove the dust limit from Bitcoin. Five reasons:

Jeremy knows this, but to be clear for other readers, the dust limit is
a policy in Bitcoin Core (and other software) where it refuses by
default to relay or mine transactions with outputs below a certain
amount.  If nodes or miners running with non-default policy choose to
relay or mine those transactions, they are not penalized (not directly,
at least; there's BIP152 to consider).

Question for Jeremy: would you also allow zero-value outputs?  Or would
you just move the dust limit down to a fixed 1-sat?

I think the dust limit is worth keeping:

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

> 2) dust outputs can be used in various authentication/delegation smart
> contracts

All of which can also use amounts that are economically rational to
spend on their own.  If you're gonna use the chain for something besides
value transfer, and you're already wiling to pay X in fees per onchain
use, why is it not reasonable for us to ask you to put up something on
the order of X as a bond that you'll actually clean up your mess when
you're no longer interested in your thing?

> 3) dust sized htlcs in lightning (
> https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-th=
at-would-typically-be-considered-dust-through-the-light)
> force channels to operate in a semi-trusted mode=20

Nope, nothing is forced.  Any LN node can simply refuse to accept/route
HTLCs below the dust limit.

> which has implications
> (AFAIU) for the regulatory classification of channels in various
> jurisdictions

Sucks for the people living there.  They should change their laws.  If
they can't do that, they should change their LN node policies not to
route uneconomic HTLCs.  We shouldn't make Bitcoin worse to make
complying with regulations easier.

I also doubt your proposed solution fixes the problem.  Any LN node that
accepts an uneconomic HTLC cannot recover that value, so the money is
lost either way.  Any sane regulation would treat losing value to
transaction fees the same as losing value to uneconomical conditions.

Finally, if LN nodes start polluting the UTXO set with no economic way
to clean up their mess, I think that's going to cause tension between
full node operators and LN node operators.

> agnostic treatment of fund transfers would simplify this
> (like getting a 0.01 cent dividend check in the mail)

I'm not sure I understand this point.  It sounds to me like you're
comparing receiving an uneconomic output to receiving a check that isn't
worth the time to cash.  But the costs of checks are borne only by the
people who send, receive, and process them.  The costs of uneconomic
outputs polluting the UTXO set are borne by every full node forever (or
for every archival full node forever if non-archival nodes end up using
something like utreexo).

> 4) thinly divisible colored coin protocols might make use of sats as value
> markers for transactions.

I'm not exactly sure what you're talking about, but if Alice wants to
communicate the number n onchain, she can do:

    if n < dust:
      nSequence =3D 0x0000 + n  # should probably check endianess
    else:
      nValue =3D n

There's at least 15 bits of nSequence currently without consensus or
policy meaning, and the dust limits are currently in the hundreds of
sat, so there's plenty of space.

Alice could probably also communicate the same thing by grinding her
output script's hash or pubkey; again, with dust limits just being
hundreds of sats, that's not too much grinding.

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

I haven't looked since they upgraded to bulletproofs, but ISTR the
original CT implementation leaked the most significant digits or
something (that kept down the byte size of the proofs), so maybe it was
already possible to know what was certainly not dust and what might be
dust.

In short, it's my opinion that the dust limit is not creating any real
problems, so it should be kept for its contribution to keeping full
nodes faster, cheaper, and more efficient.

-Dave

P.S. As I prepared to send this, Matt's email arrived about "If it
weren't for the implications in changing standardness here, I think we
should consider increasing the dust limit instead."  I'm in agreement
with both parts of that statement.

--doahxmd3go2jqdi4
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmEQUcUACgkQ2dtBqWwi
adOsARAAoY4ABZ2RxmcOUFKyirinPpnYxOyMYUj6RC7zhOD4fkX14bgVJzAKbmij
1bXBr8IyF8qejN9ufhP48L/EAPEZufaBY5Xw1eJ8Nct/VK+Uq+TOmjURdfg+TcDQ
AWXe+Dn1YHs4DEAzsLnZCc7UVUhxRdp4haTvLM9TwenTFySF8ckQsQWr0fzLrMwb
5gamo/dROnn32ekQdsYTcLyIAJDfr/i8mO0K6yG0tO2leJbg7Z0iQkzBQPBs5AwI
heMUD4DlGF1k32RJif0YN1Mfu5Q3MlOP18D9DHOpaE1cKgEOhiOU3eFdHT5iEdJa
UgS/LNWru7TjErkA7jRMP37dan1WYGFxGKmboJVqUdPkTTwBCKUuOvJ1+nEFUCvh
/tLX34gPToWgFPSM1w39IDTtu6MrnUcbh9kGnnJh3BxgP5Nm0AqWIbYNKNmlV3eY
SWnCTwZEcDrPgNBzvTrFuOaBb+kNF8wH/ZRW0zuu6jmC7KSD98vshF+mKDcmoYyS
xN9Od5TxJZfJL30w1uER3jZgiV7BjClEDFZNU7S4zxxl8aYqW9E1nuBq8c/Fbn+t
LZso2HlZ4mK5MnF//FDsSTWhHnoAQ9WtZ9imUXFjOSsH+e0cwVTngTAiOowsfg8k
+2Y81fDWcQDrKm2Exm8Cu4fygHgo03VsAtDKOQzSEZ0Bi8AbM4M=
=hxSZ
-----END PGP SIGNATURE-----

--doahxmd3go2jqdi4--