Context
BTQ-Core is a Bitcoin Core 26.0 fork. Blocks are 8 MB / 8 MW. Dilithium witnesses make each transaction much larger than an ECDSA one, so a "full" block is hundreds to low-thousands of txs, not a few thousand tiny ones.
Compact blocks (BIP152) send a short id per tx, not the whole block. The receiver rebuilds from its mempool. If a short id is missing, it asks for that tx (getblocktxn) or falls back to a full download.
There is a small side pool of non-mempool txs used only for that rebuild: recent orphans, replacements, and rejects. Bitcoin sized it at 100. That matched a world where a block was ~2–3k small txs and you already had most of them in the mempool.
What is wrong today
DEFAULT_BLOCK_RECONSTRUCTION_EXTRA_TXN is 100.
An 8 MB Dilithium block that you just saw as mempool traffic can still miss more than 100 of those extras (replaced parents, orphans that landed, a tx you rejected then saw again). 100 misses is how you stop reconstructing and request the body. On a 60-second block time, that download has to finish before the next block.
What to change
- Default the extra pool to 2000.
- Same structure. Do not invent a new index in this issue.
-blockreconstructionextratxn=100 must still start, for operators who want the old cap.
Measure miss rate on a near-full Dilithium block before arguing 2000 vs 5000. This issue is the default.
Check
p2p_compactblocks.py.- Two nodes that already have the mempool: a near-full Dilithium block reconstructs without
getblocktxn for txs they already had.
-blockreconstructionextratxn=100 still starts.
PR: #191
Context
BTQ-Core is a Bitcoin Core 26.0 fork. Blocks are 8 MB / 8 MW. Dilithium witnesses make each transaction much larger than an ECDSA one, so a "full" block is hundreds to low-thousands of txs, not a few thousand tiny ones.
Compact blocks (BIP152) send a short id per tx, not the whole block. The receiver rebuilds from its mempool. If a short id is missing, it asks for that tx (
getblocktxn) or falls back to a full download.There is a small side pool of non-mempool txs used only for that rebuild: recent orphans, replacements, and rejects. Bitcoin sized it at 100. That matched a world where a block was ~2–3k small txs and you already had most of them in the mempool.
What is wrong today
DEFAULT_BLOCK_RECONSTRUCTION_EXTRA_TXNis 100.An 8 MB Dilithium block that you just saw as mempool traffic can still miss more than 100 of those extras (replaced parents, orphans that landed, a tx you rejected then saw again). 100 misses is how you stop reconstructing and request the body. On a 60-second block time, that download has to finish before the next block.
What to change
-blockreconstructionextratxn=100must still start, for operators who want the old cap.Measure miss rate on a near-full Dilithium block before arguing 2000 vs 5000. This issue is the default.
Check
p2p_compactblocks.py.getblocktxnfor txs they already had.-blockreconstructionextratxn=100still starts.PR: #191