Luke is a very experienced, although controversial, Core developer who has a few other respected anti-spam Core devs involved who can keep him honest, but he is the only one who can accept Knots code changes as a “maintainer” AFAIK.
Core has the appearance of being decentralized with around 10 maintainers IIRC but many of the prominent full time Core devs have the same funding sources and so are not as decentralized as things may appear. Some of them also get free office space from Chaincode labs, so they hang out there together. This increases the risk of group-think.
Knots benefits from the work of the many Core devs all over the world who test and submit code because it’s based on Core source code. Knots is slightly different to Core though because it includes code that filters most of the spam we can identify (runes/ordinals/etc) and there are other philosophical/stylistic changes Luke has made to the code like limiting the OP_RETURN default to 42 bytes because that’s what it was in Bitcoin for a long time - and Knots allows you to change that limit in the Bitcoin.conf config file on the node if you want.
It’s quite unacceptable to me that Core chose not to attempt to filter spam. Filtering runes is one line of code that checks if the OP_RETURN data starts with the number 13 - because that’s how the Runes code finds runes data in the Bitcoin blockchain. Sure, Runes could change that in future, and Core would then need to add another line of code to filter the new approach and this would happen periodically with new releases of Core, but eventually spammers will grow tired of their code breaking because of node filter updates and move to Ethereum where they are welcome. Bitcoin Core node filter policy code could also be easily separated from consensus rule validation code and all the other node code to allow new policies that fight spam to be safely updated and released very quickly without risking a chain split by accidentally breaking consensus rule code.
Knots takes the approach that filtering spam takes effort but is possible and worthwhile. Core v30 accepts that Bitcoin will be used as an arbitrary data storage layer. The OP_RETURN change in Core v30 was argued about at least 3 separate times since Lopp was paid $1000 to propose it in 2023 and it was rejected twice before getting pushed through this time. There’s lots of technical nuance to the arguments but this note is already too long!
In summary, I’m an experienced C++ developer and I did the work to understand the technical/security/legal/philosophical arguments, read the Core dev discussion threads to understand the arguments, compared the Core and Knots policy source code line-by-line and I then switched from Core to Knots. If Luke ever adds anything crazy into Knots, I can stay on an older version of Knots or do the work to modify the Knots or Core source code to remove the crazy stuff. Hopefully I will be able to just stick to Knots. And hopefully Core will pivot towards filtering spam, so I could consider running a future version of Core.
I suggest you stay on an older version of Core and not upgrade to v30 - or switch to Knots if you want to send a clear message to the Core devs that you believe Bitcoin is money not storage.
You should (obviously) do your own proof-of-work and reach your own conclusions.
