• 1. First, you need a channel
  • Public channel
  • Private channel
  • Private Taproot channel
• 2. Now suppose you want to move the money to cold storage
  • Unique amounts are dangerous
  • What helps?
• 3. What happens when you receive money?
  • SCID aliases help
• 4. Blinded paths improve the receiving side
• 5. What about when you pay somebody?
  • But your first peer is special
• 6. Does MPP fix unique-amount correlation?
• 7. What if you publish an invoice or Lightning address?
• 8. Eventually the channel closes
• 9. The practical privacy map
• 10. A better self-custodial setup
• Conclusion

Suppose you just want money to behave privately.

You want to:

• get paid without the rest of the world learning who paid you, how much, or when;
• save without the people who pay you learning how much money you have;
• pay someone without them learning where your money came from or how much you own;
• avoid letting previous payers follow where you spend your money later.

How well does Lightning do?

The short answer is:

Much better than transparent on-chain payments against passive public observers. But Lightning replaces some global observers with very privileged local observers, especially your channel peers.

The important question is therefore never just:

“Is this private?”

It is:

Private from whom?

§1. First, you need a channel

Imagine you withdraw bitcoin from a KYC exchange and open a Lightning channel.

The exchange already knows that you received the withdrawal UTXO.

What happens next depends heavily on the channel.

§Public channel

A traditional public Lightning channel is deliberately announced to the Lightning gossip network.

The announcement contains a real short_channel_id identifying the funding transaction’s block, transaction position and output. Anyone following gossip and the blockchain can therefore identify the exact channel funding output, its capacity, and the two Lightning nodes operating it.

So:

KYC withdrawal
      ↓
public channel funding
      ↓
Lightning gossip says:
"this exact UTXO is a channel between node A and node B"

If your goal was to make the KYC trail disappear, this is not particularly helpful.

§Private channel

A private, or more precisely unannounced, channel is not published in global gossip.

That removes a major public link.

Your channel peer still knows everything necessary to operate the channel:

funding UTXO
channel capacity
your Lightning node's pubkey
your network connection
channel balance changes
every HTLC you send through them
every HTLC they send to you

But the rest of the Lightning network does not automatically learn that the channel exists.

That is already a significant improvement. Although the exchange would see a channel-looking P2WSH UTXO onchain.

§Private Taproot channel

Taproot can improve the on-chain side further.

Instead of the traditional funding construction used by regular Lightning channels, a Taproot funding output can look like an ordinary P2TR output. A cooperative key-path close can also reveal considerably less structure.

This does not make the channel magically invisible. Transaction history, force closes, later consolidations and other heuristics may still expose relationships.

As of LND 0.21, production simple-Taproot channels are supported but must remain private until announced Taproot channels are supported.

So a fairly good starting point is:

Taproot channel
+
no public channel announcement
+
SCID aliases

This protects you quite well from passive public observers.

It does not protect you from your channel peer.

§2. Now suppose you want to move the money to cold storage

You opened the channel using your exchange withdrawal.

You now pay a Lightning-to-on-chain swap and ask the swap provider to send bitcoin to your cold-storage address.

Conceptually:

KYC UTXO
   ↓
private channel
   ↓ Lightning payment
swap provider
   ↓
cold-storage UTXO

No single on-chain transaction directly connects the original UTXO to your cold-storage address.

That sounds good.

But consider the amount.

Suppose:

channel:        0.08743152 BTC

a short time later:

swap output:    ~0.0869 BTC

That is a very distinctive pattern.

An observer may not need to break Lightning at all.

If it sees:

1. a suspiciously related funding transaction;
2. shortly afterwards activity from a known swap provider;
3. an output whose value is almost exactly the expected value after fees;

then the amount itself becomes a fingerprint.

§Unique amounts are dangerous

This is a general privacy problem:

The rarer the amount and the tighter the timing, the smaller your anonymity set.

A payment of:

37,218 sats

at 15:32:17 is easier to correlate across two datasets than:

50,000 sats

somewhere during a six-hour period.

This matters whenever different observers can compare:

amount + timing + direction

For example:

