path: root/5c/bd0534c1aeef57477a772b3ade98c2c17abb2f

Return-Path: <leohaf@orangepill.ovh>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0F1C8C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 19:04:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 9E4FF83134
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 19:04:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9E4FF83134
Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=orangepill.ovh header.i=@orangepill.ovh
 header.a=rsa-sha256 header.s=sig1 header.b=kF5wui99
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level: 
X-Spam-Status: No, score=-0.553 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, FAKE_REPLY_B=2.244,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 SQ8wnnzZ-2Fi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 19:04:13 +0000 (UTC)
Received: from st43p00im-zteg10063501.me.com (st43p00im-zteg10063501.me.com
 [17.58.63.176])
 by smtp1.osuosl.org (Postfix) with ESMTPS id DE6318308B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 19:04:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DE6318308B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orangepill.ovh;
 s=sig1; t=1690484651;
 bh=RFVmYvMUlzyJ/YN+TKpfb4ut4LhFRvnsj3PipfGisss=;
 h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To;
 b=kF5wui99Qsv3JM8kVDdeaQR3e6S6/lejgKHJZcY9eI8WpYgIG0cUcV3GPP3Zht5CK
 lPir38m306EJuaJwM4bzgdvzcco4DEoVRrsMgBOfBQq0aCgpQ711x3bjjNz9sQLbgy
 f6KrOFj+GQFOMYj2Wumbpjv38wtp494cZt7djX03rFE+wcrg75R1RhMaPYyvkLkbx+
 0buayeg3Z32ufdvGRXQQSUayQKM0fp+jccVjk4fNCtE9ipIu9iZTseLYTZ/tMPSRr3
 71Meh8bBGPGbU0LZQwKC+2whxqyWucY0Fh4YQMeiyajHk4UPzTfzla9QXTrfgEWDQl
 jDWIzJK2q3vGA==
Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com
 [17.42.251.41])
 by st43p00im-zteg10063501.me.com (Postfix) with ESMTPSA id F0E1D4C11F4;
 Thu, 27 Jul 2023 19:04:10 +0000 (UTC)
From: =?utf-8?Q?L=C3=A9o_Haf?= <leohaf@orangepill.ovh>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_50AC24BF-D556-4E79-B6A8-0CE6A94E37C3"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Message-Id: <052BECB8-4218-44A7-BABF-5A2CD94F2A5E@orangepill.ovh>
Date: Thu, 27 Jul 2023 21:03:58 +0200
To: vjudeu@gazeta.pl
X-Mailer: Apple Mail (2.3731.600.7)
X-Proofpoint-ORIG-GUID: M514W54T5whisoE_6L9pAzwl9vaU1Yex
X-Proofpoint-GUID: M514W54T5whisoE_6L9pAzwl9vaU1Yex
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.0.605.474.0000000_definitions?=
 =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2020-01-23?=
 =?UTF-8?Q?=5F02_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 phishscore=0 mlxscore=0
 mlxlogscore=870 adultscore=0 clxscore=1030 suspectscore=0 malwarescore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2307270173
X-Mailman-Approved-At: Sun, 30 Jul 2023 18:04:38 +0000
Cc: 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 19:04:15 -0000


--Apple-Mail=_50AC24BF-D556-4E79-B6A8-0CE6A94E37C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

=EF=BB=BFAccording to you, the rules of standardization are useless but =
in this case why were they introduced? The opreturn limit can be =
circumvented by miners, yet it is rare to see any, the same for =
maxancestorcount, minrelayfee or even the dust limit.

This cat and mouse game can be won by bitcoin defenders. Why ? Because =
it is easier to detect these transactions and make them a =
standardization rule than to create new types of spam transactions.

As for the default policy, it can be a weakness but also a strength =
because if the patch is integrated into Bitcoin Core by being activated =
by default, the patch will become more and more effective as the nodes =
update.

Also, when it came to using a pre-segwit node, it is not a solution =
because this type of node cannot initiate new ones, which is obviously a =
big problem.

Finally, I would like to quote satoshi himself who wrote about spam here =
is the link: https://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617=


> Le 27 juil. 2023 =C3=A0 07:10, vjudeu@gazeta.pl a =C3=A9crit :
>=20
> =EF=BB=BF
>> not taking action against these inscription could be interpreted by =
spammers as tacit acceptance of their practice.
>=20
> Note that some people, even on this mailing list, do not consider =
Ordinals as spam: =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/0214=
64.html
>=20
> See? It was discussed when it started. Some people believe that =
blocking Ordinals is censorship, and could lead to blocking regular =
transactions in the future, just based on other criteria. That means, =
even if developers would 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-dev/2023-February/0214=
87.html
>=20
>> as spammers might perceive that the Bitcoin network tolerates this =
kind of behavior
>=20
> 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 whitepaper was uploaded just on 1-of-3 multisig outputs, see =
transaction =
54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. You =
have the whole altcoins that are connected to Bitcoin by using part of =
the Bitcoin's UTXO set as their database.
>=20
> That means, as long as you won't solve IBD problem and UTXO set =
growing problem, you will go nowhere, because if you block Ordinals =
specifically, people 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-consensus data, like it could be done =
in "assume UTXO" model.
>=20
> Also note that as long as people use Taproot to upload a lot of data, =
you can still turn off the witness, and become a pre-Segwit node. But if =
you block those ways, then people will push data into legacy parts, and =
then you will need more code to strip it correctly. The block 774628 =
maybe contains almost 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 maybe just a few kilobytes.
>=20
>> 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.
>=20
> 1. Without a soft-fork, those data will be pushed by mining pools =
anyway, as it happened in the block 774628.
> 2. Adding some settings won't help, as most people use the default =
configuration. For example, people can configure their nodes to allow =
free transactions, without recompiling anything. The same with disabling =
dust amounts. But 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 easily bypass those restrictions. This will be just a cat =
and mouse game, where spammers will even use P2PK, if they will be =
forced to. The Pandora's box is already opened, that fix could be good =
for February or March, but not now.
>=20
>=20
>=20
>> On 2023-07-26 11:47:09 user leohaf@orangepill.ovh wrote:
>> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
>>> 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 more 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 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.
>>> However, when it comes to inscriptions, there are no available =
options except 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 =
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.
>>> So, I wonder why there are no options to reject inscriptions in the =
mempool of a node.
>> 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.
>>> 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 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).

