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

[gmaxwell]

As many people are aware, the Knots implementation of Bitcoin is planning on forking off about 60 days from now over their desire to impose restrictions on Bitcoin Script in order to make their efforts to filter other people's transactions more effective.

So at that point you'll presumably want to disconnect any knots peers as they'll just be a useless waste of bandwidth... but it turns out there may be good reason to do so sooner rather than later:

Because of Knots longstanding dedication to playing god over other users transactions knots nodes already reject a significant fraction of transactions that ultimately get mined.  This means that when a block gets found and your node should be working as fast as it can to help spread it to unify the network on a single chaintip and eliminate advantages for larger hashpower consolidations over smaller miners ... if you have knots peers your nodes time will be wasted catching them up to what they already should have learned on the network.

If you look at the peerinfo for knots peers you'll find that bytessent_per_msg.blocktxn and bytesrecv_per_msg.getblocktxn are likely to be significantly greater than Bitcoin Core 0.3x peers which have been connected for the same amount of time.

On two different nodes I have access to I see:


Summary Group                            | Peers Included | Avg bytessent_per_msg.blocktxn Bytes/Sec
-------------------------------------------------------------------------------------
All /Satoshi:3* Nodes                    | 61             | 1.744407                
All *Knots* Nodes                        | 14             | 86.426688                



Summary Group                            | Peers Included | Avg bytessent_per_msg.blocktxn Bytes/Sec
-------------------------------------------------------------------------------------
All /Satoshi:3* Nodes                    | 36             | 18.738560                
All *Knots* Nodes                        | 13             | 339.347537              


So I'm seeing knots peers using 50 and 18 times the at-blocktime bandwidth compared to other current software.

If you're running a node optimized to speed up network wide block propagation, it might make sense to limit the number of Knots peers you accept, even today.  Blocking them entirely would come with some theoretical forking risk though it would only be a concern if practically everyone did it, which seems unlikely to say the least.  But if you want to behave more safely, limiting yourself to one or two at most would eliminate even that risk (well, up until the point they fork themselves) without wasting as much resources at the critical time of new block discovery.

[ABCbits]

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.

[DaveF]

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

[satscraper]

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.

[gmaxwell]

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".

[ABCbits]

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.

I think few people intentionally enable it to furthermore reduce bandwidth usage.

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.

Isn't it the default behavior? The syncing node can't verify the TX actually use valid and unspent UTXO.

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.

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.

[Satofan44]

If you're running a node optimized to speed up network wide block propagation, it might make sense to limit the number of Knots peers you accept, even today.  Blocking them entirely would come with some theoretical forking risk though it would only be a concern if practically everyone did it, which seems unlikely to say the least.  But if you want to behave more safely, limiting yourself to one or two at most would eliminate even that risk (well, up until the point they fork themselves) without wasting as much resources at the critical time of new block discovery.

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.

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.

I think few people intentionally enable it to furthermore reduce bandwidth usage.

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.

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.

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?

[nc50lc]

-snip- 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.

[ercewubam]

Code:

if "Knots" in user_agent:

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.

"Straight-forward" as in no code changes?

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.

Code:

bitcoin-cli getpeerinfo | jq -r '.[] | select(.subver | test("Knots")) | .addr' | while read addr; do
  ip=$(echo $addr | cut -d':' -f1)
  bitcoin-cli setban "$ip" add
done

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.

Code:

== Network ==
addnode "node" "command" ( v2transport )
clearbanned
disconnectnode ( "address" nodeid )
getaddednodeinfo ( "node" )
getaddrmaninfo
getconnectioncount
getnettotals
getnetworkinfo
getnodeaddresses ( count "network" )
getpeerinfo
listbanned
ping
setban "subnet" "command" ( bantime absolute )
setnetworkactive state

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.

[gmaxwell]

straight forward way to block all or most of them to the public?

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()

[Satofan44]

-snip- 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.

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.

Code:

if "Knots" in user_agent:

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.

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).

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.

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.

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."

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.

[gmaxwell]

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.

[Satofan44]

I finally got around to doing this as I was accumulating connections over several updates and restarts. Anyway there was no rushed given that there are very few users on this forum that run nodes (probably there are more readers that do) given that they just farm money for shitposting.

I used some simple scripting stuff with AI that uses the normal CLI to ban Knots based on the subversion only for now. For this kind of low-level stuff an LLM can do it easily, and then the only thing that is necessary to put it on a schedule. Keep in mind to remember that it may default to ipv4 handling, and you may need to explicitly tell it to include ipv6 and onion nodes (of which there were only 3 in my connection list). Weekly repetition is sufficient but daily is also good if one wants to be aggressive. So here is the data that I have as of now, which is in a way good timing as well because it comes after their scam fork attempt:

Knots Peers: 37 / 390, representing 9% of the total connections.

After the ban:

Knots Peers: 0 / 353, representing 0% of the total connections.

I don't think it necessary that advanced solutions focusing on misbehavior are yet necessary, I think the Knots scammers will continue to lose relevance and possibly go away on their own. Should someone observe an increase in misbehaving nodes or nodes that are hiding the Knots subversion then I'll post an AI-version ready-to-use for the public.

[athanred]

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.

[gmaxwell]

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.

Approximately all knots peers are broken wrt causing block propagation load... the 110 stuff should disconnect itself due to "invalid blocks".  But the non-110 knots are still probably better off being disconnected for performance reasons per my original post.

[Satofan44]

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.

man i just run a node and hope it works lol. didn't know knots were this greedy. respect for crunching the numbers. good looking out.

Your data is going to depend a lot on your own node, this is why there is some oscillation between knots numbers between users but also because their sibyl attack fluctuates a lot over time.

Approximately all knots peers are broken wrt causing block propagation load... the 110 stuff should disconnect itself due to "invalid blocks".  But the non-110 knots are still probably better off being disconnected for performance reasons per my original post.

That was my idea, even user agent is simple enough for more people. I highly doubt that there are more than a few Knots nodes hiding under false user agents (for now).

[DaveF]

... 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.

With them forking off to a new algorithm in less then a couple of weeks, except for dealing with some other crap it's not going to matter to much. They are going to disconnect themselves.

Probably going to be entertaining to watch what happens during the 1st couple of weeks of September, but outside of replying to posts here about it I am not really looking at it that hard anymore. They failed, they have decided to go away. knots is just going to be another altcoin fork.

-Dave

[gmaxwell]

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.

[takuma sato]

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.