Liquid INV rate probably too low

[ajtowns]

https://github.com/ElementsProject/elements/blob/cfc10a5dd6c18db140dd1d1e94dfa8cad16bfe36/src/net_processing.cpp#LL136C1-L136C1

/** Maximum rate of inventory items to send per second.
 *  Limits the impact of low-fee transaction floods. */
static constexpr unsigned int INVENTORY_BROADCAST_PER_SECOND = 7;

Given liquid's higher block rate, this value should probably be higher (also probably true on Bitcoin itself) -- perhaps it should be coded as (4200 / consensusParams.nPowTargetSpacing) ?

[delta1]

Hey @ajtowns thank you for this suggestion. Do you have any suggestions for benchmarking this type of change?

[ajtowns]

I think the worst case scenario would be if you setup a block proposer node behind a single (bastion) full node (so that it doesn't have random things on the internet connecting to it), and you do that by having the block proposer node make an outbound connection to the bastion node. In the case the bastion node will treat the block proposer node as an inbound, and rate limit it to INVENTORY_BROADCAST_PER_SECOND on average.

You should be able to set up a demo of that scenario with regtest pretty easily: fire up the "bastion" node as normal but with a large mempool. Mine 200 blocks on the bastion node, and split the funds up so the bastion node has 30k confirmed utxos. Fire up the block producer node and sync it to the bastion node. Disconnect the two. Have the bastion node generate 30k txs. Have the bastion node start producing a block every minute. Reconnect the two nodes. Check if the bastion node is able to produce full blocks to clear out the backlog, or if it's rate limited and takes ~70 minutes to do so and is clearing its mempool each block despite not filling the block.

If the txs are confidential, they might use 1.33kvB per tx, which equates to about 12.5 tx/s with full blocks (1MvB/minute); if they're non-confidential, the might use closer to 400vB per tx, which equates to 41.6 tx/s with full blocks.