Should nodes focused on block propagation speed cut ties with Knots peers?

So, as many know, the Knots version of Bitcoin is set to fork in about 60 days because they want to put limits on Bitcoin Script to better filter transactions from other users. When that fork happens, you’ll probably want to cut off any Knots peers since they’ll just be wasting your bandwidth. But honestly, it might be a smart move to do that even before the fork: Knots has a long history of interfering with other users’ transactions. Their nodes already reject a good chunk of transactions that do end up being mined. So when a block is found, your node should really be working as fast as possible to spread it out and help everyone get on the same chaintip, which keeps smaller miners competitive against the bigger ones. If you’re still connected to Knots peers, your node will just waste time bringing them up to speed on stuff they should already know. If you check the peerinfo for Knots peers, you'll see that the bytes sent per message for block transactions and bytes received per message for getting block transactions are usually way higher than what you’d see with Bitcoin Core peers that have been online for the same time. On two different nodes I’ve got access to, here’s what I see: Summary Group                            | Peers Included | Avg bytes sent per msg for block transactions (Bytes/Sec) All /Satoshi:3* Nodes                    | 61             | 1.744407                 All *Knots* Nodes

By any chance, do you have any data for node group that enable blocksonly mode? If the average bytes is barely different with Knots node group, it means compact block have no benefit when connected to Knots node.

Block all of the knots nodes. You know my view on this. And unless someone really wants to go though and do a diff on lukes code when he releases the next knots update who knows what it really does. So why take the risk. As someone, perhaps even you pointed out to me a while ago, luke was taken out of the DNS seeds. So yeah, take him out of everything. -Dave

I don't think there are many such nodes, as blocksonly mode undermines privacy by making them detectable among other nodes, because if they broadcast their own transactions, the origin becomes obvious. The best way to hide something is to conceal it among similar things, rather than to differentiate it from them. That said, in my view blocksonly mode might make sense and therefore be enabled just for IBD, then removed from bitcoin.conf once the node is fully synced.

