summaryrefslogtreecommitdiff
path: root/c2/47c50658c1d9e2041a7dee71c838a281e9dafc
blob: 2622b3e03639a5e294969e8741a6f8d1823059ae (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
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
Return-Path: <melvincarvalho@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CFEB6C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 May 2023 16:37:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id AF89341DF4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 May 2023 16:37:25 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AF89341DF4
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=SoVCckGo
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
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 scusgjQ0kQSm
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 May 2023 16:37:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E1BDF41DAE
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [IPv6:2a00:1450:4864:20::131])
 by smtp4.osuosl.org (Postfix) with ESMTPS id E1BDF41DAE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 May 2023 16:37:23 +0000 (UTC)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-4f13ef4ad91so5477229e87.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 08 May 2023 09:37:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1683563842; x=1686155842;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=HNRRZsVujut1Y4fwcraNRjbR8M/90zIYBeyDOlvqv2w=;
 b=SoVCckGoLfIcmSPpLmLKJrlroj5ZvBwDVbR8ZHYb9k6wJ+AF36cHDtD6DB26qKigWQ
 Kw4zkdkYOyRYEU5y+l6z7CFk/oow1jNrvWfu0jmit/g8dC5vZYtcZVRvfEsfPjQBZQwz
 aLqXnMkEMjYDW65iiiar/m5GF91KtcWCtbqUJ9K92Da0oaRrGM6dcaV7uRq4kD1HXpqb
 9upYKrg1gtcSXYemCxzi/O1Sb64eQFtvN3UIFumgraL1/gzfLhhxnJpJwXmYTkITPrKV
 Grtd7xgohaj+7rvNk69ufxLRQEpuQnaMZOkXSDXE+l56R21k9tNEcZBqSoOxAtVV/vrb
 PRvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683563842; x=1686155842;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=HNRRZsVujut1Y4fwcraNRjbR8M/90zIYBeyDOlvqv2w=;
 b=hQCSwrlI7kkH1hHPAFbTfshJ0OJKHvGT0LKKqyNI81Lv4+iG9fYukalegxY8OqpGXP
 OeePY6ElA5zgsVbLotmV5JzW7Wbuqjy+zpw5e/5YJztl70MpyUVHzZlv3GlhZCN7HsZF
 pWIPz50NH4oazrCmpzHH3FpLm3RpWHUxcpCJt3iKytVnkw8BampQKK3Ss+FrPUvgA+qD
 4MqDaqYA7ZFbK5ByXOijXGFExtQxurAw3Jgti6w9UOwgFh8oqX9rVas/fJ3CYapXLgqF
 Cq9wAmSeJSKY3tP9sSFOmFRSzGYejdZfFkPsNAcyerbbFlJiN3zDsiOQ3J+10FWBt7qL
 XL2Q==
X-Gm-Message-State: AC+VfDyWpQqLgqEbEL4fGvCPipWm2xXHQZVz4V0kZ52JptnlqPssToNV
 5bMgxdgzSgHbKVJqr6ypuc5rnRaq1Ij9ZsJpSwt4fLW8Sp0=
X-Google-Smtp-Source: ACHHUZ4Yz0EctevjEdxAJydpCAtWb+EfDpw3dSMvHpwf/44KbkeGQKHyT7h08MKLVgD82UnMkoRdqfyNdMVX+hs1aF0=
X-Received: by 2002:ac2:519c:0:b0:4ef:ec94:9674 with SMTP id
 u28-20020ac2519c000000b004efec949674mr2553527lfi.32.1683563841246; Mon, 08
 May 2023 09:37:21 -0700 (PDT)
MIME-Version: 1.0
References: <Lm_5F74G9G21ydrFPovvmtHWpNXcbVzZibmU80oNqFRehJjcll89-t7OXqS5Fooe0cTNxGreIREMql3Li2xUCe2T5NVyss3-CrLzISO09HY=@notatether.com>
In-Reply-To: <Lm_5F74G9G21ydrFPovvmtHWpNXcbVzZibmU80oNqFRehJjcll89-t7OXqS5Fooe0cTNxGreIREMql3Li2xUCe2T5NVyss3-CrLzISO09HY=@notatether.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 8 May 2023 18:37:07 +0200
Message-ID: <CAKaEYh+Ya_W9zVXKbHr4eZWE=4tfCXvtZjvWRSmTjQTwyiKWRg@mail.gmail.com>
To: Ali Sherief <ali@notatether.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b6df6b05fb314053"
X-Mailman-Approved-At: Tue, 09 May 2023 13:33:24 +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: Mon, 08 May 2023 16:37:25 -0000

--000000000000b6df6b05fb314053
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

po 8. 5. 2023 v 13:55 odes=C3=ADlatel Ali Sherief via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> napsal:

> Hi guys,
>
> I think everyone on this list knows what has happened to the Bitcoin
> mempool 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 since 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
> its creator described them[1]) tokens threaten the smooth and normal use =
of
> the Bitcoin network as a peer-to-pear digital currency, as it was intende=
d
> to be used as.
>
> If the volume does not die down over the next few weeks, should we take a=
n
> action? The bitcoin network is a triumvirate of developers, miners, and
> users. Considering that miners are largely the entities at fault for
> allowing the system to be abused like this, the harmony of Bitcoin
> transactions is being disrupted right now. Although this community has a
> strong history of not putting its fingers into pies unless absolutely
> necessary - an example being during the block size wars and Segwit - shou=
ld
> similar action be taken now, in the form of i) BIPs and/or ii) commits in=
to
> the Bitcoin Core codebase, 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 an=
d
> introduce a run-time option to instantly prune all non-standard Taproot
> transactions. This will be easier to implement, but won't hit the road
> until minimum 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 allowed this to happen, which previously wasn't possible befor=
e.
> So we also have a responsibility to do something to ensure that this kind
> of congestion can never happen again using Taproot.
>

