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
|
Return-Path: <shymaa.arafat@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 75CD2C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Aug 2021 19:06:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 55AF560BC9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Aug 2021 19:06:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.125
X-Spam-Level:
X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, 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=no 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 e9F-a9Ea1pGG
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Aug 2021 19:06:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com
[IPv6:2607:f8b0:4864:20::436])
by smtp3.osuosl.org (Postfix) with ESMTPS id 2EE9960746
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Aug 2021 19:06:43 +0000 (UTC)
Received: by mail-pf1-x436.google.com with SMTP id k19so3150579pfc.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Aug 2021 12:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=JfBgb2+P+/5zGELhwAsIe0YF49GQpZDlC5N/2O/hBK0=;
b=SZHTKFqilFNCBWgLGI8i1fQzCYlZgRZs1m8W1esLz1eDiiXI6uVXnufDgZHHo2J7Ev
ioYaa2JBaHDLnSUX3noG0LuCCzrdU6e0+SDY0WvTs6u4ZBLj0SXIW/X5y3mEU470I9om
e7IZfOrxjHm2ln9mjiMi9IMhPb1jfC1S+fCEhtjkVNhEQNArAXVaR4TE8thAXusefYaN
W/HYcCfI7GqCrbx+26zu4uyQoYs7pD7BKfXIBj2686dFBYK9uoj30lsThtUa+bwmnZs2
/0aEAAtMOAbAAO/kggkSmTXrtGcf6ar7Ml6B5mX4fX9vMIIAw2y6a7JcWmBxHITedL1s
67Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=JfBgb2+P+/5zGELhwAsIe0YF49GQpZDlC5N/2O/hBK0=;
b=tsTVAmxszpl0sLV0lmycD8dLk/OuLq+QpSs7lZaauaROFWPqNJMeTP2/6FnsOtjsLe
BoZnS8AMeHHHnScwY+4+ydohcrCQAO5gyFkK7iF8Az7ba4zAmmVRAXjG3fbfHxREgS3a
eONbbcz3tre1xLIDw5CtklxvEkrJorDsfG072XM5O5pnT/Ux5rkek/AFqsYKnoctIWIt
zvE5sYqlmQFfd/JNxAY32geo6V/7PAkxEyF+X/78scN7mauFq2D5DnJNCiv2YyehJRzZ
e4vxmLtCfLyMu7nRRXKXoVap3zLQcA0LjQ54Zgw+MlTEso+J7Rgw/UFZU0YsF7fiV+8S
o8mg==
X-Gm-Message-State: AOAM530C+UW+ylnZYzYKeb1NnC5fwjV2r6Hzz32xqVEufo0NKTog6YNi
B4pDY0ARIp2elRTHEv3/axD06pYrBcMRUnnldzgPJ+Zj
X-Google-Smtp-Source: ABdhPJyqCPQA54+ISWuzyrWqgvqeCnPXa65VPUPrV9xpbZlzg9hLFCdgY5uV55nIVhm/i/0KmUOzk9O0BssGqrRgLLs=
X-Received: by 2002:a63:3501:: with SMTP id c1mr10152847pga.280.1629313602545;
Wed, 18 Aug 2021 12:06:42 -0700 (PDT)
MIME-Version: 1.0
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Wed, 18 Aug 2021 21:06:30 +0200
Message-ID: <CAM98U8m9=D115g-wHuVsVcSP6z7Q0EqNt0bbQKFo00ZZx0QR1g@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000081e9ad05c9da2247"
X-Mailman-Approved-At: Wed, 18 Aug 2021 20:52:43 +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: Wed, 18 Aug 2021 19:06:47 -0000
--00000000000081e9ad05c9da2247
Content-Type: text/plain; charset="UTF-8"
Dear Sir,
I'm not discussing the dust limit here, but I'm suggesting some mitigations
to the dust problem which tackles almost the same points mentioned here
especially the scalability of the UTXOS set and the corresponding Merkle
proofs/witnesses in Utreexo or any similar design ....
.
I suggest:
1-Dust UTXOS, along with burned & non-standard UTXOS, to be stored
separately in secondary storage; their Hashes in a separate Merkle too in
any accumulator design
(an earlier draft of the idea
https://bitcointalk.org/index.php?topic=5343748.new#new)
.
-In fact, the idea of separating the real UTXO values was first suggested in
https://royalsocietypublishing.org/doi/10.1098/rsos.180817
In their words
"Similarly, one can think of a two-tier data structure where a UTXO subset
containing UTXOs with a low probability of being selected such as dust is
kept on disk, while the other UTXOs are kept in memory."
.
2-I suggest also that existing dust UTXOS (from the same paper, in some
cases a UTXO could be added as an extra input with the cost of 68*fee/byte)
, to be selected with large UTXO whenever they fit in a spending ( use one
large & one small to get rid of the small)
.
3-In general when user is not willing to leave the dust to the fee, and if
there's no dust UTXOS, do not let the coin selection algorithm select the
closest match; let it choose the smallest that doesn't create dust.
For example if there's UTXOS 0.00013 & 0.00012 and user want to spend
0.0001198 choose 0.00013 so that the change is not dust (with same cost).
.
Thank you for your time,
This is the first time I send a suggestion to your emailing list, so sorry
if I missed any regulations
.
Shymaa M. Arafat
--00000000000081e9ad05c9da2247
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Dear Sir,<div dir=3D"auto"><br></div><div dir=3D"auto">I&=
#39;m not discussing the dust limit here, but I'm suggesting some mitig=
ations to the dust problem which tackles almost the same points mentioned h=
ere especially the scalability of the UTXOS set and the corresponding Merkl=
e proofs/witnesses in Utreexo or any similar design ....</div><div dir=3D"a=
uto">.</div><div dir=3D"auto">I suggest:</div><div dir=3D"auto">1-Dust UTXO=
S, along with burned & non-standard UTXOS, to be stored separately in s=
econdary storage; their Hashes in a separate Merkle too in any accumulator =
design</div><div dir=3D"auto">(an earlier draft of the idea</div><div dir=
=3D"auto"><a href=3D"https://bitcointalk.org/index.php?topic=3D5343748.new#=
new" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://bit=
cointalk.org/index.php?topic=3D5343748.new#new</a>)</div><div dir=3D"auto">=
.</div><div dir=3D"auto">-In fact, the idea of separating the real UTXO val=
ues was first suggested in</div><div dir=3D"auto"><a href=3D"https://royals=
ocietypublishing.org/doi/10.1098/rsos.180817" rel=3D"noreferrer noreferrer =
noreferrer" target=3D"_blank">https://royalsocietypublishing.org/doi/10.109=
8/rsos.180817</a></div><div dir=3D"auto">In their words</div><div dir=3D"au=
to">"Similarly, one can think of a two-tier data structure where a UTX=
O subset containing UTXOs with a low probability of being selected such as =
dust is kept on disk, while the other UTXOs are kept in memory."</div>=
<div dir=3D"auto">.</div><div dir=3D"auto">2-I suggest also that existing d=
ust UTXOS (from the same paper, in some cases a UTXO could be added as an e=
xtra input with the cost of 68*fee/byte) , to be selected with large UTXO w=
henever they fit in a spending ( use one large & one small to get rid o=
f the small)</div><div dir=3D"auto">.</div><div dir=3D"auto">3-In general w=
hen user is not willing to leave the dust to the fee, and if there's n=
o dust UTXOS, do not let the coin selection algorithm select the closest ma=
tch; let it choose the smallest that doesn't create dust.</div><div dir=
=3D"auto">For example if there's UTXOS 0.00013 & 0.00012 and user w=
ant to spend 0.0001198 choose 0.00013 so that the change is not dust (with =
same cost).</div><div dir=3D"auto">.</div><div dir=3D"auto">Thank you for y=
our time,</div><div dir=3D"auto">This is the first time I send a suggestion=
to your emailing list, so sorry if I missed any regulations</div><div dir=
=3D"auto">.</div><div dir=3D"auto">Shymaa M. Arafat</div><div dir=3D"auto">=
<br></div></div>
--00000000000081e9ad05c9da2247--
|
