> protonmail.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> > 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.
>
> One of the things discussed during the mempoolfullrbf discussion is that a
> small (~10%) of nodes willing to relay a class of transaction is enough for
> that class of transaction to consistently reach miners. That means you
> would need to get nearly the entire network to run updated relay policy to
> prevent inscriptions from trivially reaching miners and being included in
> blocks. Inscription users have shown that they are willing and able to send
> non-standard transactions to miners out of band (
> https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae),
> so even if you managed to get enough of the network running the new rule to
> prevent propagation to miners, those users can just go out of band. Or,
> they can simply change the script that is used to embed an inscription in
> the transaction witness. For example, instead of 0 OP_IF?, maybe they do 0
> OP_DUP OP_DROP OP_IF. When the anti-inscription people detect this, they
> have to update the rule and wait for 90%
> + of the network to upgrade. When the pro-inscription people see this,
> they only have to convince other inscription enthusiasts and businesses to
> update.
>
> The anti-inscription patch has to be run by many more participants (most
> of whom don?t care), while the pro-inscription update has to be run by a
> small number of people who care a lot. It?s a losing battle for the
> anti-inscription people.
>
> If you want to prevent inscriptions, the best answer we know of today is
> economic: the cost of the blockspace needs to be more expensive than
> inscribers are willing to pay, either because its too expensive or because
> there?s no market demand for inscriptions. The former relies on Bitcoin
> becoming more useful to more people, the latter is the natural course of
> collectibles.
>
> > Finally, I would like to quote satoshi himself who wrote about spam here
> is the link: https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>
> Appeals to Satoshi are not compelling arguments.
>
> Cheers,
> Rijndael
>
> On Sun, Jul 30, 2023 at 2:04 PM, L?o Haf via bitcoin-dev <[
> bitcoin-dev at lists.linuxfoundation.org](mailto:On Sun, Jul 30, 2023 at
> 2:04 PM, L?o Haf via bitcoin-dev < wrote:
>
> > ?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.
> >
> > 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=195.msg1617#msg1617
> >
> >> Le 27 juil. 2023 ? 07:10, vjudeu at gazeta.pl a ?crit :
> >
> >>
> >
> >> ?
> >
> >>> 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/021464.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/021487.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 at 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 ? 07:30, vjudeu at gazeta.pl a ?crit :
> >
> >>>> 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).
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 98, Issue 20
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230731/44d8e3ad/attachment-0001.html>
