Bitcoin Lightning Privacy: Routing Analysis

We’re meeting tonight to discuss the Routing Analysis chapter of Lightning Privacy Research. Here are some notes to help prepare you for the discussion!

NOTE: This is just Stephen sharing his notes with you and not actually a well thought-out or spellchecked instructional plan. 🙃

Lightning Privacy Introduction

  • Bitcoin Layer 1 – all TXes visible on a public blockchain
  • Lightning (Layer 2) – No central ledger, peer-to-peer


  • When a LN payment is associated with a BTC TX
  • P2P LN nodes know certain payment details
  • Highly connected LN nodes see a larger percent of network

❓ Questions

What is an anonymity set?

Routing Analysis

  • LN uses onion routing for a certain amount of source and destination privacy

❓ Questions

How is LN onion routing similar to TOR? How is it different?

  • Problem statement – there’s situations where the sender and receiver can be learned by routing nodes
    • Some scenarios allow routers to infer this info
    • A single actor controlling multiple nodes can correlate payment info

❓ Questions

What is an LSP? How might using an LSP affect privacy?

  • HTLCs – using the same payment hash each time can affect privacy
  • Wormhole attack – allows dishonest users to steal routing fees from honest users along a payment path – outlined in this paper:
    • Basically, 2 malicious nodes (Mike and Mallory) are on the same payment route and collaborate
    • Normal behavior: nodes pass the preimage back to the prior node to unwind HTLCs
    • Evil behavior: Mike passes preimage back to Mallory, skipping all the nodes in between, and M & M take the routing fees of every node that was skipped
  • PTLCs might fix this
  • Timing delays – basically, estimating how far away source of destination of a payment is by how long it takes to settle
    • Top nodes can perform timing analysis on the majority of payments
    • What if you run multiple nodes, and you route a payment for amount X, and then milliseconds later your other nodes routes a payment for slightly less than amount X.
    • What if average payment time between your node and neighbor is 100ms? If you route a payment to tyour neighbor and the HTLC or PTLC is fulfilled in about 100ms, you can assume your neighbor was the final hop.

❓ Questions

Should nodes add a random delay to fix timing analysis? It must be 2-3x delay to be meaningful, but does this affect usability of the LN? (See Peter Todd’s comment on opting into slower payments for the sake of privacy)

  • Random delay could be neat, but isn’t enforceable
  • MPP – Multipath payments
  • Randomize them to improve them
  • Multipath improves privacy
  • Randomizing the multipath and multiple shards to each node improves further
  • Splinter payments – MPP initiates midway through route
  • Splinter is theoretical atm
    • Protocol change needed?
    • Can splintering be enforced?
  • Longer paths?
    • 6 degress of sep
    • Go beyond 9 hops
  • Analyzing multipath payments
    • Less info can be gleaned (dont know full payment amount)
    • Anonymity set increases if more folks use MPP
      • Thought to self: reminds of CoinJoins in a way. Could people route MPPs with preset denominations to improve privacy?

❓ Questions

  • What are positives for implementing the author’s suggestions?
  • What are negatives for these suggestions?
  • Implementation notes
    • PTLCs – no progress has been made since taproot softfork
    • Timing delays – no active work being done to the knowledge of the authors
    • MPP is possible today. Splintering has not been discussed before.