Next scheduled rescrape ... never
Version 2
Last scraped
Edited on 13/05/2025, 08:35:03 UTC
Quote
This would need to be fixed at the protocol level to make it impossible
If that's the case, then I wonder, when Monero will fix it: https://mordinals.gitbook.io/handbook/how-does-it-workAre there any plans to ban Ordinals from Monero?
The only resistant chain I know of is Grin, because users cannot control, how their data pushes will be represented on-chain, so they will be shuffled in the process, which will make them useless.
It has already been fixed by limiting the size of the tx_extra field to 32 bytes (if I remember correctly), I think it has discouraged spammers.
I could only find 2 years old mordinals through Mordinals explorer.
Of course, there will always be the possibility to encrypt data in fields that are not designed for it, even in the transaction amount itself.
In Bitcoin, with its fixed block size, the problem is more severe and impacts regular users who just want to transact, resulting in higher fees and longer queues to be included in a block.
This would need to be fixed at the protocol level to make it impossible - and we all know nothing will be done.
From what I've read on GitHub, there is a solution for it, but people argue it shouldn't be implemented, and every discussion on the topic is eventually closed.
From what I've read on GitHub, there is a solution for it, but people argue it shouldn't be implemented, and every discussion on the topic is eventually closed.
Can you share discussion link which makes it impossible, including misuse of address and public key to store arbitrary data?
*Possible* - I don't know if it fixed all the possibilities, but it certainly addressed the main one that was being abused.
https://github.com/bitcoin/bitcoin/issues/29187
Their conclusion to the exploited protocol hole:
Quote
This CVE is disputed. The large majority of contributors to this project disagree this is indeed a security vulnerability. I personally believe the CVE system is being abused in this case.
I believe this issue should be closed. There is no point in keeping it open.
I believe this issue should be closed. There is no point in keeping it open.
Some of these "contributors" who refuse to fix the issue have been found to be connected to Ordinals, making money either directly or indirectly by forcing users to adopt their Layer 2 "solutions."
Version 1
Scraped on 13/05/2025, 08:09:51 UTC
Quote
This would need to be fixed at the protocol level to make it impossible
If that's the case, then I wonder, when Monero will fix it: https://mordinals.gitbook.io/handbook/how-does-it-workAre there any plans to ban Ordinals from Monero?
The only resistant chain I know of is Grin, because users cannot control, how their data pushes will be represented on-chain, so they will be shuffled in the process, which will make them useless.
It has
Of course, there will always be the possibility to encrypt data in fields that are not designed for it, even in the transaction amount itself.
In Bitcoin, with its fixed block size, the problem is more severe and impacts regular users who just want to transact, resulting in higher fees and longer queues to be included in a block.
Original archived Re: Removing OP_return limits seems like a huge mistake
Scraped on 13/05/2025, 08:04:51 UTC
Quote
This would need to be fixed at the protocol level to make it impossible
If that's the case, then I wonder, when Monero will fix it: https://mordinals.gitbook.io/handbook/how-does-it-workAre there any plans to ban Ordinals from Monero?
The only resistant chain I know of is Grin, because users cannot control, how their data pushes will be represented on-chain, so they will be shuffled in the process, which will make them useless.
It has been already fixed by limiting the size of tx_extra field to 32 bytes (If I remember correctly).