From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 99821C0032 for ; Thu, 27 Jul 2023 05:10:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7A15F83A52 for ; Thu, 27 Jul 2023 05:10:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7A15F83A52 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=yVbbBaOH X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 i-YMQc4AQdyn for ; Thu, 27 Jul 2023 05:10:41 +0000 (UTC) Received: from smtpa40.poczta.onet.pl (smtpa40.poczta.onet.pl [213.180.142.40]) by smtp1.osuosl.org (Postfix) with ESMTPS id BA92B8398E for ; Thu, 27 Jul 2023 05:10:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org BA92B8398E Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4RBJkJ3F7Vzlg2RW; Thu, 27 Jul 2023 07:10:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1690434632; bh=LUOYNFat6GhsL5shrTeIZDsPG5oidzBQ4txK/4PODos=; h=From:Cc:To:Date:Subject:From; b=yVbbBaOHcR/69zD4A1mV3OJhFe1A5ZAETYq+E3SP25o7y7OVf2X6dKuuZwq4ep0St BGB+KfL+mc+vp1iyEEnyNV4JEAIzW3NSH3DqS+3G6A/koh11u36XEEfmPf8mv53AJX mSSUP7RvX26OO42CWGN4VHdT+cB47nFM4MXchfPY= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.241.56] by pmq8v.m5r2.onet via HTTP id ; Thu, 27 Jul 2023 07:10:32 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "leohaf@orangepill.ovh" Date: Thu, 27 Jul 2023 07:10:32 +0200 Message-Id: <163542243-7186ea0fe48e5b37fbd915d4b7ed7878@pmq8v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.241.56;PL;2 X-Mailman-Approved-At: Thu, 27 Jul 2023 08:29:00 +0000 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2023 05:10:42 -0000 > not taking action against these inscription could be interpreted by spamm= ers as tacit acceptance of their practice. Note that some people, even on this mailing list, do not consider Ordinals = as spam: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Febru= ary/021464.html See? It was discussed when it started. Some people believe that blocking Or= dinals is censorship, and could lead to blocking regular transactions in th= e future, just based on other criteria. That means, even if developers woul= d create some official version with that option, then some people would not= follow them, or even block Ordinals-filtering nodes, exactly as described = in the linked thread: https://lists.linuxfoundation.org/pipermail/bitcoin-d= ev/2023-February/021487.html > as spammers might perceive that the Bitcoin network tolerates this kind o= f behavior But it is true, you have the whole pages, where you can find images, files,= or other data, that was pushed on-chain long before Ordinals. The whole wh= itepaper was uploaded just on 1-of-3 multisig outputs, see transaction 54e4= 8e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. You have the = whole altcoins that are connected to Bitcoin by using part of the Bitcoin's= UTXO set as their database. That means, as long as you won't solve IBD problem and UTXO set growing pro= blem, you will go nowhere, because if you block Ordinals specifically, peop= le won't learn "this is bad, don't do that", they could read it as "use the= old way instead", as long as you won't block all possible ways. And doing = that, requires for example creating new nodes, without synchronizing non-co= nsensus data, like it could be done in "assume UTXO" model. Also note that as long as people use Taproot to upload a lot of data, you c= an still turn off the witness, and become a pre-Segwit node. But if you blo= ck those ways, then people will push data into legacy parts, and then you w= ill need more code to strip it correctly. The block 774628 maybe contains a= lmost 4 MB of data from the perspective of Segwit node, but the legacy part= is actually very small, so by turning witness off, you can strip it to may= be just a few kilobytes. > 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 a= dding a standardization option. This option would allow the community to fr= eely decide whether it should be activated or not. 1. Without a soft-fork, those data will be pushed by mining pools anyway, a= s it happened in the block 774628. 2. Adding some settings won't help, as most people use the default configur= ation. For example, people can configure their nodes to allow free transact= ions, without recompiling anything. The same with disabling dust amounts. B= ut good luck finding a node in the wild that does anything unusual. 3. This patch produced by Luke Dashjr does not address all cases. You could= use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used by Ordinals, and e= asily bypass those restrictions. This will be just a cat and mouse game, wh= ere spammers will even use P2PK, if they will be forced to. The Pandora's b= ox is already opened, that fix could be good for February or March, but not= now. On 2023-07-26 11:47:09 user leohaf@orangepill.ovh wrote: > I understand your point of view. However, inscription represent by far th= e largest spam attack due to their ability to embed themselves in the witne= ss 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 l= imiting 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 spammer= s as tacit acceptance of their practice. This could encourage more similar = spam attacks in the future, as spammers might perceive that the Bitcoin net= work tolerates this kind of behavior. I want to emphasize that my proposal does not involve implementing a soft f= ork in any way. On the contrary, what I am asking is simply to consider add= ing a standardization option. This option would allow the community to free= ly decide whether it should be activated or not. > Le 26 juil. 2023 =C3=A0 07:30, vjudeu@gazeta.pl a =C3=A9crit : > = >> and I would like to understand why this problem has not been addressed m= ore seriously > = > 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 tha= t approach. Burn old coins, and people will call it "Tether", redistribute = them, and people will call it "BSV". Leave everything untouched, and the ne= twork will split into N parts, and then you pick the strongest chain to dec= ide, what should be done. > = >> However, when it comes to inscriptions, there are no available options e= xcept for a patch produced by Luke Dashjr. > = > Because the real solution should address some different problem, that was= always there, and nobody knows, how to deal with it: the problem of foreve= r-growing initial blockchain download time, and forever-growing UTXO set. S= ome changes with "assume UTXO" are trying to address just that, but this co= de is not yet completed. > = >> So, I wonder why there are no options to reject inscriptions in the memp= ool of a node. > = > Because it will lead you to never ending chase. You will block one inscri= ptions, and different ones will be created. Now, they are present even on c= hains, 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 trans= actions, and then you will go back to those more serious problems under the= hood: IBD time, and UTXO size. > = >> Inscriptions are primarily used to sell NFTs or Tokens, concepts that th= e Bitcoin community has consistently rejected. > = > The community also rejected things like sidechains, and they are still pr= esent, just in a more centralized form. There are some unstoppable concepts= , for example soft-forks. You cannot stop a soft-fork. What inscription cre= ators did, is just non-enforced soft-fork. They believe their rules are fol= lowed to the letter, but this is not the case, as you can create a valid Bi= tcoin transaction, that will be some invalid Ordinals transaction (because = their additional rules are not enforced by miners and nodes). > = > = > =