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.