summaryrefslogtreecommitdiff
path: root/fb/1d87706b30237c2e2f2ed469fae416681d327c
blob: c9f066b56d3c962e2a44b5d0b23b0daea7d9aa5b (plain)
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
199
200
201
202
203
Return-Path: <jk_14@op.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1DCA7C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 May 2023 08:51:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id E013F83BB2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 May 2023 08:51:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E013F83BB2
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
 header.s=2011 header.b=ZHG9+mS7
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pCEpi2WUCu_f
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 May 2023 08:51:17 +0000 (UTC)
X-Greylist: delayed 00:09:54 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E1DB183B9B
Received: from smtpa40.poczta.onet.pl (smtpa40.poczta.onet.pl [213.180.142.40])
 by smtp1.osuosl.org (Postfix) with ESMTPS id E1DB183B9B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 May 2023 08:51:16 +0000 (UTC)
Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4QFs7t2PlXzlgPxm;
 Tue,  9 May 2023 10:41:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
 t=1683621674; bh=dFo5IZU8bnfLoFMTT18QhS1ft+rEhK9IM6CoHBj++P0=;
 h=From:To:Date:Subject:From;
 b=ZHG9+mS7vE9fLu0VOv3LzrVVyw2+4yUf2Xk8OdCGecsvv9XhX3VgJmkgiO0+Ch1PP
 l1cyzL3Jk8vCLWYh5WrS/J/9BAt9hMXCLTYV9AKa9bsqebg5LU1kWFDo2b0A1Kv/jG
 9YrGnZhMSi+By/DQTOCeKtQTsEF4a2Kt3kzQtEhA=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [89.64.64.233] by pmq7v.m5r2.onet via HTTP id ;
 Tue, 09 May 2023 10:41:14 +0200
From: jk_14@op.pl
X-Priority: 3
To: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 09 May 2023 10:41:13 +0200
Message-Id: <183080646-e0c2bb9eaf62640f6c5d6c34f66db1d9@pmq7v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <jk_144@onet.pl>;89.64.64.233;PL;3
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Tue, 09 May 2023 12:23:30 +0000
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject
 non-standard Taproot transactions from full nodes?
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: Tue, 09 May 2023 08:51:19 -0000



Ok, I need to highlight one important thing well proven by this discussion =
(like it or not)...

Not the spam itself is the real reason of feeling: "something must be done"
The reason is: $30 fee per transaction (I hope you all agree)


Let me paraphrase some quotes used in this discussion, then:

1. Lack of block subsidy long term and necessity of $40 tx fee to compensat=
e it - "threaten the smooth and normal use of the Bitcoin network as a peer=
-to-pear digital currency, as it was intended to be used as."

2. "the harmony of Bitcoin transactions is being disrupted right now" due t=
o lack of block subsidy and due to exorbitant $40 tx fees as an effect nece=
ssary to keep the network security untouched

3. "Fee spikes aren't fun" and it's obvious that keeping the network securi=
ty only on enormous tx fees of active users and having passive users as fre=
e-riders - isn't fun, too

4. by ignoring Bitcoin long-term security budget problem - "we indirectly a=
llowed this to happen, which previously wasn't possible before. So we also =
have a responsibility to do something to ensure that this kind of tremendou=
s $40 tx fees can never happen again"

5. "Action against exorbitant fees should have been taken months ago. (...)=
 It's a mistake that the" tail emission or other necessary solution - weren=
't implemented on time

6. "we need to find a solution for long-term horrible fees problem - that f=
its everyone's common ground."


Yes, we need - instead of being still in a heavy denial state.

No additional comment then, except this little one:
Delay of halving in case of 4 years long network difficulty regression situ=
ation.


Regards,
Jaroslaw





W dniu 2023-05-09 00:37:57 u=C5=BCytkownik Luke Dashjr via bitcoin-dev <bit=
coin-dev@lists.linuxfoundation.org> napisa=C5=82:

Action should have been taken months ago. Spam filtration has been a standa=
rd part of Bitcoin Core since day 1. It's a mistake that the existing filte=
rs weren't extended to Taproot transactions. We can address that, or try a =
more narrow approach like OP_RETURN (ie, what "Ordisrespector" does). Since=
 this is a bugfix, it doesn't really even need to wait for a major release.

(We already have pruning. It's not an alternative to spam filtering.)

Luke




On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:
Hi guys,


I think everyone on this list knows what has happened to the Bitcoin mempoo=
l during the past 96 hours. Due to side projects such as BRC-20 having such=
 a high volume, real bitcoin transactions are being priced out and that is =
what is causing the massive congestion that has arguable not been seen sinc=
e December 2017. I do not count the March 2021 congestion because that was =
only with 1-5sat/vbyte.


Such justifiably worthless ("worthless" is not even my word - that's how it=
s creator described them[1]) tokens threaten the smooth and normal use of t=
he Bitcoin network as a peer-to-pear digital currency, as it was intended t=
o be used as.


If the volume does not die down over the next few weeks, should we take an =
action? The bitcoin network is a triumvirate of developers, miners, and use=
rs. Considering that miners are largely the entities at fault for allowing =
the system to be abused like this, the harmony of Bitcoin transactions is b=
eing disrupted right now. Although this community has a strong history of n=
ot putting its fingers into pies unless absolutely necessary - an example b=
eing during the block size wars and Segwit - should similar action be taken=
 now, in the form of i) BIPs and/or ii) commits into the Bitcoin Core codeb=
ase, to curtail the loophole in BIP 342 (which defines the validation rules=
 for Taproot scripts) which has allowed these unintended consequences?


An alternative would be to enforce this "censorship" at the node level and =
introduce a run-time option to instantly prune all non-standard Taproot tra=
nsactions. This will be easier to implement, but won't hit the road until m=
inimum next release.


I know that some people will have their criticisms about this, absolutists/=
libertarians/maximum-freedom advocates, which is fine, but we need to find =
a solution for this that fits everyone's common ground. We indirectly allow=
ed this to happen, which previously wasn't possible before. So we also have=
 a responsibility to do something to ensure that this kind of congestion ca=
n never happen again using Taproot.


-Ali


---


[1]:=C2=A0https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-b=
rcs-the-promise-and-peril-of-bitcoin-backed-tokens/






_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev