) is a relatively simple code change, but it has important implications for BCH's UX and scalability.
tl;dr: BCHN will now by default relay transactions 10x faster than before. This will make BCHN's transaction relay much faster than ABC, though not as fast as BU. On the flip side, BCHN will require more bandwidth than ABC at low transaction throughput rates, but less than BU. BCHN has also added the `-txbroadcastinterval` command-line option to allow node operators to configure this behavior more precisely.
# Background on `inv` message batching
The inv messages for transactions are responsible for the vast majority of a node's total network traffic, since inv messages are sent per peer regardless of whether that peer needs the transaction or not. If a node is sending one inv per tx per peer, and the node has 50 peers, that results in about `120 bytes/tx/peer * 50 peers = 6000 bytes` of network traffic per transaction, or roughly 6x as much traffic as is required for receiving and sending the transaction itself (assuming a typical 500 byte transaction). In this scenario, about 2/3 of the traffic is actually protocol overhead -- mostly TCP/IP overhead, but also bitcoin p2p protocol overhead. This overhead can be mitigated with batching. Using IPv4, inv messages take up about `80 + 40n` bytes per message, where n is the number of transaction hashes being sent. This means that batching behavior can reduce the average traffic per peer per tx from around 120 bytes (for a batch size of 1) to around 44 bytes (for a batch size of 10). The way to achieve large batch sizes is to have a wait time before sending each tx inv to allow extra txs to be ready in each transmission. A batch size of 10 can be achieved with 20 tx/sec and an average wait time of 2 sec, for example.
If the wait time is mismatched with the transaction throughput rate, it can result in an increase in transaction propag...