Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 77AFAC0032 for ; Thu, 27 Jul 2023 13:06:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 52B8B4018F for ; Thu, 27 Jul 2023 13:06:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 52B8B4018F X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RurnQt_LNGxX for ; Thu, 27 Jul 2023 13:06:42 +0000 (UTC) X-Greylist: delayed 8731 seconds by postgrey-1.37 at util1.osuosl.org; Thu, 27 Jul 2023 13:06:42 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6091D400D0 Received: from 2.mo548.mail-out.ovh.net (2.mo548.mail-out.ovh.net [178.33.255.19]) by smtp2.osuosl.org (Postfix) with ESMTPS id 6091D400D0 for ; Thu, 27 Jul 2023 13:06:42 +0000 (UTC) Received: from mxplan6.mail.ovh.net (unknown [10.109.143.25]) by mo548.mail-out.ovh.net (Postfix) with ESMTPS id 419AF21B72; Thu, 27 Jul 2023 10:41:08 +0000 (UTC) Received: from peersm.com (37.59.142.109) by DAG6EX2.mxp6.local (172.16.2.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Thu, 27 Jul 2023 12:41:07 +0200 Authentication-Results: garm.ovh; auth=pass (GARM-109S003dc5f1f5d-c9ba-45c1-8333-c2da47b11898, 62DEFCF61F8FED0F11D287297961668B007FB0AA) smtp.auth=aymeric@peersm.com X-OVh-ClientIp: 92.184.107.155 Content-Type: multipart/alternative; boundary="Apple-Mail-A63D5894-EB08-4DAF-8545-C6A872C9E7B8" Content-Transfer-Encoding: 7bit From: "aymeric@peersm.com" MIME-Version: 1.0 (1.0) Date: Thu, 27 Jul 2023 12:41:06 +0200 Message-ID: <55D64031-B210-4971-B353-E31A68268A58@peersm.com> References: In-Reply-To: To: , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (17H35) X-Originating-IP: [37.59.142.109] X-ClientProxiedBy: DAG4EX1.mxp6.local (172.16.2.31) To DAG6EX2.mxp6.local (172.16.2.52) X-Ovh-Tracer-GUID: ca672bd9-699f-4a7d-96ab-2ad575fc9645 X-Ovh-Tracer-Id: 5315373463679493018 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedviedrieeggddthecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurheptgfghfggufffkfhfjgfvofhisegrjehmrehhtdejnecuhfhrohhmpedfrgihmhgvrhhitgesphgvvghrshhmrdgtohhmfdcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepteeigfeftdehudegudevgfethfdtuddtleeiveeggeegheeugeefjeejhfefhfdunecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutdelpdelvddrudekgedruddtjedrudehheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtoheplhgvohhhrghfsehorhgrnhhgvghpihhllhdrohhvhhdpsghithgtohhinhdquggvvheslhhishhtshdrlhhinhhugihfohhunhgurghtihhonhdrohhrghdpoffvtefjohhsthepmhhoheegkedpmhhouggvpehsmhhtphhouhht X-Mailman-Approved-At: Sun, 30 Jul 2023 18:04:24 +0000 Subject: Re: [bitcoin-dev] [SPAM] 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: Thu, 27 Jul 2023 13:06:44 -0000 --Apple-Mail-A63D5894-EB08-4DAF-8545-C6A872C9E7B8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable See #28130 on bitcoin repo Of course the intent is not to store "inscriptions" but a reference Whatever you do bitcoin cannot avoid deviant practices Therefore that one is the right way to go Envoy=C3=A9 de mon iPhone > Le 25 juil. 2023 =C3=A0 23:19, L=C3=A9o via bitcoin-dev a =C3=A9crit : >=20 > =EF=BB=BF > Hello, >=20 > I am writing to you today because I am concerned about a significant bug t= hat seems to be overlooked in recent versions of the software. The bug in qu= estion 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 o= n the blockchain, causing issues with the UTXO set, which appears to be grow= ing by about 25MB per day. >=20 > I understand that there may be discussions about the nature of these inscr= iptions, but personally, I find it hard not to consider them as spam. Their r= ecurring nature and their impact on the size of the UTXO set and the blockch= ain itself seem concerning, and I would like to understand why this problem h= as not been addressed more seriously. >=20 > I would also like to point out that there are options in Bitcoin Core to c= hoose 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 mo= st people as it requires compiling Bitcoin Core. >=20 > So, I wonder why there are no options to reject inscriptions in the mempoo= l of a node. Such a feature could give users the ability to customize their a= pproach in managing these particular cases and help mitigate the negative im= pact of inscriptions on the network. >=20 > In addition to the technical issues, I also find that this situation raise= s ethical questions. Inscriptions are primarily used to sell NFTs or Tokens,= concepts that the Bitcoin community has consistently rejected. >=20 > Therefore, I kindly request you, as Bitcoin developers, to take this conce= rn into consideration and seriously consider implementing a feature that wou= ld allow users to reject inscriptions in the mempool. Such a measure would c= ontribute to protecting the integrity of the network. >=20 > Thank you sincerely for your attention to this matter. >=20 > L=C3=A9o. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-A63D5894-EB08-4DAF-8545-C6A872C9E7B8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable See #28130 on bitcoin repo

Of course the intent is not to store "inscriptions" but a reference=

Whatever you do bitcoin cannot avoid deviant practices

Therefore that one is the right way to go

Envoy=C3=A9 de mon iPhone

Le 25 juil. 2023 =C3=A0 23:19, L=C3=A9o via bitcoin-dev <= bitcoin-dev@lists.linuxfoun@lists.linuxfoundation.org> a =C3=A9crit = :

=EF=BB= =BF
Hello,

I am writing t= o you today because I am concerned about a significant bug that seems to be o= verlooked in recent versions of the software. The bug in question concerns t= he "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 ab= out the nature of these inscriptions, but personally, I find it hard not to c= onsider 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 Bitc= oin Core to choose the mempool policy, such as datacarrier or permitbaremult= isig. However, when it comes to inscriptions, there are no available options= except for a patch produced by Luke Dashjr. Unfortunately, this patch is un= usable for most people as it requires compiling Bitcoin Core.

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

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

Ther= efore, I kindly request you, as Bitcoin developers, to take this concern int= o consideration and seriously consider implementing a feature that would all= ow users to reject inscriptions in the mempool. Such a measure would contrib= ute to protecting the integrity of the network.

Thank yo= u sincerely for your attention to this matter.

L=C3=A9o= .
_______________________________________________bitcoin-dev mailing list
bitcoin-dev@lists.linuxfound= ation.org
https://lists.linuxfoundation.org/mailman/listinfo= /bitcoin-dev
= --Apple-Mail-A63D5894-EB08-4DAF-8545-C6A872C9E7B8--