From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3CD5CC0032 for ; Tue, 25 Jul 2023 14:12:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id EC8B340B91 for ; Tue, 25 Jul 2023 14:12:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EC8B340B91 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=YZaXv9/5 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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, HTML_MESSAGE=0.001, 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 2xcooopoxiPm for ; Tue, 25 Jul 2023 14:12:05 +0000 (UTC) Received: from st43p00im-ztfb10073301.me.com (st43p00im-ztfb10073301.me.com [17.58.63.186]) by smtp2.osuosl.org (Postfix) with ESMTPS id 123324016F for ; Tue, 25 Jul 2023 14:12:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 123324016F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orangepill.ovh; s=sig1; t=1690294323; bh=MAR12H7lnruXqmv+1iYsMfyJvMSVRwhVPd0NEVMq/ys=; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To; b=YZaXv9/5679euQPSFGfmRVLxgLTt+qFAIos3oDKv6NpeSNk7mBu8F4bFFb9HofjpR W9Q4jHoJB3K65KQ/WcJXo6sU2Umpv7GidkBVbPqlg6cxuCTWeBBn/nBAIPnsVSLFQB 3YxuEXar8KgqbrWMm9d8hFhWk1eZcfGmhD+ff1AYMYaWIGRFvEtWT74s1bsgaI21qc pySlyl3vanTtktVkd6CtDKnZA5hYtfprh2sr2h/BUen7lB7WaU6HAlZT2AlExQ5H55 WTe836IOy9I6zjZeIhR6c27jEKmF0uG3+WNmxjZFGob1YCIMEpdI1ezvHoOBEfnE4T SQcG8aYWy+LOg== Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com [17.42.251.41]) by st43p00im-ztfb10073301.me.com (Postfix) with ESMTPSA id AD43F800D0B for ; Tue, 25 Jul 2023 14:12:01 +0000 (UTC) From: leohaf@orangepill.ovh Content-Type: multipart/alternative; boundary="Apple-Mail=_F26752E0-179A-455F-A0A1-B4FBD00D3647" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Message-Id: Date: Tue, 25 Jul 2023 16:11:49 +0200 To: bitcoin-dev@lists.linuxfoundation.org X-Mailer: Apple Mail (2.3731.600.7) X-Proofpoint-GUID: Ele9xdy3C6Ap0PYoUKokCYxC1QukM7xZ X-Proofpoint-ORIG-GUID: Ele9xdy3C6Ap0PYoUKokCYxC1QukM7xZ 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=2 mlxscore=2 malwarescore=0 clxscore=1030 mlxlogscore=173 bulkscore=0 spamscore=2 adultscore=0 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2307250125 X-Mailman-Approved-At: Tue, 25 Jul 2023 21:19:46 +0000 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2023 14:12:06 -0000 --Apple-Mail=_F26752E0-179A-455F-A0A1-B4FBD00D3647 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I am writing to you today because I am concerned about a significant bug = that seems to be overlooked in recent versions of the software. The bug = in question concerns the "inscriptions" developed by @rodarmor, and it = worries me because, in just a few months, they have already reached a = size of 11.8GB on the blockchain, causing issues with the UTXO set, = which appears to be growing by about 25MB per day. I understand that there may be discussions about the nature of these = inscriptions, but personally, I find it hard not to consider them as = spam. Their recurring nature and their impact on the size of the UTXO = set and the blockchain itself seem concerning, and I would like to = understand why this problem has not been addressed more seriously. I would also like to point out that there are options in Bitcoin Core to = choose the mempool policy, such as datacarrier or permitbaremultisig. = However, when it comes to inscriptions, there are no available options = except for a patch produced by Luke Dashjr. Unfortunately, this patch is = unusable for most people as it requires compiling Bitcoin Core. So, I wonder why there are no options to reject inscriptions in the = mempool of a node. Such a feature could give users the ability to = customize their approach in managing these particular cases and help = mitigate the negative impact of inscriptions on the network. In addition to the technical issues, I also find that this situation = raises ethical questions. Inscriptions are primarily used to sell NFTs = or Tokens, concepts that the Bitcoin community has consistently = rejected. Therefore, I kindly request you, as Bitcoin developers, to take this = concern into consideration and seriously consider implementing a feature = that would allow users to reject inscriptions in the mempool. Such a = measure would contribute to protecting the integrity of the network. Thank you sincerely for your attention to this matter. L=C3=A9o.= --Apple-Mail=_F26752E0-179A-455F-A0A1-B4FBD00D3647 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello,

I am = writing to you today because I am concerned about a significant bug that = seems to be overlooked in recent versions of the software. The bug in = question concerns the "inscriptions" developed by @rodarmor, and it = worries me because, in just a few months, they have already reached a = size of 11.8GB on the blockchain, causing issues with the UTXO set, = which appears to be growing by about 25MB per day.

I = understand that there may be discussions about the nature of these = inscriptions, but personally, I find it hard not to consider them as = spam. Their recurring nature and their impact on the size of the UTXO = set and the blockchain itself seem concerning, and I would like to = understand why this problem has not been addressed more = seriously.

I would also like to point out that = there are options in Bitcoin Core to choose the mempool policy, such as = datacarrier or permitbaremultisig. However, when it comes to = inscriptions, there are no available options except for a patch produced = by Luke Dashjr. Unfortunately, this patch is unusable for most people as = it requires compiling Bitcoin Core.

So, I = wonder why there are no options to reject inscriptions in the mempool of = a node. Such a feature could give users the ability to customize their = approach in managing these particular cases and help mitigate the = negative impact of inscriptions on the network.

In addition = to the technical issues, I also find that this situation raises ethical = questions. Inscriptions are primarily used to sell NFTs or Tokens, = concepts that the Bitcoin community has consistently rejected.

Therefore, = I kindly request you, as Bitcoin developers, to take this concern into = consideration and seriously consider implementing a feature that would = allow users to reject inscriptions in the mempool. Such a measure would = contribute to protecting the integrity of the network.

Thank you = sincerely for your attention to this matter.

L=C3=A9o.
= --Apple-Mail=_F26752E0-179A-455F-A0A1-B4FBD00D3647--