1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Return-Path: <bitcoin-dev@wuille.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1C8CEC000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Sep 2021 22:07:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id F1E7B61461
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Sep 2021 22:07:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=wuille.net
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id QvHTkPzb16ji
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Sep 2021 22:07:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch
[185.70.41.104])
by smtp3.osuosl.org (Postfix) with ESMTPS id 768A9613FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Sep 2021 22:07:33 +0000 (UTC)
Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com
[51.77.79.158])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits))
(No client certificate requested)
by mail-41104.protonmail.ch (Postfix) with ESMTPS id 4HL6mg4Dlvz4x14M
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Sep 2021 22:07:31 +0000 (UTC)
Authentication-Results: mail-41104.protonmail.ch;
dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net
header.b="lOh1rT6u"
Date: Thu, 30 Sep 2021 22:07:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net;
s=protonmail; t=1633039629;
bh=hMhSxbuEAPx7XiOv8V2fNwspArKMAmOij5P+Yspq2XI=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=lOh1rT6uI2v1XyifQMO0xfDiKU01b2GfSvStQYA4U2xNCvy3yZlMkUOQYzCwJDaOT
+5MYQ69ANQdeE0JyuEl5i7ysBxBUW/R8uvocjGZ+Syi5M4WK5ZA3aCg+eyQciZu4hJ
K8Fmz8KuPtnlcp+tiUxHP3IRuDY3Ik2cQid3Oo8aJlxwSFC0BZi+2gF1Jfze/OC1Lr
1ggOs+KVhJ6f4PZYXdNg3NvyktUtrWkEkYX5z/d4YcMANSkkMTjc/LF2ckB9u8Nbnj
kT6Cvq0XPXm68s1EUqTRmHZJGvcdErO3MeBfAGKssdJIjDwRxX7/uzKhq2uR6iQIox
wsFx+t+DOfeBg==
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
X-Mailman-Approved-At: Fri, 01 Oct 2021 07:45:03 +0000
Cc: 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: Thu, 30 Sep 2021 22:07:36 -0000
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
|