--Apple-Mail=_50AC24BF-D556-4E79-B6A8-0CE6A94E37C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><meta =
http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div =
dir=3D"auto"><div dir=3D"ltr">=EF=BB=BF<span>According to you, the rules =
of standardization are useless but in this case why were they =
introduced? The opreturn limit can be circumvented by miners, yet it is =
rare to see any, the same for maxancestorcount, minrelayfee or even the =
dust limit.</span><br><span></span><br><span>This cat and mouse game can =
be won by bitcoin defenders. Why ? Because it is easier to detect these =
transactions and make them a standardization rule than to create new =
types of spam transactions.</span></div><div dir=3D"ltr"><br>As for the =
default policy, it can be a weakness but also a strength because if the =
patch is integrated into Bitcoin Core by being activated by default, the =
patch will become more and more effective as the nodes =
update.<br><span></span><br><span>Also, when it came to using a =
pre-segwit node, it is not a solution because this type of node cannot =
initiate new ones, which is obviously a big =
problem.</span><br><span></span><br></div><div dir=3D"ltr">Finally, I =
would like to quote satoshi himself who wrote about spam here is the =
link:&nbsp;<a =
href=3D"https://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617">htt=
ps://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617</a></div><div =
dir=3D"ltr"><br><div dir=3D"ltr"></div><blockquote type=3D"cite"><span>Le =
27 juil. 2023 =C3=A0 07:10, vjudeu@gazeta.pl a =C3=A9crit =
:</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>=EF=BB=BF</span><br></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>not taking action against =
these inscription could be interpreted by spammers as tacit acceptance =
of their practice.</span><br></blockquote></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>Note that some people, even on this mailing list, do =
not consider Ordinals as spam: =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/0214=
64.html</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>See? It was discussed when it started. Some people =
believe that blocking Ordinals is censorship, and could lead to blocking =
regular transactions in the future, just based on other criteria. That =
means, even if developers would 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-dev/2023-February/0214=
87.html</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>as spammers might perceive =
that the Bitcoin network tolerates this kind of =
behavior</span><br></blockquote></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>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 whitepaper was uploaded just on 1-of-3 =
multisig outputs, see transaction =
54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. You =
have the whole altcoins that are connected to Bitcoin by using part of =
the Bitcoin's UTXO set as their =
database.</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>That means, as long as you won't solve IBD problem =
and UTXO set growing problem, you will go nowhere, because if you block =
Ordinals specifically, people 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-consensus data, like it could be =
done in "assume UTXO" model.</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>Also note that as long as people use Taproot to =
upload a lot of data, you can still turn off the witness, and become a =
pre-Segwit node. But if you block those ways, then people will push data =
into legacy parts, and then you will need more code to strip it =
correctly. The block 774628 maybe contains almost 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 maybe just a few =
kilobytes.</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>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.</span><br></blockquote></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>1. Without a soft-fork, those data will be pushed by =
mining pools anyway, as it happened in the block =
774628.</span><br></blockquote><blockquote type=3D"cite"><span>2. Adding =
some settings won't help, as most people use the default configuration. =
For example, people can configure their nodes to allow free =
transactions, without recompiling anything. The same with disabling dust =
amounts. But good luck finding a node in the wild that does anything =
unusual.</span><br></blockquote><blockquote type=3D"cite"><span>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 =
easily bypass those restrictions. This will be just a cat and mouse =
game, where spammers will even use P2PK, if they will be forced to. The =
Pandora's box is already opened, that fix could be good for February or =
March, but not now.</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>On 2023-07-26 11:47:09 =
user leohaf@orangepill.ovh =
wrote:</span><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>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.</span><br></blockquote></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>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.</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>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.</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span>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.</span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><span></span><br></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>Le=
 26 juil. 2023 =C3=A0 07:30, vjudeu@gazeta.pl a =C3=A9crit =
:</span><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><span>and I would like to understand why this problem has =
not been addressed more =
seriously</span><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>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.</span><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><span>However, when it comes to inscriptions, there are no =
available options except for a patch produced by Luke =
Dashjr.</span><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>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.</span><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><span>So, I wonder why there are no options to reject =
inscriptions in the mempool of a =
node.</span><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>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.</span><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><span>Inscriptions are primarily used to sell NFTs or =
Tokens, concepts that the Bitcoin community has consistently =
rejected.</span><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><span>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).</span><br></blockquote></blockquote></div></div></body></html>=

--Apple-Mail=_50AC24BF-D556-4E79-B6A8-0CE6A94E37C3--