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