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.