From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Date: Thu, 30 Sep 2021 22:07:08 +0000 [thread overview]
Message-ID: <MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net> (raw)
In-Reply-To: <20210808215101.wuaidu5ww63ajx6h@ganymede>
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@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
next prev parent reply other threads:[~2021-09-30 22:07 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 [this message]
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='MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--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