Should operators that care about block propagation speed block knots peers?

[DaveF]

Isn't it better to have as many nodes as possible? A lot of people in Bitcoin Knots (myself included) that found out how Core dealed with this whole thing to be the wrong way did not sign up for a hardfork adventure. As long as the Bitcoin Knots version is compatible with the original chain then that is yet another point of decentralization. I value as many full copies of the blockchain as possible in different jurisdictions and different parties to be the most valuable thing if we would make a ranking of what helps the blockchain to stay safe. If people want to run experiments of filtering transactions that's not a big deal compared to seeing less and less full nodes. I reckon incentivizing people by using assumevalid by default is a bigger problem than any of this.

Knots is no different from core.
All luke did was take core and make his own tweaks to it. So, unlike running other node software knots is at it's core just core with changes. No pun intended.

And very soon unless luke or someone does major work knots is going to be built from a version of core (29.x) that is no longer supported. since core and all of it's developers only support the current version which is going to be 32.x in a couple of months and 2 previous versions so 31.x and 30.x

So if some vulnerabilities are found in 29.x nothing is really going to be done to fix them from core's side. You will have to rely 100% on the knots team. Which as of now, according to github, is 1 person.

-Dave

[ABCbits]

Now, all you need, is asking a given peer about the hash of the 961,632 block in the heaviest chain. If someone considers 0000000000000000000169eb6f811ddbd0daf343af7b62180cdb13e7c78dbc16 to be a valid block, then it supports BIP-110, and can be disconnected. And if another node says it is 00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba, then it is non-BIP-110, and can be left as-is.

Well, I applied the ban using the user agent which was a planned thing long before the actual BIP-110 nonsense. Anyway, I would want to ban all user-agent Knots nodes regardless of whether they support BIP-110 or not. Later an advanced version of banning that works on misbehaving peers could be deployed but only if necessary. I wonder if Core could figure out another misbehavior filter and implement something directly.

Just like you can't truly stop spam/arbitrary data on blockchain, you can't truly stop Knots node connected to your node. Spoofing agent/name of the client isn't that hard. If you intent to ban by what kind of TX it would accept/relay, it could affect people who custom their Bitcoin Core setting or run different full node software.

Besides, i don't recall serious attempt to ban or stop other client/node that deemed as spy or fake node either.

I reckon incentivizing people by using assumevalid by default is a bigger problem than any of this.

Which part that you consider as bigger problem? Last time i checked, assumevalid only skip script check of TX on old blocks.