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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2E006C000E;
Sun, 8 Aug 2021 21:16:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with UTF8SMTP id 1043E82BBC;
Sun, 8 Aug 2021 21:16:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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=mattcorallo.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with UTF8SMTP id 7bCwOuU12eK4; Sun, 8 Aug 2021 21:16:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp1.osuosl.org (Postfix) with UTF8SMTPS id 0336E8266C;
Sun, 8 Aug 2021 21:16:14 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 0D66165D76C;
Sun, 8 Aug 2021 21:14:25 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1628455264; t=1628457266;
bh=dxX34mZbaogMY4esT7fYDyogHvbQRKv3GirEKtAdB2E=;
h=Date:Subject:To:References:From:In-Reply-To:From;
b=dt1dqD2ge4nS5N1B5RDIZ3rFrlVxwvRd/CLya9jofi35NQVjly26ErlSAjJY5A+s6
0QojcHVg2HhrzyBfvshQAi1va/M/fXhA3Mp5hFg5oqwnMZ+lb5QvvIxp0wX1L0jaTm
31i6RuCW3bSGojb990V+qNPE+meBLQLEv+RX/meRJuy06EGuuSg/Be7SVv9oYQGJIY
7OTsFAdH9rJezNW1lHY1C+FJKuQ1La+R3LFteTHKhp6RcUflIRmE++c86kz1j38yhP
Ay0K0B1wXtw0kGQEAqHxu9NwpIFBi7YgEUEHbRnI6Ps+rQCwW1FXDPkHeUx2RLTQ2k
Jb+y73MuqPbqA==
Message-ID: <e22dde6c-9a31-60ae-64d0-5e2ff84a6b79@mattcorallo.com>
Date: Sun, 8 Aug 2021 17:14:23 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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:16:16 -0000
If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit
instead.
The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like
assume-utxo/background history sync it is arguably *the* fundamental scalability constraint of the system. Today's dust
limit is incredibly low - its based on a feerate of only 3 sat/vByte in order 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.
Matt
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
It is precisely our business - the costs are born by us, not the creator. If someone wants to create outputs which don't
make sense to spend, they can do so using OP_RETURN, since they won't spend it anyway.
> 2) dust outputs can be used in various authentication/delegation smart contracts
So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them outputs.
> 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
> <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 which has implications (AFAIU) for the regulatory classification of
> channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent
> dividend check in the mail)
This is unrelated to the consensus dust limit. This is related to the practical question about the value of claiming an
output. Again, the appropriate way to solve this instead of including spendable dust outputs would be an OP_RETURN
output (though I believe this particular problem is actually better solved elsewhere in the lightning protocol).
> 4) thinly divisible colored coin protocols might make use of sats as value markers for transactions.
These schemes can and should use values which make them economical to spend. The whole *point* of the dust limit is to
encourage people to use values which make sense economically to "clean up" after they're done with them. If people want
to use outputs which they will not spend/"clean up" later, they should be using OP_RETURN.
> 5) should we ever do confidential transactions we can't prevent it without compromising privacy / allowed transfers
This is the reason the dust limit is not a *consensus* limit. If and when CT were to happen we can and would relax the
standardness rules around the dust limit to allow for CT.
>
> The main reasons I'm aware of not allow dust creation is that:
>
> 1) dust is spam
> 2) dust fingerprinting attacks
3) The significant costs to every miner and full node operator.
|
