From: "David A. Harding" <dave@dtrt•org>
To: Antoine Riard <antoine.riard@gmail•com>
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: Mon, 9 Aug 2021 20:14:41 -1000 [thread overview]
Message-ID: <20210810061441.6rg3quotiycomcp6@ganymede> (raw)
In-Reply-To: <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2537 bytes --]
On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote:
> I'm pretty conservative about increasing the standard dust limit in any
> way. This would convert a higher percentage of LN channels capacity into
> dust, which is coming with a lowering of funds safety [0].
I think that reasoning is incomplete. There are two related things here:
- **Uneconomical outputs:** outputs that would cost more to spend than
the value they contain.
- **Dust limit:** an output amount below which Bitcoin Core (and other
nodes) will not relay the transaction containing that output.
Although raising the dust limit can have the effect you describe,
increases in the minimum necessary feerate to get a transaction
confirmed in an appropriate amount of time also "converts a higher
percentage of LN channel capacity into dust". As developers, we have no
control over prevailing feerates, so this is a problem LN needs to deal
with regardless of Bitcoin Core's dust limit.
(Related to your linked thread, that seems to be about the risk of
"burning funds" by paying them to a miner who may be a party to the
attack. There's plenty of other alternative ways to burn funds that can
change the risk profile.)
> the standard dust limit [...] introduces a trust vector
My point above is that any trust vector is introduced not by the dust
limit but by the economics of outputs being worth less than they cost to
spend.
> LN node operators might be willingly to compensate this "dust" trust vector
> by relying on side-trust model
They could also use trustless probabalistic payments, which have been
discussed in the context of LN for handling the problem of payments too
small to be represented onchain since early 2016:
https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_178
(Probabalistic payments were discussed in the general context of Bitcoin
well before LN was proposed, and Elements even includes an opcode for
creating them.)
> smarter engineering such as utreexo on the base-layer side
Utreexo doesn't solve this problem. Many nodes (such as miners) will
still want to store the full UTXO set and access it quickly, Utreexo
proofs will grow in size with UTXO set size (though, at best, only
log(n)), so full node operators will still not want their bandwidth
wasted by people who create UTXOs they have no reason to spend.
> I think the status quo is good enough for now
I agree.
-Dave
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-08-10 6:15 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 ` [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 [this message]
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=20210810061441.6rg3quotiycomcp6@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--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