Question - how did the fix in Knots come about? Was it through limiting the size of Witness scripts? or simply targeting the op_if op_endif combination for [non]relay?

My research on this at the time... was that most Core developers thought the arbitrary data combination could easily be replicated with other opcodes, slightly changed, and repeated or reproduced ever so slightly different.

So it would be like 'whack a mole' because the exact scripts could be changed slightly again and again and filtering each time would do more harm than good.

Today, the reason for not 'filtering' is that the 90% threshold would never be met... and filtering inscriptions today would harm the mempool, fee estimation, and be ineffective regardless a net negative.

So it has not been changed.

The other explanations I've read is that larger witness 'blobs' aren't economic... the NFTs or jpegs are DoS attacks noone is really buying them. Attackers will change or alter their attack ever so slightly... because they don't care about the arbitrary data ITSELF, just attacking Bitcoin noone is buying monkey jpegs.

Which I also think is true.

I have tried for hours and hours.

That's not true. And I can read the tea leaves.

If users get to decide, and everyone is free and honorable in their choice of which node software to run...

Then why do Knots users care what Core does? Core users can run Core, and Knots users can run Knots etc and that way everyone can be happy.

Everyone is free to set their own mempool/relay policies as they see fit... Why would it matter then what 'percentage' of the network runs Knots if it is purely an individual choice? It could be 2%, it could be 65% it's purely an individual choice... and people can mine or relay etc whatever they choose based usually on fees/ideology/personal preference etc.

I agree that it is just mempool policy... but being that it is, it doesn't really matter what Core does because everyone is free to choose their own mempool policies and participate together.

To say otherwise... doesn't make sense to me.

My post as the 'op' wasn't related to the Lukejr article. I'm not sure that article is credible or relevant...

But I do think there will be a fork eventually otherwise how will the concerns of the Knots enthusiasts be addressed or satisfied?

Clearly to them (which is totally their choice) running Core isn't acceptable, and neither is the spam. Spam isn't going to be 100% solved under core v30... and it isn't solved now either.

So a serious, meaningful solution needs to be found which invalidates such spam in blocks itself and if that invalidates 'core' blocks then it's a hard fork.

What am I missing?

That is a lot of 'configuration' options...

How do you/we know that any of that 20% of nodes is real??? Those nodes don't pay fees. They don't compete for blockspace. They don't (necessarily) hold the keys to Bitcoin either.

What is the point of 'spooling up more nodes'... if it could be 1 node or 2 or 5 or 100 nodes per person? Are those nodes actually being used?

I don't like controversy... however it's what people want to talk about, and I want to have an informed discussion.

I think continuing with Core is the right thing to do... because I think that un-limiting/un-restricting the sizes of op_return is the 'right thing' to do in the long run.

Even if the corporations run Knots... they are still storing and relaying and verifying "illegal material" that might, could, possibly be in blocks.

Even a non-listening node relays blocks to other nodes, right? That could have 'illegal data'? Meaning that the only way to prevent 'illegal material' is to run a pruned node... that prunes op_returns and witness script that isn't necessary.

That would probably work, although there could be 'illegal data' inside fake public keys or unspendable addresses too (that's my understanding).

If the 'solution' is to restrict what transactions get relayed... then corporations could run "blocks only" and not have a mempool.

Then they could prune their node and ditch all the op_returns... but if they're doing that what is the point of knots?

What core is doing isn't a fork. It is backwards compatible.

Someone who runs Core 29 or 29.1 for example has to do 'nothing' and everything is forwards/backwards compatible.

Knots on the other hand by activating an anti-spam hard fork, is changing consensus rules and creating their own fork. That is the point of the write-up and what I was trying to address. Core is not proposing a fork

Makes sense

I used to think extremely well of Matt Kratter but he has completely gone off the deep end IMO.

Knots users say to 'run knots'. There are legions of them on Nostr and Youtube and Twitter although I suspect some of them are bots.

What happens when core 30 gets released? Well the degens will show up attracted to the very controversy that is being generated... and come up ways to 'gamble' on something in op_return it could be absolutely anything. A new NFT new crayon-drawing new token the possibilities are endless.

"Run Knots" which is effectively a relay policy could eventually shift to "become Knots"... our 'filtering' isn't effective and core won't budge. And once people are Running Core 30 it doesn't get un-released it's out there?

So influencers in the Knots space will eventually pivot to other solutions that invalidate the arbitrary data in blocks creating their own separate chain.

The ironic thing I think is that once they start 'invalidating' the blocks they will create more controversy... so the spammers will show up to the knots-chain too and find some way to speculate on something. Then I guess they hard-fork again? I don't know. The more you fork the more controversy the more spammers/etc.

If people don't speculate on your chain it means they don't care about it.

+1

I remember in some of the 'mega-discussions' posted by @Murch (which were awesome btw) what hard-fork would actually be required to permanently 'fix' the inscriptions and op_return issues. IE no inscriptions at all and no op_return at all which is datacarriersize=0? So that these things never propagate.

I have read about soft-fork proposals and more drastic hard-fork things... but it gets seriously in the weeds.

One thing I do believe is that there will be a fork eventually though Knots-users really really want it.

Interesting. Thank you for your perspective... I was with the understanding that covenants had been put on the 'back burner' for the time being.

If changing op_return size creates this kind of conflict imagine what a covenants soft-fork would do and that's why we haven't had one. Does larger op_returns mean covenants are more likely? My understanding is that covenants are additional spending conditions.

Not upgrading... would still be in lock-step/consensus with Core 30 right? So 'not upgrading' would be on the Core-Side.

Interesting. Thank you for your perspective

Joinmarket had a recent update that, from what I understand, fixed the orderbook to make it more complete, more accessible and more consistent. But honestly I don't know

Oh. My. Gosh

Not you specifically. You're a Stacker. The collective 'you' as in everybody

If it's so bad... then why is it so expensive? In my experience at least... the desirable places tend to be expensive. And the less-desirable... less so.

Know what I mean?