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>
Date: Thu, 27 Jul 2023 07:10:32 +0200
Message-Id: <163542243-7186ea0fe48e5b37fbd915d4b7ed7878@pmq8v.m5r2.onet>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
Precedence: list

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

> =

> =