-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Liquid INV rate probably too low #1243
Comments
Hey @ajtowns thank you for this suggestion. Do you have any suggestions for benchmarking this type of change? |
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 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. |
https://github.com/ElementsProject/elements/blob/cfc10a5dd6c18db140dd1d1e94dfa8cad16bfe36/src/net_processing.cpp#LL136C1-L136C1
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)
?The text was updated successfully, but these errors were encountered: