Upgrade to Pro — share decks privately, control downloads, hide ads and more …

XThin vs Compact Blocks

dagurval
September 25, 2016

XThin vs Compact Blocks

Slides from presentation given at:
"Satoshi’s Vision: Bitcoin Development & Scaling Conference" September 25, 2016

Westin St. Francis, San Francisco

dagurval

September 25, 2016
Tweet

Other Decks in Technology

Transcript

  1. 2 minute crash course in Compact Blocks … by comparing

    protocol basics. Asumes you understand xthins.
  2. This identifier conflict is OK! It’s a bit more work

    to support both. We only have to ignore one of BIP152 (Compact Blocks) requirements.
  3. Announcing support is different • Using service bit is good

    for locating peers. • XThin supporting nodes are scarce. • Compact block would benifit less, plenty of Core nodes.
  4. XThin sends a filter with a block request. Compact blocks

    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.
  5. XThin sends a filter with a block request. Compact blocks

    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.
  6. Encoding with hashes or indexes • XThin and Compact Blocks

    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
  7. Encoding with hashes or indexes • Transactions have a fixed

    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.
  8. Scalability • XThin can scale as is. • Compact Blocks

    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.
  9. Upgrading the protocol • XThin does not have a defined

    upgrade mechanism • Compact Blocks define a version in their handshake. • Nodes ignore Compact Block support if versions don’t match theirs.
  10. Segwit capability • Compact blocks bumps its version number. •

    Peers with version 2 get segwit serialized transactions. • XThin can also be made compatible with segwit by changing the serialization.
  11. Low latency relaying Pushing blocks is back in style! •

    Compact Blocks has a “high bandwith mode” • Similar to xpedited - both save a round trip
  12. Basic verification Send xthin block Block received Full verification Xpedited

    A Send Compact Block Block received Full verification Compact Blocks High bandwith mode A B B VS
  13. Low latency relaying Pushing blocks is back in style! •

    Compact Blocks requests announcements with blocks from 3 semi-arbitrary peers. • Xpedited is configured in bitcoin.conf
  14. How are hash collisions in mempool handled? • XThin falls

    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)
  15. My conclusion • There isn’t much difference. • Compact Blocks

    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.