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.

[Satofan44]

... I wonder if Core could figure out another misbehavior filter and implement something directly...

That would create a perpetual game of whack-a-mole.
Core updates to block luke's scamcoin nodes and within the next update or two of his client he codes around it. Then sooner or later core updates again and we start the cycle again.

It doesn't really have to be the case, and it would not be hard. Misbehavior analysis can be effective enough to detect different kind of misbehavior, it is not supposed to be a single pattern-matching behavior.

Misbehavior filters can be useful when the dumb behavior is ignorance and not an intentional attack. -- no real wack a mole in that case.  Some of the victims of that scheme to launch a scamcoin are going to continue running older versions of knots for some time, and it would be good for the network if a reasonable number of nodes weren't being slowed down by them.

Exactly where I was trying to go with this, so instead of asking users to do it themselves I would want to see more misbehavior filtering being implemented directly in the software.

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.

While I do understand it from some perspective, I have seen this kind of argument used a bit to much on these parts, and often it is being used as a false reason not to do anything against certain types of topics.. The idea is not to try and ban 100% of Bitcoin Knots nodes, which would be aiming for a perfect result. The idea is to ban as many Bitcoin Knots nodes while using the least amount of effort and implementation complexity as possible. With what I have used this time, I have effectively banned 99% of current and future Bitcoin Knots nodes without even a full hour of work. I would call that a great success if a similar result is achieved for misbehaving peers. An impossibility to perfectly solve something should never be a reason to justify inaction. It took me some time to address this for various reasons, but now that it is up the problem is mostly resolved.

[DaveF]

Thinking about it a bit more, makes you wonder if a bit of it could be done with a service like the ones that spam blacklists.
You see a knots node connect to your node, your node blocks it and sends it's IP to a public list which keeps track of that IP
After a certain number of people report that IP it gets added to a list.

The other side is your node connects to that same service and can download that list and just block those IPs from the start.

Probably too much work, and too many ways to abuse it, and yes you would be giving up privacy. And a host of other issues I have not thought of.

But, still a thought.

-Dave

[ABCbits]

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.

While I do understand it from some perspective, I have seen this kind of argument used a bit to much on these parts, and often it is being used as a false reason not to do anything against certain types of topics.. The idea is not to try and ban 100% of Bitcoin Knots nodes, which would be aiming for a perfect result.
--snip--

In that case, banning by user agent is enough. People who use Knots as a way to voice or oppose against Bitcoin Core decision want to seen on nodes statistic. It's not kind of feature i believe should exist on Bitcoin Core itself, it should remain as external script that interact with Bitcoin Core.

Probably too much work, and too many ways to abuse it, and yes you would be giving up privacy. And a host of other issues I have not thought of.

With naive approach, you can easily block IP used by Tor exit node or commercial VPN by mistake.

[Cricktor]

...

I don't like this proposal as it's countering Bitcoin's and Core's design of a trustless and decentralized setup. A centralized nuts-node blacklist server doesn't fit that design philosophy.

It might work for clearnet nodes, but what about onion nodes that intentionally alter their onion circuits every now and then?

Knots crap will drive itself to irrelevance and likely a no-problem anymore. I'm fine to disconnect my nodes from Knotsies via user agent-fu. If Knotsies have to go the extra mile to hide they're foolish nodes, well, so be it. Either there'll be other indicators (and possibly some sort of whack-a-mole race) or they'll become such a minority that it's not worth it to take care of them.

I wonder how much "energy" is wasted because of this Knots bs.

[Satofan44]

...

I don't like this proposal as it's countering Bitcoin's and Core's design of a trustless and decentralized setup. A centralized nuts-node blacklist server doesn't fit that design philosophy.

It might work for clearnet nodes, but what about onion nodes that intentionally alter their onion circuits every now and then?

Knots crap will drive itself to irrelevance and likely a no-problem anymore. I'm fine to disconnect my nodes from Knotsies via user agent-fu. If Knotsies have to go the extra mile to hide they're foolish nodes, well, so be it. Either there'll be other indicators (and possibly some sort of whack-a-mole race) or they'll become such a minority that it's not worth it to take care of them.

I wonder how much "energy" is wasted because of this Knots bs.

An external service blacklist has nothing to do with Bitcoin's or Core's design, people already have various blacklists of different kinds. As long as it is not directly implemented in Core, it remains an opt-only idea for those that want to use it.  There is no reason to keep misbehaving or hostile peers connected to your own nodes. Why should I spend financial resources on such nodes? I'd rather spend my bandwidth and resources on good nodes, especially long-standing nodes. 

[DaveF]

...

I don't like this proposal as it's countering Bitcoin's and Core's design of a trustless and decentralized setup. A centralized nuts-node blacklist server doesn't fit that design philosophy.

It might work for clearnet nodes, but what about onion nodes that intentionally alter their onion circuits every now and then?

Knots crap will drive itself to irrelevance and likely a no-problem anymore. I'm fine to disconnect my nodes from Knotsies via user agent-fu. If Knotsies have to go the extra mile to hide they're foolish nodes, well, so be it. Either there'll be other indicators (and possibly some sort of whack-a-mole race) or they'll become such a minority that it's not worth it to take care of them.

I wonder how much "energy" is wasted because of this Knots bs.

An external service blacklist has nothing to do with Bitcoin's or Core's design, people already have various blacklists of different kinds. As long as it is not directly implemented in Core, it remains an opt-only idea for those that want to use it.  There is no reason to keep misbehaving or hostile peers connected to your own nodes. Why should I spend financial resources on such nodes? I'd rather spend my bandwidth and resources on good nodes, especially long-standing nodes. 

Exactly, I can see the way I wrote it being interpreted as being part of the app itself. But, I was thinking more along the lines of a front end filter like a lot of mail servers / web servers use. Kind of like cloudflare / bad bot IP blacklists but for BTC nodes.

As I said, probably not that practical, causes loss of privacy, and a host of others issues would have to be worked out.

But, a fair talking point in this thread at least IMO.

-Dave