does not • Filter represents the requesters mempool • Using a filter increases request by Average: ~5KB (BU) Protocol Max: 36KB. Prefill accuracy: XThin: ~1% re-request rate with 5KB filter. Compact Blocks: ~60% re-request rate with current algorithm. Big improvement potential.
does not Mempool policies: XThin benifits from similar mempool policies Compact Blocks requires similar mempool policies My opinion: • Having a filter is worth the extra bytes • Filter is more cross-client friendly.
both send list of 64bit hashes in a block. • Compact Blocks obfuscates them. • Compact Blocks adds index to prefilled txs. ◦ Saves: 1KB per 21 prefilled
position in the block. • Compact Blocks use this in re-requests. Savings: ~1KB per 21 txs re-requested. My opinion: • Using index is a good idea. • Compact Blocks encoding is needlessly complex.
gets issues when blocks have >= 2^16 transactions. (~38MB blocks with avg 0.6KB per tx. ~17MB with carefully crafted blocks) • Easy to fix by updating index to 32bit integer or with a hack.
back to requesting thicker blocks (256bit hashes) • Compact block explicitly re-requests the transactions that collided • XThin nodes can also use the re-request strategy (XT does)
is more complex to implement. • Compact Block manages to shave of some more bytes. • I doubt there will be performance difference. I hope someone does a performance comparison. • Overall both are good protocols.