From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 11193C0032 for ; Wed, 26 Jul 2023 05:40:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id CC2E782163 for ; Wed, 26 Jul 2023 05:40:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CC2E782163 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=TRdZ4DF3 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 mvsgz261VXUJ for ; Wed, 26 Jul 2023 05:40:43 +0000 (UTC) X-Greylist: delayed 599 seconds by postgrey-1.37 at util1.osuosl.org; Wed, 26 Jul 2023 05:40:42 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CA18282157 Received: from smtpa39.poczta.onet.pl (smtpa39.poczta.onet.pl [213.180.142.39]) by smtp1.osuosl.org (Postfix) with ESMTPS id CA18282157 for ; Wed, 26 Jul 2023 05:40:42 +0000 (UTC) Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4R9jCv1J5gzlgNw8; Wed, 26 Jul 2023 07:30:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1690349435; bh=g9U/WvJrum/I/NA0GKez3F9Mjg3Xn6T0y0uLXebL7jE=; h=From:To:Date:Subject:From; b=TRdZ4DF3rorH9Tq9W3l671QCu8yIwFPnD0azMluFTOBtC/+ic/CgNy667POdCuXm/ 1eUuC9mrQODGXXECPNxXLVUfim228GAyyJDmphmyh0qNDayRUzWIgFRDgfgzd0sgeb 8OSCBhkVgA1itOnj/QuzRmtnHcasruteXUmnXsXQ= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.233.114] by pmq6v.m5r2.onet via HTTP id ; Wed, 26 Jul 2023 07:30:35 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "leohaf@orangepill.ovh" , "bitcoin-dev@lists.linuxfoundation.org" Date: Wed, 26 Jul 2023 07:30:32 +0200 Message-Id: <95672223-c6bb7b8fd5ea766bdfd2c54a3fe80859@pmq6v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.233.114;PL;2 X-Mailman-Approved-At: Wed, 26 Jul 2023 14:38:10 +0000 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: Wed, 26 Jul 2023 05:40:45 -0000 > and I would like to understand why this problem has not been addressed mo= re seriously Because if nobody has any good solution, then status quo is preserved. If t= omorrow ECDSA would be broken, the default state of the network would be "j= ust do nothing", and every solution would be backward-compatible with that = approach. Burn old coins, and people will call it "Tether", redistribute th= em, and people will call it "BSV". Leave everything untouched, and the netw= ork will split into N parts, and then you pick the strongest chain to decid= e, what should be done. > However, when it comes to inscriptions, there are no available options ex= cept for a patch produced by Luke Dashjr. Because the real solution should address some different problem, that was a= lways there, and nobody knows, how to deal with it: the problem of forever-= growing initial blockchain download time, and forever-growing UTXO set. Som= e changes with "assume UTXO" are trying to address just that, but this code= is not yet completed. > So, I wonder why there are no options to reject inscriptions in the mempo= ol of a node. Because it will lead you to never ending chase. You will block one inscript= ions, and different ones will be created. Now, they are present even on cha= ins, where there is no Taproot, or even Segwit. That means, if you try to k= ill them, then they will be replaced by N regular indistinguishable transac= tions, and then you will go back to those more serious problems under the h= ood: IBD time, and UTXO size. > Inscriptions are primarily used to sell NFTs or Tokens, concepts that the= Bitcoin community has consistently rejected. The community also rejected things like sidechains, and they are still pres= ent, just in a more centralized form. There are some unstoppable concepts, = for example soft-forks. You cannot stop a soft-fork. What inscription creat= ors did, is just non-enforced soft-fork. They believe their rules are follo= wed to the letter, but this is not the case, as you can create a valid Bitc= oin transaction, that will be some invalid Ordinals transaction (because th= eir additional rules are not enforced by miners and nodes).