When a node has no mempool content it doesn't attempt to use compact blocks... so it'll not show up in these figures. I think I have had very few blockonly peers.  You might notice you have some fRelay=false peers, but those are almost all from the the two blocksonly connections each node makes. (because addr messages and txn can be used by attackers to learn the network topology and most of the costs of having connections is the datastructures used to track who knows which transactions each node makes two extra outbound connections that only relay blocks, so there is always a portion of network topology that attackers can't easily learn). It's an interesting question to know what percentage of the block those knots peers are requesting, I think I could extract that from the logs.  I suspect they still get a good improvement from compact blocks, but it's something like half the block they're missing. But now that you bring up blocksonly peers -- it might be a reasonable feature to intentionally delay replies to bare getblock requests when you've sent out hb compact blocks until a second or two later.  By the same token, peers that send huge getblocktxn could be treated similarly.  They're never going to be on the fast path for the block so a little delay won't hurt.  The trick is that if *everyone* missed transactions, you don't want to add delays.  So I think it would basically be "if the peer missed many transactions that you didn't miss, and you've got any peers in HB mode, delay replying slightly to give your fast peers a chance".

I think few people intentionally enable it to furthermore reduce bandwidth usage. Isn't it the default behavior? The syncing node can't verify the TX actually use valid and unspent UTXO. Half sounds plausible. https://thebitcoinportal.com/live/spam/overview says 57.5% TX count considered as non-monetary in last 7 days. I know it's biased/inaccurate data, but it probably align with kind of TX not relayed by Knots node.

That seems extremely unlikely at this point of time. I haven't checked this data myself but I have plenty of connections to Bitcoin Knots nodes last time I checked so this does have a big impact on me. It was around 15% or something if I remember correctly, and since I have hundreds of connections this is a big drain on the resources. You can just submit the transactions through a third party location/service while obfuscating yourself whether through VPNs or TOR, the issue of "privacy" is easily solved -- nobody is going to look any deeper into it usually. It is a great mode that has a very good purpose as you have mentioned, some users need it. It would explain a good portion of the difference in bandwidth usage if they are blocking all of those transactions. The answer is already YES. I would like to block them on my node, I don't need these useless leeches taking this precious bandwidth. Has anyone provided the most straight forward way to block all or most of them to the public?

"Straight-forward" as in no code changes? There's this Github repository that's providing a banlist file which is compiled using bitnodes. But since Bitnodes is now inaccessible, it hasn't been updated since April. Here's the link anyways: github.com/aeonBTC/Knots-Banlist There's a script in the issues tab as an alternative.

This can easily result in banning peers, which you don't want to ban, or not banning those, who you want to target. A better idea would be to observe the traffic, and make decisions, based on that. Which means banning the client, regardless of the User Agent, just if it consumes too much resources. Probably the easiest way is to use RPC commands, to measure some things, and then make an external script, which will execute RPC commands on given peers. Again, it would help only for a while, but users can change their User Agent as they wish, and then, blocking next peers will be harder, if they will do that. This is what can be easily used. And I guess it should be enough, to get the amount of bytes, sent or received by a given node, and then ban some of them, which use too much resources.

Go to your favorite LLM and say "Write a python script that connects to the bitcoin core RPC using cookie authentication without using any non-standard python libraries.  The script should run getpeerinfo and find all the peers that contain Knots in their subver.  Then it should call disconnect node on each one of them. Then it should display ascii art of luke-jr crying." then just run that in a loop every couple minutes.  SOTA models will one shot this, less powerful ones may need to iterate a little on errors in the first try.  I'm not providing the output because you should all be able to do this on your own. While not the most straightforward the same approach can be used to do a lot of simple tasks like this. When you are successful at using AI to improve your node's performance and your personal autonomy, post your AI's crying luke-jr code: Qwen-3.6-27B (it went and found a picture of him online) def lukejr_crying():     print()     print("  luke-jr is crying because you disconnected all his Knots peers:")     print()     # ASCII art from Luke Dashjr's actual X/Twitter profile photo     # with tear effects added     art = r"""       |#%#+=**#%****#%#*#+*#*+**+-==++*++***=#**********#@@@@@@@@%%       |###+=**#%++*##%**#++#***+*=-+++=:-=+#=***********#@@@@@@@@@@       |**#++***%+*=*%%**#+*#**#++==+==*+****+=--==+****+#@@@@@@@@@@       |**#++**##+*=*%#++#++#**#*++++*#%%%####*+=--===**=#@@@@@@@@@@       |++#+=++##=+=*%#+*#++#*****###%%%%%@@%%%#*+====**+%@@@@@@@@@@       |++#+=+=*#=*+#%*+##++#++####%###%%%%%%%%%#*+-==*++%@@@@@@@@@@       |+*#+===##=+*#%*+##++*+#%%%#%%%%%%%%%%%%%%#*===*++%@@@@@@@@@@       |=*#=+++##=++%#*+##+**#%%%%%%%####%%%%%%####*==***%@@@@@@@@@@       |+*#=+++#*=+*%#+**#*#%%%%%%%##*****##%%%%%%##+=*+*%@@@@@@@@%%       |+**=+++#*==*%*+***#%%%%%%%#*+++++++*##%%%%%#*+***%@@@@@@@@%#       |=**=+++**=+#%+++#*%%%%%%%%#+=======+*####%%%#+=+*%@@@%%%%@%%       |=**=+++**=+%#+++*#%%%%%%%#*=====-====+*##%%%#*+=*%@%#%%%%%%%       |##*=+**#*=*%#+++##%%%%%%##*============+*#%%##**+%%##%%#%%%#      |#**==+*#*=*%*+++##%%%%%%#*+=========---=++*#*##*+%%#%%##%%%%%       |***===+**=##*+==*%%@%%%%#**==========---===++#*++%@%%%##%%#%       |*#*====+*=%#*+==#%@@%%%##*+===========---===+*+=+%@@%##%#%%%       |**++++==++%**+==#%@%%%%##*+===========---====++==%@@%####%%%       |+*+-==+++#%+++=*#%%%%%%#+============----==--+*=+%@@%%%%%%%%       |+*+----==%#+====*%%%%%#*===================--=#+*%@%%%%@@%#%       |+*=-----=%#=++=-+%%%%#*+====+++*++=======----=*=+%@%%%%%%%#*       |**+==---+%*-===+++#%%#*==+++****###*++======-=*=*%@%%%%%%##*       |+======-##=---=##++###+==++*#**##%%##*+=====-=+=+%%%%%%#%##*       |----===+%#=---+*+++##*+===+*##%@##%##*+++***+++-+%%%%%%##+*=       |----=-=*%*====++++*#*++====+***%++##*+=+#%%%#*+=*%%%%%%+=**+       |------=*%*+===+++*#**+=====+++*++****=-+%@%#**==*++###*-+**=       |+==--==##*=-===++*+++=======+++****++=-=#@#*#+=======+=-+*#=       |+++++++%*+-----=+*=+===+=======+++======**++*=======-=+*%*++       |====++#%+=-=+====+++===+================+**+=------+++*#%#%#       |-=-===%#==-=***===+===++==========+======++==+*#**#@%%%%%%%%       |-----=%#-=:-#%%+==+====+=========++=========-#@%%%%@%@@%%%%%       |..:--+%+-=--+++#*+=====++=======+*++++=======%#*%%%%%@@%%%%%       |.::--##=-=-====**++===++=======+++*###*++====%+=*#**@%%%%%%%       |----=%#-==-==--**=+++=========++==*#####*+===%*++%##@%@@%%%%       |*#*+*%*-=++*****+=++++=======++=+*##%###+===+%*+-++#@+*####*       |***=##=-=%%%@@@%==+++++++======+*#####%#*===*%#+=++#@%###%%@       |**++%#--#@%@@@@%==++++++++====+*######%%#+=+%%#+===#@@****#@       |**+*%*-=%@@%@@@#==+**++++++==+*###%##%%%#*=*%#%###*%@%+*#*%@       |**+#%*#%@@@@%@@*==+**++++++=+*###*****#%#*+*%#%%%%%@%**#%%%@       |***##%@@@@@@@@%+==+**++++++++********+*#%#+*%#%%%%%%@**#%%%@       |***%%@@@@@@@@@#+==++***++******+++*#**+*#*++%#%%%%%@@***#@@@       |**#%@@@@@@@@@@%*+=++********#*+++++**+=+#*++##*%%@#%%###%%%%       |**%@@@@@@@@@@@@%+=++*#########*+===+++=+****#%*%%@#*=+==+++#       |**%@@@@@@@@@@@@@#++*#%%%%%%####*++++++++**#%#%*#%@@*++==++*%       |*#%@@@@@@@@@@@@@@*++#%%%%%%##%##**++*++***#%#%*#%@@+++==+**%       |%%@@@@@@@@@@@@@@@%*+*%%%%%%##%####********#%%%%#%@@+==+#@@@%       |@@@@@@@@@@@@@@@@@@%**#%%%%%%%%#####**#*****#%%%%%%%*=+#####%       |@@@@@@@@@@@@@@@@@@@%*#%%%%%%%%#%######******##@%%%%*+*%@@%#%       |@@@@@@@@@@@@@@@@@@@@%#%%%%%%%%%%%#######******%%%%%#*+%@%#%#       |@@@@@@@@@@@@@@@@@@@@@%%%%%%%%%%%%%%%#####**+**%@%#%%#*######       |@@@@@@@@@@@@@@@@@@@@@@%%%%%%%%#%%%%%%######*+*%%%##****#%%##       |@@@@@@@@@@@@@@@@@@@@@@@%%%%%%##%%%%%%#%#####**#%###******###       |@@@@@@@@@@@@@@@@@@@@@@@@@%%%%%%%%%%%%%%####%%##%%##*#****%%%       |@@@@@@@@@@@@@@@@@@@@@@@@@%%%%%%%%%%%%%%%##%%%%%##*####***%%%       |@@@@@@@@@@@@@@@@@@@@@@@@@@%%%%%%%%%%%%%%%%%%%%%%******#**###       |@@@@@@@@@@@@@@@@@@@@@@@@@@@%%%%%%%%%@%%%%%@@@%%@@***********       |@@@@@@@@@@@@@@@@@@@@@@@@@@@@%%%%%%%%@%%%%%@@@%@@@%#**####*##       |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@%@%@@%@%%%@@@@@%@@@@%#########       |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@%%@@@@@@@@@@%%%%%%%%%%       |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@%@@@@@@@@@@@@@%%%##*++       |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@%++++++=     """     print(art)     print()     # Add tears     tears = """         :   .   :     .   :   .     :   .          .  :    .  :    .    :  .    :   .            :   .     :    .   :     .   :         .    :  .    :    .  :   .   :    .            .    :  .    :    .   :   .    :     """     print(tears)     print("    ...my poor Knots...")     print()

Yes, in terms of straight-forward I am also looking for ways to make it as newbie-friendly as possible. We have quite a fair number of node runners that are not that technologically competent, and it would be nice to be able to provide them some easy ways to ban Knots nodes. Nice share, perhaps this could be a small project for someone on the forum to maintain a Knots banlist and refresh it. It is unfortunate that Bitnodes is not accessible anymore. If we want to be objective on this level, don't we need to establish a good baseline then in order to define what is "too much"? In extreme cases it is clear, if a one node uses X amount and another 1000 times X then it is simple. But what about 25% more than X? I'd need to establish some sort of baseline to compare it fairly to catch most of them without creating too many false positives (I don't want to ban some normal node simply because it uses a little bit more than the average). They can, but they fall into a trap with that. My observations: 1. In no case will all Knots users do this, perhaps not even the majority. 2. If they do this on a mass scale, they lose their sybil attack of fake nodes that is misrepresenting their support. They could claim that nodes with changes or empty user agents are Knots, but that has a much less manipulative effect. 3. Let them do it, since their nodes have a clear behavioral signature that makes them mostly distinct from Core nodes it will be easy. They would have to implement changes similar to Core in order to minimize this discrepancy and to be able to hide within user agents. Nevertheless I appreciate the thoughts and it would be worthwhile to work on this after deploying the easier solution first, because even in absence of the banning some peers may have already changes their node information. This is a work of art, just beautiful.  I'll post an update once I try one of these and give some basic data changes. I could even post a list of the peers that I have identified and banned. Thanks to all 3 of your for the various ideas and different approaches. I will try something out soon and see what happens to my number of connections and data usage.

funny timing, this thread gets traffic and a knots user considers testing for once: https://github.com/bitcoinknots/bitcoin/issues/312 Unsurprising it's been three days and there hasn't been a response-- they've mistaken Knots for a software project rather than one delusional man's power fantasy.