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

XThin vs Compact Blocks

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for dagurval 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

Avatar for dagurval

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.