Probing & Privacy 探測與隱私

Balance Probing:

Attacker wants to know Alice-Bob channel balance distribution

Method: Send intentionally failing payments

  Attacker -> ... -> Alice -> Bob -> non-existent destination

  Using wrong payment_hash, payment will definitely fail.
  But the failure location reveals information!

Probing Process:
  1. Send 1 BTC probe payment
     -> Fails: TEMPORARY_CHANNEL_FAILURE (Alice->Bob insufficient)
     -> Conclusion: Alice's balance < 1 BTC

  2. Send 0.5 BTC probe payment
     -> Fails: UNKNOWN_PAYMENT_HASH (reached destination, then failed)
     -> Conclusion: Alice's balance >= 0.5 BTC

  3. Send 0.75 BTC...
     -> Continue binary search

  4. After ~10 probes
     -> Know exact balance to sat level!

Problems:
  - Completely free (failed payments have no fee)
  - Hard to prevent (looks like normal failures)
  - Can be done at scale

Payment Correlation Attack:

HTLCs use same payment_hash across hops:

A -> B -> C -> D
     |        |
     +--------+-- same payment_hash

If attacker controls B and D:

  B sees: from A, hash=abc123, amount=100k
  D sees: to ?, hash=abc123, amount=99k (minus fees)

  Correlation! Same payment.
  Knows: A is paying someone after D
  Amount: ~100k sats

Worse case: First and last node control
If attacker controls A and D's counterparties:
  - Knows exact sender identity
  - Knows exact receiver identity
  - Knows exact amount
  - Complete de-anonymization!

PTLCs Solution:
Use different points instead of same hash:
  A -> B: point_AB
  B -> C: point_BC (different!)
  C -> D: point_CD (different!)

Cannot correlate payments via point

Timing Analysis:

Attacker can correlate payments via timing:

Scenario: Attacker controls nodes near entry and exit

Entry time: T0
Intermediate delay: ~100ms (network latency)
Exit time: T0 + ~100ms

If at T0 there's only one inbound HTLC,
and at T0+100ms only one matching outbound HTLC,
-> Very likely the same payment

Mitigations:
  - Add random delays (but increases payment time)
  - Batch HTLC processing (high complexity)
  - Use Tor for network layer anonymity

Path Length Inference:
CLTV timelock decrement reveals path position:
  - Entry node sees large CLTV
  - Exit node sees small CLTV
  - Difference / delta = approximate hop count

Balance Probing Defense Methods:

1. Shadow Routing
   - Add fake hops after real path
   - CLTV appears longer
   - Hard to determine real destination

2. Randomized Errors
   - Return failure even with sufficient balance
   - Increases probing uncertainty
   - But affects normal payment success rate

3. Fee Rate Limiting
   - Limit frequency of failed payments
   - Slows down probing
   - Need to balance normal usage

4. Minimum HTLC Setting
   - Set higher minimum value
   - Reduces precise probing ability
   - But limits small payments

5. Regular Rebalancing
   - Actively change balance distribution
   - Probe results quickly outdated
   - Has cost

Reality:
  Currently no perfect probing defense exists.
  Best strategy is to accept some balance leakage
  and use private channels to reduce probeable channels.

Privacy Asymmetry:

Sender Privacy (better):
  - Chooses path, controls more info
  - Can choose which nodes to route through
  - Receiver doesn't know sender identity (unless in invoice)
  - Can use Trampoline to reduce exposure

Receiver Privacy (worse):
  - Must provide contact method (invoice/BOLT12)
  - Route hints leak private channel info
  - Node ID is prerequisite to receive payments
  - Sender knows at least the last hop

Route Blinding Improves Receiver Privacy:
  - Hides real node ID
  - Hides last few hops of path
  - Sender only knows entry point

Best Practices:
  - Sender: Use multi-hop paths, avoid direct connection
  - Receiver: Use Route Blinding + private channels
  - Both: Use Tor, periodically rotate nodes/channels