your first Lightning peer
             ↘
              correlation
             ↗
swap provider / blockchain

Your direct peer knows when you sent an HTLC through your channel and approximately how much it was for.

If your node is clearly an edge user rather than a routing node, the peer may have a strong reason to believe that the payment originated with you. And this would be obvious for a private channel, that since its unannounced, other users couldn’t use to route payments. So it must be yours.

If that peer can also identify the eventual on-chain swap transaction, the Lightning hop has not necessarily broken the relationship.

§What helps?

Reducing correlation:

• do not perform the swap immediately after opening the channel;
• avoid sweeping a distinctive near-full-channel amount;
• consider splitting activity over time;
• avoid always using the same swap provider;
• use multiple independent Lightning peers;
• avoid unnecessarily unique amounts;
• obtain on-chain privacy before opening the channel where possible.

This last point matters.

Lightning can help preserve privacy you already have.

It is much less reliable as a machine for erasing a highly identifying on-chain history.

§3. What happens when you receive money?

Now suppose you have inbound liquidity and someone wants to pay you.

They need some way to reach your private channel.

With a normal BOLT 11 invoice, this usually means a route hint.

A route hint can contain:

peer node pubkey
short channel ID
fees
CLTV policy

for the private suffix of the route.

The invoice itself also identifies the payee node: the public key can be explicitly included or recovered from the invoice signature.

So the payer may learn something like:

             public network
                   │
                   ▼
          your channel peer
                   │
        private channel alias
                   │
                   ▼
               your node

They now know your Lightning node ID and at least one node through which you can be reached.

§SCID aliases help

A real SCID identifies a channel funding output on-chain.

An SCID alias is instead an arbitrary identifier negotiated by the channel peers.

For channels using option_scid_alias, the real SCID must not be placed in BOLT 11 route hints; an alias may be used instead.

So:

real SCID
   ↓
payer can find funding UTXO

SCID alias
   ↓
payer sees opaque channel identifier

That is an important improvement.

But it does not hide:

your node pubkey
your inbound peer
repeated invoice identity

So an ordinary BOLT 11 invoice can still become a persistent pseudonymous identity.

§4. Blinded paths improve the receiving side

Route blinding attacks a different problem.

Instead of telling the payer:

public node A
      ↓
private peer B
      ↓
your real node C

you can give them something closer to:

public introduction node A
          ↓
      ????????
          ↓
      ????????
          ↓
         you

The payer knows where to enter the blinded route, but not the real identities or channel identifiers of the hidden suffix.

BOLT 12 invoices require blinded payment paths, and BOLT 12 offers can themselves provide blinded paths through which the recipient can be contacted.

This can hide your actual Lightning node identity from the payer.

It does not hide you from the peer whose channel actually connects to you.

That peer still sees the HTLC enter your channel.

It may not cryptographically know that you are the final recipient rather than another forwarding node, but for an obvious edge wallet the inference may be strong.

That distinction matters:

payer:
"payment disappeared somewhere behind this introduction point"

your direct peer:
"an HTLC of this amount entered this user's channel at this time"

§5. What about when you pay somebody?

Lightning is quite good at preventing the recipient from trivially learning the sender’s node.

The recipient does not receive a blockchain input showing where your coins came from.

The onion route means ordinary intermediate nodes know only their adjacent hops rather than the entire route.

Roughly:

YOU → A → B → C → MERCHANT

Node B knows:

came from A
goes to C
amount around X
time T
payment hash H

It does not normally know:

YOU were the sender
MERCHANT was the final recipient

The merchant knows that it got paid.

It does not normally know your first channel, your total Lightning balance, or the UTXO from which your Lightning balance originally came.

That is a substantial privacy improvement over an ordinary Bitcoin transaction.

§But your first peer is special

Suppose your topology is:

YOU <- one private channel -> LSP <--> rest of Lightning

Every payment you make goes through that LSP.

Every payment you receive may also go through that LSP.

So the LSP sees a long-running stream of:

outgoing amount + time
incoming amount + time
channel balance changes

If you rarely route payments for other people (which you couldn’t do with a private channel), it has a strong statistical basis for treating outgoing HTLCs as your payments and incoming HTLCs as your receipts.

