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
|
Return-Path: <leohaf@orangepill.ovh>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id B0FB6C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 09:47:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 6847740489
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 09:47:07 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6847740489
Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=orangepill.ovh header.i=@orangepill.ovh
header.a=rsa-sha256 header.s=sig1 header.b=cztL9xyE
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_LOW=-0.7,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xSFnSsXQ8veZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 09:47:06 +0000 (UTC)
Received: from st43p00im-ztfb10073301.me.com (st43p00im-ztfb10073301.me.com
[17.58.63.186])
by smtp2.osuosl.org (Postfix) with ESMTPS id 262CB4012D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 09:47:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 262CB4012D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orangepill.ovh;
s=sig1; t=1690364825;
bh=doyaXfuV4U3jbmnDAugru18PQeFwKBGm3OtoY+xT4GA=;
h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To;
b=cztL9xyEOCrkLPGYGfLZCj81+J1d4CQ7Ry4UjQpPVfIMFSRpwIbB7wX+UI2HnjoJW
k5RZD9BoaJmPVszMcJqj08qu2xhTJU3+TZOT8fvRgR4lVDG82wxEyjxR5X1lrVnH/m
FpWQZ1cG2uMY7VZxZyrS3+wvTZIm6nnNGYtX2BuUzXJZsW09zkr2jRuAPwaO0/9yi/
nklSjIGOWS+uzOzEVhxX7ozoIcv7oijIDlTNj6bXzzydlczDVZt8ZLj/l9AkysOmdy
My2n/M2aYCmZnAjGEB9qqBT1Dt1Prz/rCaJNh7bQ2rpHi5v3HlwOsjnb2lC2lf0T9+
qexgWkfVWJFNg==
Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com
[17.42.251.41])
by st43p00im-ztfb10073301.me.com (Postfix) with ESMTPSA id 6DE9080036E;
Wed, 26 Jul 2023 09:47:04 +0000 (UTC)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: leohaf@orangepill.ovh
X-Priority: 3
In-Reply-To: <95672223-c6bb7b8fd5ea766bdfd2c54a3fe80859@pmq6v.m5r2.onet>
Date: Wed, 26 Jul 2023 11:46:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A48FB4E-2CE6-4539-A387-AB66F21DCADF@orangepill.ovh>
References: <95672223-c6bb7b8fd5ea766bdfd2c54a3fe80859@pmq6v.m5r2.onet>
To: vjudeu@gazeta.pl
X-Mailer: Apple Mail (2.3731.600.7)
X-Proofpoint-GUID: hw3p7YZwDyVyriypusa4PcZzC_RAYLP7
X-Proofpoint-ORIG-GUID: hw3p7YZwDyVyriypusa4PcZzC_RAYLP7
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
=?UTF-8?Q?2903e8d5c8f:6.0.573,18.0.957,17.0.605.474.0000000_definitions?=
=?UTF-8?Q?=3D2023-05-18=5F15:2023-05-17=5F02,2023-05-18=5F15,2020-01-23?=
=?UTF-8?Q?=5F02_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
spamscore=0 mlxscore=0
mlxlogscore=520 bulkscore=0 malwarescore=0 phishscore=0 suspectscore=0
clxscore=1030 classifier=spam adjust=0 reason=mlx scancount=1
engine=8.12.0-2212070000 definitions=main-2307260086
X-Mailman-Approved-At: Wed, 26 Jul 2023 14:38:10 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
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, 26 Jul 2023 09:47:07 -0000
I understand your point of view. However, inscription represent by far =
the largest spam attack due to their ability to embed themselves in the =
witness with a fee reduction.
Unlike other methods, such as using the op_return field which could also =
be used to spam the chain, the associated fees and the standardization =
rule limiting op_return to 80 bytes have so far prevented similar =
abuses.
Although attempting to stop inscription could lead to more serious =
issues, not taking action against these inscription could be interpreted =
by spammers as tacit acceptance of their practice. This could encourage =
more similar spam attacks in the future, as spammers might perceive that =
the Bitcoin network tolerates this kind of behavior.
I want to emphasize that my proposal does not involve implementing a =
soft fork in any way. On the contrary, what I am asking is simply to =
consider adding a standardization option. This option would allow the =
community to freely decide whether it should be activated or not.
> Le 26 juil. 2023 =C3=A0 07:30, vjudeu@gazeta.pl a =C3=A9crit :
>=20
>> and I would like to understand why this problem has not been =
addressed more seriously
>=20
> Because if nobody has any good solution, then status quo is preserved. =
If tomorrow ECDSA would be broken, the default state of the network =
would be "just do nothing", and every solution would be =
backward-compatible with that approach. Burn old coins, and people will =
call it "Tether", redistribute them, and people will call it "BSV". =
Leave everything untouched, and the network will split into N parts, and =
then you pick the strongest chain to decide, what should be done.
>=20
>> However, when it comes to inscriptions, there are no available =
options except for a patch produced by Luke Dashjr.
>=20
> Because the real solution should address some different problem, that =
was always there, and nobody knows, how to deal with it: the problem of =
forever-growing initial blockchain download time, and forever-growing =
UTXO set. Some changes with "assume UTXO" are trying to address just =
that, but this code is not yet completed.
>=20
>> So, I wonder why there are no options to reject inscriptions in the =
mempool of a node.
>=20
> Because it will lead you to never ending chase. You will block one =
inscriptions, and different ones will be created. Now, they are present =
even on chains, where there is no Taproot, or even Segwit. That means, =
if you try to kill them, then they will be replaced by N regular =
indistinguishable transactions, and then you will go back to those more =
serious problems under the hood: IBD time, and UTXO size.
>=20
>> Inscriptions are primarily used to sell NFTs or Tokens, concepts that =
the Bitcoin community has consistently rejected.
>=20
> The community also rejected things like sidechains, and they are still =
present, just in a more centralized form. There are some unstoppable =
concepts, for example soft-forks. You cannot stop a soft-fork. What =
inscription creators did, is just non-enforced soft-fork. They believe =
their rules are followed to the letter, but this is not the case, as you =
can create a valid Bitcoin transaction, that will be some invalid =
Ordinals transaction (because their additional rules are not enforced by =
miners and nodes).
>=20
>=20
>=20
|