This is a nuanced and sensitive topic that has been discussed previously,
as far back as 2010, in a conversation between Gavin and Satoshi:

https://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617

Gavin: That's a cool feature until it gets popular and somebody decides it
would be fun to flood the payment network with millions of transactions to
transfer the latest Lady Gaga video to all their friends...
Satoshi: That's one of the reasons for transaction fees.  There are other
things we can do if necessary.

High fees could be viewed as disruptive to the network, but less disruptive
than regular large reorgs, or a network split.

It might be beneficial to brainstorm the "other things we can do if
necessary".

A simple observation is that increasing the block size could make it more
challenging to spam, though it may come at the expense of some
decentralization.


> -Ali
>
> ---
>
> [1]:
> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-=
promise-and-peril-of-bitcoin-backed-tokens/
> <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the=
-promise-and-peril-of-bitcoin-backed-tokens/?outputType=3Damp>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000b6df6b05fb314053
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">po 8. 5. 2023 v=C2=A013:55 odes=C3=AD=
latel Ali Sherief via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; napsal:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"fon=
t-family:Arial,sans-serif;font-size:14px">Hi guys,</div><div style=3D"font-=
family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family=
:Arial,sans-serif;font-size:14px">I think everyone on this list knows what =
has happened to the Bitcoin mempool during the past 96 hours. Due to side p=
rojects 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 th=
at has arguable not been seen since December 2017. I do not count the March=
 2021 congestion because that was only with 1-5sat/vbyte.</div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"fo=
nt-family:Arial,sans-serif;font-size:14px">Such justifiably worthless (&quo=
t;worthless&quot; is not even my word - that&#39;s how its creator describe=
d them[1]) tokens 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.</div=
><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div =
style=3D"font-family:Arial,sans-serif;font-size:14px">If the volume does no=
t die down over the next few weeks, should we take an action? The bitcoin n=
etwork is a triumvirate of developers, miners, and users. Considering that =
miners are largely the entities at fault for allowing the system to be abus=
ed like this, the harmony of Bitcoin transactions is being disrupted right =
now. Although this community has a strong history of not putting its finger=
s into pies unless absolutely necessary - an example being 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 codebase, to curtail the l=
oophole in BIP 342 (which defines the validation rules for Taproot scripts)=
 which has allowed these unintended consequences?</div><div style=3D"font-f=
amily:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:=
Arial,sans-serif;font-size:14px">An alternative would be to enforce this &q=
uot;censorship&quot; at the node level and introduce a run-time option to i=
nstantly prune all non-standard Taproot transactions. This will be easier t=
o implement, but won&#39;t hit the road until minimum next release.</div><d=
iv style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div sty=
le=3D"font-family:Arial,sans-serif;font-size:14px">I know that some people =
will have their criticisms about this, absolutists/libertarians/maximum-fre=
edom advocates, which is fine, but we need to find a solution for this that=
 fits everyone&#39;s common ground. We indirectly allowed this to happen, w=
hich previously wasn&#39;t possible before. So we also have a responsibilit=
y to do something to ensure that this kind of congestion can never happen a=
gain using Taproot.</div></blockquote><div><br></div></div><div class=3D"gm=
ail_quote">This is a nuanced and sensitive topic that has been discussed=20
previously, as far back as 2010, in a conversation between Gavin and=20
Satoshi: <br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote"><a href=3D"https://bitcointalk.org/index.php?topic=3D195.msg1617#ms=
g1617">https://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617</a></d=
iv><div class=3D"gmail_quote"><br>Gavin: That&#39;s a cool feature until it=
 gets popular and somebody decides it would be fun to flood the payment net=
work with millions of transactions to transfer the latest Lady Gaga video t=
o all their friends...<br>Satoshi: That&#39;s one of the reasons for transa=
ction fees.=C2=A0 There are other things we can do if necessary.<div><br></=
div><div class=3D"gmail_quote">High fees could be viewed as disruptive to t=
he network, but less disruptive than regular large reorgs, or a network spl=
it.<br></div><div class=3D"gmail_quote"><br></div></div><div class=3D"gmail=
_quote">It might be beneficial to brainstorm the &quot;other things we can =
do if necessary&quot;.</div><div class=3D"gmail_quote"><br></div><div>A sim=
ple observation is that increasing the block size could make it=20
more challenging to spam, though it may come at the expense of some=20
decentralization.</div><div><br> </div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial,sa=
ns-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-ser=
if;font-size:14px">-Ali</div><div style=3D"font-family:Arial,sans-serif;fon=
t-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size=
:14px">---</div><div style=3D"font-family:Arial,sans-serif;font-size:14px">=
<br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">[1]:=
=C2=A0<span><a rel=3D"noreferrer nofollow noopener" href=3D"https://www.coi=
ndesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril=
-of-bitcoin-backed-tokens/?outputType=3Damp" target=3D"_blank">https://www.=
coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-pe=
ril-of-bitcoin-backed-tokens/</a></span></div><div style=3D"font-family:Ari=
al,sans-serif;font-size:14px"><div>
    </div>
   =20
            <div>
       =20
            </div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000b6df6b05fb314053--