Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0F1C8C0032 for ; 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 ; 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 ; 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 ; 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?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
=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: htt= ps://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617

Le = 27 juil. 2023 =C3=A0 07:10, vjudeu@gazeta.pl a =C3=A9crit = :

=EF=BB=BF
not taking action against = these inscription could be interpreted by spammers 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-February/0214= 64.html

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

as spammers might perceive = that the Bitcoin network tolerates this kind of = 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 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.

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.

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.

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.

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.



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.

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 = :
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--