From: "David A. Harding" <dave@dtrt•org>
To: Jeremy <jlrubin@mit•edu>
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
Date: Sun, 8 Aug 2021 11:51:01 -1000 [thread overview]
Message-ID: <20210808215101.wuaidu5ww63ajx6h@ganymede> (raw)
In-Reply-To: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5284 bytes --]
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-that-would-typically-be-considered-dust-through-the-light)
> force channels to operate in a semi-trusted mode
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 = 0x0000 + n # should probably check endianess
else:
nValue = 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-08-08 21:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-08 18:52 [bitcoin-dev] " Jeremy
2021-08-08 21:14 ` Matt Corallo
2021-08-08 21:41 ` Oleg Andreev
2021-08-08 21:51 ` David A. Harding [this message]
2021-08-08 22:46 ` [bitcoin-dev] [Lightning-dev] " 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-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=20210808215101.wuaidu5ww63ajx6h@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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