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
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
Return-Path: <shymaa.arafat@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0A3ABC000D;
Fri, 8 Oct 2021 07:45:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id D20056089E;
Fri, 8 Oct 2021 07:45:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 nzukpQGsTq-i; Fri, 8 Oct 2021 07:45:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com
[IPv6:2607:f8b0:4864:20::430])
by smtp3.osuosl.org (Postfix) with ESMTPS id 1AE7B60890;
Fri, 8 Oct 2021 07:45:12 +0000 (UTC)
Received: by mail-pf1-x430.google.com with SMTP id m26so7501020pff.3;
Fri, 08 Oct 2021 00:45:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=FV0mFFASWOCI2QsGfi2pnrrGc/QqkLslqps8Hmvo/xo=;
b=DR8rnv+Kz9YhPn56Ve1uoodthJehBN1bpqjqHrTOoo0tHlBf0J/YhAMfFcEUEjKifU
eZz91QBERSzJter1DVUe+d2O5+lcQm/EHhQeEzXTd8R0s397xMeE7XduBKlT6aJ5DtxS
63BqTW78dgm+DS9Cc7DMMJEPmRXl+8ROnUYpqMRNRkuPHD4Sya8HG3a6Bts9E6yVefj5
Xlwh1ExBJOINSmhqXoGThEMYpZqM9puN3YCh8Df/qcOCOCqmOyPcIpVRC7RK5p9+/Qvn
L2c0AfpmvmUvCfifO80ETQ3/elmH5uP0NuZWcsJPHriEk6854ntETPt8jooYUbSbmOHl
ebBQ==
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;
bh=FV0mFFASWOCI2QsGfi2pnrrGc/QqkLslqps8Hmvo/xo=;
b=sJwgjT7VKmEqtv+HhUM3Bkbxv7f8LZknPy1UaAE1NDPvBXMwKPisOXV9ZU1JS47yid
prvIf13moKXKlie2Z3YK9VnfkZrIIoBWnno1sbdHiqPIOFDIwQesQyvJsLYdjHWwgn6/
Qno3HHUYkgHeLeFe7NHHaxO9D1ZkNBzNszgmwouhyJAKRaFXgffo0vcoRYcgtB5AUZ5Y
600DYp9dEV9Nl4HRBFS4yKaomAIwYmSYUD4jf2Hz5zcdgF15tTSH9oWjlV2y7WLRoFjn
9VHXxxfW3oycJWzKFvU81jO4ncFnZBiHEXnHDMPMgFdqbx242IHFgbtWsY35hawxa5P9
dtIQ==
X-Gm-Message-State: AOAM533XRQWe887itlbCfFzgCwvtLYN2uovnQdIEnOV9lPmzD9xBYvBf
HWf24O8XBlNG1V426p6ZcAzDT5rG3xsVbiZ8wuxtsDM6
X-Google-Smtp-Source: ABdhPJzcvMsK4THINwzAOOtxrBaW2ofaZVwh4+bXRtL1E9/8Dn5/wANznERKld436qRL3MRg35WbuulBp56ptJ6nhKE=
X-Received: by 2002:a62:8f53:0:b0:44c:5d10:9378 with SMTP id
n80-20020a628f53000000b0044c5d109378mr8561667pfd.19.1633679111205; Fri, 08
Oct 2021 00:45:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
<20210808215101.wuaidu5ww63ajx6h@ganymede>
<MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net>
<CAJowKgKt=yYdNOYYNsWh7FJ2EH7rz0bd2EjUjmyA=cA6k5cvUQ@mail.gmail.com>
<BtaljKLqpe75GB6pHEPQMF6_L-hBaE0ZCBGaXrUfnHRYeEbCqFWZ12DaMRm5jEADceL3uPfCiL-WU9MOZJ_m54Zi3Pzu0vSFN3nQvuSKvBM=@protonmail.com>
<CAM98U8nSOQ9HpdRLBdkcFAdToW=z7_EhnYisMb7F46ExmJkT-w@mail.gmail.com>
<ZKZ4RR6uAv0mG8yFQyRkWDTFQ7JnsGVfLQcMTmsc5ui7MTJXuzMkVk5YQTniPuc4F_KRhn7BEZZHEK60IZYZYU9A1r-tbmfPTnIs0pOd7oU=@protonmail.com>
<CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>
<MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
In-Reply-To: <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Fri, 8 Oct 2021 09:44:59 +0200
Message-ID: <CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com>
To: lightning-dev <lightning-dev@lists.linuxfoundation.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000019b70005cdd28f2e"
X-Mailman-Approved-At: Fri, 08 Oct 2021 07:55:07 +0000
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, 08 Oct 2021 07:45:13 -0000
--00000000000019b70005cdd28f2e
Content-Type: text/plain; charset="UTF-8"
The suggested idea I was replying to is to make all dust TXs invalid by
some nodes. I suggested a compromise by keeping them in secondary storage
for full nodes, and in a separate Merkle Tree for bridge servers.
-In bridge servers they won't increase any worstcase, on the contrary this
will enhance the performance even if slightly.
-In full nodes, and since they will usually appear in clusters, they will
be fetched rarely (either by a dust sweeping action, or a malicious
attacker)
In both cases as a batch
-To not exhaust the node with DoS(as the reply mentioned)one may think of
uploading the whole dust partition if they were called more than certain
threshold (say more than 1 Tx in a block)
-and then keep them there for "a while", but as a separate partition too to
exclude them from any caching mechanism after that block.
-The "while" could be a tuned parameter.
-Take care that the more dust is sweeped, the less dust to remain in the
UTXO set; as users are already much dis-incentivised to create more.
.
Thanks for allowing the reply
On Thu, Oct 7, 2021, 16:43 ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
>
> > I don't know what brings up sorting here, unless as an example.
>
> Yes, it is an example: quicksort is bad for network-facing applications
> because its ***worst-case behavior*** is bad.
> Bitcoin is a network-facing application, and similarly, ***worst-case
> behavior*** being bad is something that would strongly discourage
> particular approaches.
> Your proposal risks bad ***worst-case behavior***.
>
> > Anyways, I was comparing to rejecting them completely, not to keeping
> them in one set. In addition, those dust sweep Transactions will probably
> be a dust sweep and thus contain so many inputs which "maybe" makes 1-one
> disk visit to fetch all their hashes at once, 2-from a smaller subset with
> max size 5-10% the UTXO set, justifiable.
>
> Do not consider the ***average case*** where a block is composed of only a
> few dust sweep transactions and most transactions are normal,
> non-dust-sweep transactions.
>
> Instead, consider the ***worst case*** where ***all*** transactions in a
> block are dust sweep transactions, because that is what attackers will use.
>
> Regards,
> ZmnSCPxj
>
--00000000000019b70005cdd28f2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>The suggested idea I was replying to is to make all =
dust TXs invalid by some nodes. I suggested a compromise by keeping them in=
secondary storage for full nodes, and in a separate Merkle Tree for bridge=
servers.</div><div dir=3D"auto">-In bridge servers they won't increase=
any worstcase, on the contrary this will enhance the performance even if s=
lightly.</div><div dir=3D"auto">-In full nodes, and since they will usually=
appear in clusters, they will be fetched rarely (either by a dust sweeping=
action, or a malicious attacker)</div><div dir=3D"auto">In both cases as a=
batch</div><div dir=3D"auto">-To not exhaust the node with DoS(as the repl=
y mentioned)one may think of uploading the whole dust partition if they wer=
e called more than certain threshold (say more than 1 Tx in a block)=C2=A0=
=C2=A0</div><div dir=3D"auto">-and then keep them there for "a while&q=
uot;, but as a separate partition too to exclude them from any caching mech=
anism after that block.</div><div dir=3D"auto">-The "while" could=
be a tuned parameter.</div><div dir=3D"auto">-Take care that the more dust=
is sweeped, the less dust to remain in the UTXO set; as users are already =
much dis-incentivised to create more.</div><div dir=3D"auto">.</div><div di=
r=3D"auto">Thanks for allowing the reply</div><div dir=3D"auto"><br><div cl=
ass=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On T=
hu, Oct 7, 2021, 16:43 ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@protonmail.c=
om" target=3D"_blank" rel=3D"noreferrer">ZmnSCPxj@protonmail.com</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> I don't know what brings up sorting here, unless as an example.<br=
>
<br>
Yes, it is an example: quicksort is bad for network-facing applications bec=
ause its ***worst-case behavior*** is bad.<br>
Bitcoin is a network-facing application, and similarly, ***worst-case behav=
ior*** being bad is something that would strongly discourage particular app=
roaches.<br>
Your proposal risks bad ***worst-case behavior***.<br>
<br>
> Anyways, I was comparing to rejecting them completely, not to keeping =
them in one set. In addition, those dust sweep Transactions will probably b=
e a dust sweep and thus contain so many inputs which "maybe" make=
s 1-one disk visit=C2=A0 to fetch all their hashes at once, 2-from a smalle=
r subset with max size 5-10% the UTXO set, justifiable.<br>
<br>
Do not consider the ***average case*** where a block is composed of only a =
few dust sweep transactions and most transactions are normal, non-dust-swee=
p transactions.<br>
<br>
Instead, consider the ***worst case*** where ***all*** transactions in a bl=
ock are dust sweep transactions, because that is what attackers will use.<b=
r>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div></div>
--00000000000019b70005cdd28f2e--
|
