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
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
Return-Path: <oleganza@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 584D1C000E;
Sun, 8 Aug 2021 21:41:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 3B1BE82C1E;
Sun, 8 Aug 2021 21:41:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NU3012s8v8lt; Sun, 8 Aug 2021 21:41:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
[IPv6:2a00:1450:4864:20::131])
by smtp1.osuosl.org (Postfix) with ESMTPS id 4758C82B8C;
Sun, 8 Aug 2021 21:41:36 +0000 (UTC)
Received: by mail-lf1-x131.google.com with SMTP id g30so25523909lfv.4;
Sun, 08 Aug 2021 14:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=content-transfer-encoding:from:mime-version:subject:date:message-id
:references:cc:in-reply-to:to;
bh=mNK0307j768H64ykGqRAPi5daBIAEI97NetP5yxO8p4=;
b=WbZhD6PGOhCSJ0EnREuR0hWrcYWH7cwpcRTN0WUJrbxKjyHz2aSSjaCCABwZbetqPM
av2QOS6a44VaN99R0bNkS+ZjTGHO8QLP24Bycg2/IKf5vFY6aSk6jEkiY9KV3Yo1QU6o
BfRGywDoVnQT8pnC8JZDgaUhuIrqSaVhfW8FbGgD3t+YQcg7SoqTQLdDawrQutd4Im0W
pTlkzzpz7wo2lzHrfGYu2006VopOMKJYHGeib3yvkVoF+yinIfBGzK5++6C3Hh55S8sb
8Y5AwbdCAysmwGbygBgzNGJTUm48tpXw55vHAumWCME+0fnrEDO3nGbz+zxkqddMhj41
acNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:content-transfer-encoding:from:mime-version
:subject:date:message-id:references:cc:in-reply-to:to;
bh=mNK0307j768H64ykGqRAPi5daBIAEI97NetP5yxO8p4=;
b=rxjRtqJsQGMJWmHfUbafgUU9iOaxcRcMN2OIp3xvfJrfCYP+lXrdA4mPy5HrihepbL
Ess86+201/JCIuRROcCOgCcu+GXR4iRmS0I0PLI9ldjC1iAIrpS5ozxlNKr95qRK0Stq
bKJutpNIbF0kre5GNm9K1CE4qUvK3cZAuZiSjj63xuAzLeeRsH60QajJZajoWLN4p8AS
6lZaLkuiIPhjqxVb4raKLdjUu2e6GsD3sRFqzg4nUidWxHUs24CreXtfCfvmr97zfk5f
Ew2jStNYj571yNgEaWVomoPDnk4hq8FxVSeD5+1Rngz+bEPjyVtLtG+p3cJmUYWbIWJ3
jJWw==
X-Gm-Message-State: AOAM532EvNhY9TLINLuShVPdfc3qDJAvqMdx1KtGd7eeS+QAhPCFz2lJ
d0aAz19qjbr3ctTrB21bNJE=
X-Google-Smtp-Source: ABdhPJwGaRuPfwAaGuf7M0TqUL1IZAGBLaGL6+cTQQmwOxE4Fu7tMrCirZY7Bh+OO8tX/QV8eHjxQw==
X-Received: by 2002:ac2:446a:: with SMTP id y10mr14816100lfl.489.1628458894230;
Sun, 08 Aug 2021 14:41:34 -0700 (PDT)
Received: from smtpclient.apple ([94.25.229.253])
by smtp.gmail.com with ESMTPSA id c13sm1527118lfv.133.2021.08.08.14.41.33
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 08 Aug 2021 14:41:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Oleg Andreev <oleganza@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 9 Aug 2021 00:41:32 +0300
Message-Id: <29C08A0C-E9DA-4D9A-B27A-A5479D2B434E@gmail.com>
References: <e22dde6c-9a31-60ae-64d0-5e2ff84a6b79@mattcorallo.com>
In-Reply-To: <e22dde6c-9a31-60ae-64d0-5e2ff84a6b79@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (18G69)
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-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:41:40 -0000
I agree with Jeremy. Dust limit works due to design accident: that outputs a=
re not encrypted. But outputs are private business and the real issue is onl=
y the cost of utxo set storage born by every user. There are two ways to add=
ress this:
1) either make ppl pay for renting that storage (which creates a ton of prob=
lems of its own)
2) or make storage extremely cheap so it remains cheap at any scale. This is=
perfectly solved by Utreexo.
But looking at the private data because you can is a hack that creates issue=
s of its own.
> On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
>=20
> =EF=BB=BFIf it weren't for the implications in changing standardness here,=
I think we should consider increasing the dust limit instead.
>=20
> The size of the UTXO set is a fundamental scalability constraint of the sy=
stem. In fact, with proposals like assume-utxo/background history sync it is=
arguably *the* fundamental scalability constraint of the system. Today's du=
st limit is incredibly low - its based on a feerate of only 3 sat/vByte in o=
rder for claiming the UTXO to have *any* value, not just having enough value=
to be worth bothering. As feerates have gone up over time, and as we expect=
them to go up further, we should be considering drastically increasing the 3=
sat/vByte basis to something more like 20 sat/vB.
>=20
> Matt
>=20
>> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote:
>> We should remove the dust limit from Bitcoin. Five reasons:
>> 1) it's not our business what outputs people want to create
>=20
> It is precisely our business - the costs are born by us, not the creator. I=
f someone wants to create outputs which don't make sense to spend, they can d=
o so using OP_RETURN, since they won't spend it anyway.
>=20
>> 2) dust outputs can be used in various authentication/delegation smart co=
ntracts
>=20
> So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-the=
m outputs.
>=20
>> 3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/quest=
ions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-thro=
ugh-the-light <https://bitcoin.stackexchange.com/questions/46730/can-you-sen=
d-amounts-that-would-typically-be-considered-dust-through-the-light>) force c=
hannels to operate in a semi-trusted mode which has implications (AFAIU) for=
the regulatory classification of channels in various jurisdictions; agnosti=
c treatment of fund transfers would simplify this (like getting a 0.01 cent d=
ividend check in the mail)
>=20
> This is unrelated to the consensus dust limit. This is related to the prac=
tical question about the value of claiming an output. Again, the appropriate=
way to solve this instead of including spendable dust outputs would be an O=
P_RETURN output (though I believe this particular problem is actually better=
solved elsewhere in the lightning protocol).
>=20
>> 4) thinly divisible colored coin protocols might make use of sats as valu=
e markers for transactions.
>=20
> These schemes can and should use values which make them economical to spen=
d. The whole *point* of the dust limit is to encourage people to use values w=
hich make sense economically to "clean up" after they're done with them. If p=
eople want to use outputs which they will not spend/"clean up" later, they s=
hould be using OP_RETURN.
>=20
>> 5) should we ever do confidential transactions we can't prevent it withou=
t compromising privacy / allowed transfers
>=20
> This is the reason the dust limit is not a *consensus* limit. If and when C=
T were to happen we can and would relax the standardness rules around the du=
st limit to allow for CT.
>=20
>> The main reasons I'm aware of not allow dust creation is that:
>> 1) dust is spam
>> 2) dust fingerprinting attacks
>=20
> 3) The significant costs to every miner and full node operator.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