This does not mean the LSP automatically knows the remote counterparty.

But it is in an unusually powerful position for timing, amount and routing correlation.

Self-custody removes custody risk.

It does not remove metadata risk.

§6. Does MPP fix unique-amount correlation?

Not automatically.

Multi-Part Payments split one payment across several HTLCs:

100,000 sats

becomes perhaps

31,000
24,000
45,000

A node that sees only one shard may no longer know the total amount.

That can help in some circumstances.

But standard MPP uses the same payment hash for all parts.

And if all shards leave through the same first peer:

YOU
 │
 ├─31k─┐
 ├─24k─┼── same LSP
 └─45k─┘

that LSP can simply observe all the pieces.

MPP may also expose the payment to more intermediate nodes because more paths are being used.

So:

MPP is primarily a liquidity and reliability mechanism, not an anonymity protocol.

It provides the most privacy benefit when the shards leave through different independent first-hop peers and no observer can recombine them.

Even then, correlated timing and the common payment hash can limit the benefit.

§7. What if you publish an invoice or Lightning address?

There is another difference between:

making a payment

and:

publishing a permanent way to receive payments

A public BOLT 11 invoice generator is a poor long-term receiving identifier.

Ordinary BOLT 11 exposes the payee node identity and may expose private route hints.

Anyone who obtains it can associate that Lightning node with the person, account, website or identity that published it.

BOLT 12 can improve this model substantially because a reusable offer can negotiate fresh invoices over Lightning onion messages and can use blinded paths.

But even a BOLT 12 offer is a persistent pseudonymous object.

If you publish the same offer everywhere under your real identity, observers can obviously associate those uses with the same recipient.

§8. Eventually the channel closes

Lightning does not permanently delete the on-chain layer.

Eventually channels close.

That matters because the closing transaction may provide new clues about:

which output was a channel;
which participant received which funds;
which outputs later get consolidated;
which known entity one side belongs to.

Taproot and cooperative closes can reduce what is exposed.

A peer that carelessly consolidates outputs can increase it again.

Force-close paths can expose more channel-specific structure.

So privacy planning should include:

where did the funding coins come from?

and

what will I do with the closing output?

not just what happens while the channel is alive.

§9. The practical privacy map

The easiest way to think about Lightning is this:

The weakest point frequently changes depending on what you are doing.

That is why there is no useful single number called a “Lightning privacy score.”

§10. A better self-custodial setup

If privacy matters, a useful direction is:

on-chain privacy before funding
        ↓
private Taproot channels
        ↓
SCID aliases
        ↓
multiple independent peers
        ↓
blinded receiving paths / BOLT 12
        ↓
careful amount + timing behavior
        ↓
private channel closing strategy

The important word is independent.

Two channels to companies sharing data may provide less privacy than they appear to.

The objective is to avoid giving one party an unnecessarily complete view.

For example:

Peer A sees some outgoing activity.

Peer B sees some incoming activity.

Payers see blinded paths.

Blockchain observers see P2TR transactions
but no public channel announcement.

No single passive observer gets the complete story.

That is much stronger than:

one LSP
   sees
everything in
everything out

§Conclusion

Lightning is not a giant CoinJoin.

It does not make a KYC history disappear.

It does not make unique amounts harmless.

And it does not prevent your channel peers from observing the traffic that crosses their channels.

What Lightning does extremely well is remove the need to publish every payment permanently to the entire world.

That changes the privacy problem from:

EVERYONE can inspect every payment forever

toward:

different parties observe different pieces

That is a major improvement.

The goal should therefore be to make sure those pieces remain separated:

• avoid unnecessary public channels;
• avoid real SCIDs in private route hints;
• use Taproot where appropriate;
• prefer blinded receiving mechanisms;
• avoid relying on one peer for your entire payment history;
• reduce amount and timing fingerprints;
• preserve on-chain privacy before funding and after closing.

The strongest practical Lightning privacy does not come from believing that nobody sees anything.

It comes from ensuring that no single observer gets enough information to reconstruct everything.

https://stacker.news/items/1562360