path: root/b2/0c12c3dc29e6b5eb626638dd1fb5517f58c868

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 99821C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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" <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: <vjudeu@gazeta.pl>;5.173.241.56;PL;2
X-Mailman-Approved-At: Thu, 27 Jul 2023 08:29:00 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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).
> =

> =

> =