Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: "leohaf@orangepill.ovh" <leohaf@orangepill.ovh>,
 "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Date: Wed, 26 Jul 2023 07:30:32 +0200
Message-Id: <95672223-c6bb7b8fd5ea766bdfd2c54a3fe80859@pmq6v.m5r2.onet>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
Precedence: list

> 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).