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
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id B5DA7C000D;
Fri, 1 Oct 2021 13:40:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id A0F6B4023B;
Fri, 1 Oct 2021 13:40:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id l-GiURVgTZhr; Fri, 1 Oct 2021 13:40:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com
[IPv6:2607:f8b0:4864:20::102d])
by smtp2.osuosl.org (Postfix) with ESMTPS id 60FC2400D0;
Fri, 1 Oct 2021 13:40:19 +0000 (UTC)
Received: by mail-pj1-x102d.google.com with SMTP id
oj15-20020a17090b4d8f00b0019f8860d6e2so290263pjb.5;
Fri, 01 Oct 2021 06:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=7JiZ1Ht8KdWvwN40N8LBSywCONVo6XuxA+02RHRvB0w=;
b=lGrGR5BUKJNRmiHF93B8lZnkssdlNtCQXNjUyTbvy5rxSCV8ob/dHw/dSF9ZJUh5vI
DaGYN7U//dQaCp9RS7q1W3U+XL6xJ7VhwNjZxmLlCcAT4hz5j++XdDdrzPA0ZINsNm1g
kMBN7F4nBtWK7D7FCTlSLfDlLIMyz2a3sA3/FXNbyTYK0A7VZDsbzRbaVFlMH2nwxpZZ
KiPWKwk9e1HDaPcv7vlyAXDlV1ahZg8g1kwN16FmyoP1leBvXdBKXp1Vv6IJ/kpUs1Ey
yC9Bh4Nn3EBzYc/1jTAvtNiF2g74YJ2vb9A7zbb6vPC80y8/QZpiLDc9PEnbtjq828f3
Qvwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=7JiZ1Ht8KdWvwN40N8LBSywCONVo6XuxA+02RHRvB0w=;
b=07vSW+ugVisZ/6ncaWWfnVW6240ptm7pnttiTmYMPpf4kNkKUQ/jyu7QEO23zrkGEM
U0prBhLS6pbP9UDZVtSdjASM0AWvhkOiNJ4JU3KHMM+cOt1GDgs+9ngDPFavH0G8A9tS
Wbv3T+u6jpGCgH5xKx1DoQsQ1jfATo+QLkXnBw5VBChOloqhHihmDGul5Sz2UpVC6xxw
c8C8AIwmIkCxMmVmzC8+CAA6mtwng5a03WjY/pIv6lJRUgSqgIw62Vr98o8pRWOyJPtb
nBC/uDOGUlnpUENHnHT0hhAMH//h/lvAHPB8DDjhsmUIrz/O5Gr+FT0uvXrhVQ7RfjpI
8ghA==
X-Gm-Message-State: AOAM533oBtj4LMOxh9Iy/EtlvMIWyS+4NK0TZBfbskHEZ796C8+nCmjj
63lchCwq4XvUVoAvPpZkJLxVEZff6k5VMSf6NZ1nycXZY5Xdqow=
X-Google-Smtp-Source: ABdhPJzx3RoKoVJmuPB2vnVclTLjZ0UJRfDOLnF692WhZ3IBW8ZczGsT3Ep7fEwUWO+z5pKEvcjYG2jPdHQYbPNVXz0=
X-Received: by 2002:a17:90a:8b8d:: with SMTP id z13mr490273pjn.0.1633095618467;
Fri, 01 Oct 2021 06:40:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
<20210808215101.wuaidu5ww63ajx6h@ganymede>
<MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net>
In-Reply-To: <MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 1 Oct 2021 09:40:06 -0400
Message-ID: <CAJowKgKt=yYdNOYYNsWh7FJ2EH7rz0bd2EjUjmyA=cA6k5cvUQ@mail.gmail.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 01 Oct 2021 13:45:28 +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: Fri, 01 Oct 2021 13:40:20 -0000
mostly thinking out loud
suppose there is a "lightweight" node:
1. ignores utxo's below the dust limit
2. doesn't validate dust tx
3. still validates POW, other tx, etc.
these nodes could possibly get forked - accepting a series of valid,
mined blocks where there is an invalid but ignored dust tx, however
this attack seems every bit as expensive as a 51% attack
On Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Jumping in late to this thread.
>
> I very much agree with how David Harding presents things, with a few comm=
ents inline.
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =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 =
<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 con=
sensus rules fail to account
> for. Having a relay policy that avoids at the very least economically irr=
ational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules could deal with this, as you do=
n'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 sma=
rt
> > > contracts
> >
> > > 3. dust sized htlcs in lightning (
> > > https://bitcoin.stackexchange.com/questions/46730/can-you-send-am=
ounts-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 pro=
tocols have no business being on the Bitcoin chain, possibly
> beyond committing to an occasional batched state update or so. Both becau=
se 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 w=
ithout
> > > 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 nonzer=
o, which could be required as part of a relay policy.
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
