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
|
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 8B353C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Oct 2021 09:13:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 7A7446061F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Oct 2021 09:13:56 +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 SAcCqkCcpzHM
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Oct 2021 09:13:55 +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 4D644607AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Oct 2021 09:13:55 +0000 (UTC)
Received: by mail-pf1-x436.google.com with SMTP id k26so4813003pfi.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Oct 2021 02:13:55 -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=NTIxRUiAsnIzH62ZDKO8K3lKx7k4NDHKh07mJSF9vK0=;
b=Vjxpu7ML76FrqGn0tD7Hbkx0cz5gbq0SiROy5eUyltKuXK1Pf3rEFGppGg2joLF3+X
C+DSOYlO2XCFkRx/QXIvkAHwjr9ojsZ+rcNFnlU2TK3gQJeMs7oZtlztOYRfvjCaJgo7
f8JlEjOUUtcN0KjyMGZt0iRpqi9Kw8OnqIBp3GbFKV8Nq/oac2x+nEKcR9eX83+CqFTi
K/HUXMS+AVqj0eWxdt41UxtsrZc8CQzk2tJtgGqySjA6DbwBQ+3ezoFqYPK1x8533bxm
Ezib9/l/58xh4bJSrJmvEgQy0ibHwxWrZ9LI4Y4+Y1kcwCBHkAAofvFplOedOO1WqJlP
ZVvg==
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=NTIxRUiAsnIzH62ZDKO8K3lKx7k4NDHKh07mJSF9vK0=;
b=dBJxlR+Z8D68N9C4Jg2KIAXxVHBwJrZbR+bcKy9MkOa0R3wWTQQqkVGgutHRuDjaYF
qxCsrlZ5pL6qNsxC4ACmXnIdOF2oOMHRn/lYSw8wD9DkeMu3T+1Zqr2TH6JY3Z6EcVBJ
u1R1oj7fnJGjePhuQRb3+tvFEotsm6vMnt8AYrXEQvVBIOapAx/1Lmot0icWU/qehMka
EMwCii86A6plNuF7Tsc9tgv/ENVD4GIomBWYzaBUmBRgfrTfckwaS3b5TIhVdIax5C62
qWYCnjKVSJ9iM1rYvZ/eU86YFu+OMXt8dP5nX4/EdXtVJIGzoq4NAypvwrXQgolJZN+b
BeRw==
X-Gm-Message-State: AOAM531dD8MLJ7YCb0xb78xGPCAbdnlq+tNugHrWcz44l77l3BYLwcvX
rgzdLgImoUzNJFF4sRnQ7oDUKRyApJNPq1vTspg=
X-Google-Smtp-Source: ABdhPJybktZ3bIY/XYqbOvcIve/6PvXYCASxcOTtbQSh/SGbjrh8IuS2a63hQuYcMwk+7X1zeXFcLgBbItTwd5rSOCM=
X-Received: by 2002:a62:8f53:0:b0:44c:5d10:9378 with SMTP id
n80-20020a628f53000000b0044c5d109378mr2936463pfd.19.1633598034706; Thu, 07
Oct 2021 02:13:54 -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>
In-Reply-To: <BtaljKLqpe75GB6pHEPQMF6_L-hBaE0ZCBGaXrUfnHRYeEbCqFWZ12DaMRm5jEADceL3uPfCiL-WU9MOZJ_m54Zi3Pzu0vSFN3nQvuSKvBM=@protonmail.com>
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Thu, 7 Oct 2021 11:13:33 +0200
Message-ID: <CAM98U8nSOQ9HpdRLBdkcFAdToW=z7_EhnYisMb7F46ExmJkT-w@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000090855105cdbfae65"
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: Thu, 07 Oct 2021 09:13:56 -0000
--00000000000090855105cdbfae65
Content-Type: text/plain; charset="UTF-8"
If u allow me to discuss,,,
I previously suggested storing dust UTXOS in a separate Merkle tree or
strucutre in general if we are talking about the original set.
I'm a kind of person who doesn't like to throw any thing; if it's not
needed now keep it in the basement for example.
So, if dust UTXOS making a burden keep them in secondary storage, where in
such cases u can verify then delete them.
On Thu, Oct 7, 2021, 06:52 ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning e,
>
> > 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
>
> How would such a node treat a transaction that spends multiple dust UTXOs
> and creates a single non-dust UTXO out of them (after fees)?
> Is it valid (to such a node) or not?
>
> I presume from #1 it never stores dust UTXOs, so the node cannot know if
> the UTXO being spent by such a tx is spending dust, or trying to spend an
> already-spent TXO, or even inventing a TXO out of `/dev/random`.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000090855105cdbfae65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">If u allow me to discuss,,,<div dir=3D"auto">I previously=
suggested storing dust UTXOS in a separate Merkle tree or strucutre in gen=
eral if we are talking about the original set.<div dir=3D"auto">I'm a k=
ind of person who doesn't like to throw any thing; if it's not need=
ed now keep it in the basement for example.=C2=A0</div><div dir=3D"auto">So=
, if dust UTXOS making a burden keep them in secondary storage, where in su=
ch cases u can verify then delete them.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto"><br></div></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 7, 2021, 06:52 ZmnSCPxj via bit=
coin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Good morning e,<br>
<br>
> mostly thinking out loud<br>
><br>
> suppose there is a "lightweight" node:<br>
><br>
> 1.=C2=A0 ignores utxo's below the dust limit<br>
> 2.=C2=A0 doesn't validate dust tx<br>
> 3.=C2=A0 still validates POW, other tx, etc.<br>
><br>
>=C2=A0 =C2=A0 =C2=A0these nodes could possibly get forked - accepting a=
series of valid,<br>
>=C2=A0 =C2=A0 =C2=A0mined blocks where there is an invalid but ignored =
dust tx, however<br>
>=C2=A0 =C2=A0 =C2=A0this attack seems every bit as expensive as a 51% a=
ttack<br>
<br>
How would such a node treat a transaction that spends multiple dust UTXOs a=
nd creates a single non-dust UTXO out of them (after fees)?<br>
Is it valid (to such a node) or not?<br>
<br>
I presume from #1 it never stores dust UTXOs, so the node cannot know if th=
e UTXO being spent by such a tx is spending dust, or trying to spend an alr=
eady-spent TXO, or even inventing a TXO out of `/dev/random`.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000090855105cdbfae65--
|
