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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 55F80C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Oct 2021 10:39:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 427B340382
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Oct 2021 10:39:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 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,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vizlvBK6-pgE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Oct 2021 10:39:01 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18])
by smtp4.osuosl.org (Postfix) with ESMTPS id 4FC7D40370
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Oct 2021 10:39:01 +0000 (UTC)
Date: Fri, 08 Oct 2021 10:38:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1633689538;
bh=wbu8kRxw7cd1opnOJMMAEos7GrIbZSIcNq30zRo45VI=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=Y3ulqudFl8m5sYwLgefMYzLlk/YbXaesPmK+7NqaM364fgEmOv9GblzQnteyju4VO
9Hab0FYe6SXapFqjHpn+7e0307AqduIeITIX0IknCBN4iq4W5wVewoy8c2u0hQOVwf
JMlGp4SF3TthBB77jsTKyisNO68XA5q9q2N2RKdc=
To: shymaa arafat <shymaa.arafat@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <R7rqMyBitqJYz8vM37xnRj3OAvTfA4PDZJg3QzTVLNx3nLMeKRUxKNHu49ezhO80N7XeUweFOBeduAeoIUFvEFhjSTfwDltRH4kEdeQ9koE=@protonmail.com>
In-Reply-To: <CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com>
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>
<CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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, 08 Oct 2021 10:39:04 -0000
Good morning shymaa,
> The suggested idea I was replying to is to make all dust TXs invalid by s=
ome nodes.
Is this supposed to be consensus change or not?
Why "some" nodes and not all?
I think the important bit is for full nodes.
Non-full-nodes already work at reduced security; what is important is the s=
ecurity-efficiency tradeoff.
> I suggested a compromise by keeping them in secondary storage for full no=
des, and in a separate Merkle Tree for bridge servers.
> -In bridge servers they won't increase any worstcase, on the contrary thi=
s 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 attack=
er)
> 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 t=
hreshold (say more than 1 Tx in a block)=C2=A0=C2=A0
> -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.
Assuming you meant "dust tx is considered invalid by all nodes".
* Block has no dust sweep
* With dust rejected: only non-dust outputs are accessed.
* With dust in secondary storage: only non-dust outputs are accessed.
* Block has some dust sweeps
* With dust rejected: only non-dust outputs are accessed, block is reject=
ed.
* With dust in secondary storage: some data is loaded from secondary stor=
age.
* Block is composed of only dust sweeps
* With dust rejected: only non-dust outputs are accessed, block is reject=
ed.
* With dust in secondary storage: significant increase in processing to l=
oad large secondary storage in memory,
So I fail to see how the proposal ever reduces processing compared to the i=
dea of just outright making all dust txs invalid and rejecting the block.
Perhaps you are trying to explain some other mechanism than what I understo=
od?
It is helpful to think in terms always of worst-case behavior when consider=
ing resistance against attacks.
> -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.
But creation of dust is also as easy as sweeping them, and nothing really p=
revents a block from *both* creating *and* sweeping dust, e.g. a block comp=
osed of 1-input-1-output transactions, unless you want to describe some kin=
d of restriction here?
Such a degenerate block would hit your secondary storage double: one to rea=
d, and one to overwrite and add new entries; if the storage is large then t=
he index structure you use also is large and updates can be expensive there=
as well.
Again, I am looking solely at fullnode efficiency here, meaning all rules v=
alidated and all transactions validated, not validating and simply acceptin=
g some transactions as valid is a degradation of security from full validat=
ion to SPV validation.
Now of course in practice modern Bitcoin is hard to attack with *only* mini=
ng hashpower as there are so many fullnodes that an SPV node would be easil=
y able to find the "True" history of the chain.
However, as I understand it that proporty of fullnodes protecting against a=
ttacks on SPV nodes only exists due to fullnodes being cheap to keep online=
; if the cost of fullnodes in the **worst case** (***not*** average, please=
stop talking about average case) increases then it may become feasible for=
miners to attack SPV nodes.
Regards,
ZmnSCPxj
|
