I am also sure you are not a pedo.
I have no bad feelings towards you except when you are not being honest. You can check our communication, I haven't responended to you or asked you questions before although I read all your comments. I started very recently when I felt dishonesty when you took a stance against BIP 110. And again its not the fact on which side but the arguments that you did.
I do respect your work for Bitcoin. I wouldn't be a Bitcoiner if I don't. But we see a prime example with Core that although they have been fine in the past they turned to the dark spam side for the last couple of years.
I don't agree that Bitcoiners who value Bitcoin as Freedom Money and have put their life savings in Bitcoin not only as store of value but to be part of the financial freedom revolution are a mob. We both know what is a memecoin, what is Ethereum shitcoin and so on. And you yourself say that you don't like spam.
I wish you see BIP 110 objectively for what it is.
It limits large arbitrary data, ALL large arbitrary data which happen to be non-monetary spam. That abuses Bitcoin. OP_RETURN up to 83 Bytes is allowed. That is objective truth taken from the BIP 110 itself. Yes someone can put 1000 smaller OP_RETURNs instead of one and that will cost him 1000 times more. BIP 110 fixes insctiptions and fixes important weaknesses and that are words of Bitcoin developers. Also simulations are done that show that BIP 110 allows monetary transactions. Bitcoin continues to be permissionless Monetary network as it should be.
Running BIP110 on Bitcoin Knots because Bitcoin is Freedom Money 🤙
https://github.com/bitcoin/bips/pull/2017#pullrequestreview-3384767316
"I'm generally supportive of the changes in this BIP. Aside from minor nitpicks in language, the 34 byte scriptPubKey restriction I think will prove to be quite valuable in addressing the larger concern of DoS blocks / poison blocks that impose such high computational costs on nodes that a single block would take 30 minutes to verify on decent hardware instead of taking about a second. This is an even larger threat to Bitcoin than either CSAM or quantum, because I've read that CSAM has already been present on Bitcoin for a very long time, and quantum computers aren't anywhere near good enough to be a threat, and may never be, whereas DoS blocks could be introduced by miners who take direct submissions without sufficient checks at any time.
It's been pointed out that disabling OP_SUCCESS in Tapscript would conflict with adding new signature verification opcodes in future BIPs that might use them to add quantum resistance, but I would point out that the semantics around existing opcodes could simply be altered to preserve compatibility with BIP 110. For example, instead of creating new sets of OP_CHECKSIG opcodes to support new signature schemes, the semantics of existing OP_CHECKSIG opcode could simply be adjusted to accept imperatively inputs of varying lengths, a form of overloading / polymorphism / or duck typing. While it could be argued that a more declarative approach is superior in cryptographic contexts, I don't weight that concern as heavily as the larger concern over DoS blocks, and as such, I'm supportive of this approach.
My only major objection is that this is temporary. I'm not very comfortable with either temporary soft forks or default node expiry because it forces users to act instead of delaying action, which I think delaying action is perfectly fine and reasonable as the protocol matures. It also reminds me too much of the "difficulty bomb" based monetary policy used to coerce Ethereum miners to adopt new code from the Ethereum foundation or else. That said, if BIP 110 were activated as is, I would still be supportive, and I would also support reactivating it in the future as a more permanent feature of Bitcoin.
At a high level, this proposal reminds me in spirit of early versions of my original P2QRH proposal. I just think it could use a little more polish, but I see it as being directionally correct."
About the reorg, this one option out of 4.
https://blockspaceweekly.substack.com/p/bip-110-the-miners-paradox