Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: leohaf@orangepill.ovh
In-Reply-To: <95672223-c6bb7b8fd5ea766bdfd2c54a3fe80859@pmq6v.m5r2.onet>
Date: Wed, 26 Jul 2023 11:46:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A48FB4E-2CE6-4539-A387-AB66F21DCADF@orangepill.ovh>
References: <95672223-c6bb7b8fd5ea766bdfd2c54a3fe80859@pmq6v.m5r2.onet>
To: vjudeu@gazeta.pl
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
Precedence: list

I understand your point of view. However, inscription represent by far =
the largest spam attack due to their ability to embed themselves in the =
witness 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 limiting 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 spammers as tacit acceptance of their practice. This could encourage =
more similar spam attacks in the future, as spammers might perceive that =
the Bitcoin network tolerates this kind of behavior.

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 adding a standardization option. This option would allow the =
community to freely decide whether it should be activated or not.


> Le 26 juil. 2023 =C3=A0 07:30, vjudeu@gazeta.pl a =C3=A9crit :
>=20
>> and I would like to understand why this problem has not been =
addressed more seriously
>=20
> 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 that approach. Burn old coins, and people will =
call it "Tether", redistribute them, and people will call it "BSV". =
Leave everything untouched, and the network will split into N parts, and =
then you pick the strongest chain to decide, what should be done.
>=20
>> However, when it comes to inscriptions, there are no available =
options except for a patch produced by Luke Dashjr.
>=20
> Because the real solution should address some different problem, that =
was always there, and nobody knows, how to deal with it: the problem of =
forever-growing initial blockchain download time, and forever-growing =
UTXO set. Some changes with "assume UTXO" are trying to address just =
that, but this code is not yet completed.
>=20
>> So, I wonder why there are no options to reject inscriptions in the =
mempool of a node.
>=20
> Because it will lead you to never ending chase. You will block one =
inscriptions, and different ones will be created. Now, they are present =
even on chains, 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 transactions, and then you will go back to those more =
serious problems under the hood: IBD time, and UTXO size.
>=20
>> Inscriptions are primarily used to sell NFTs or Tokens, concepts that =
the Bitcoin community has consistently rejected.
>=20
> The community also rejected things like sidechains, and they are still =
present, just in a more centralized form. There are some unstoppable =
concepts, for example soft-forks. You cannot stop a soft-fork. What =
inscription creators did, is just non-enforced soft-fork. They believe =
their rules are followed to the letter, but this is not the case, as you =
can create a valid Bitcoin transaction, that will be some invalid =
Ordinals transaction (because their additional rules are not enforced by =
miners and nodes).
>=20
>=20
>=20