Paying Yourself? Self-Payments Could Be a Key to Lightning Privacy

The Lightning Network is best known for its fast and cheap payments. But the Layer 2 protocol could also offer more privacy than on-chain payments, since transactions are not published on Bitcoin’s blockchain, blockchain analysis is largely impossible.

The Lightning Network does present its own privacy risks, however. Payments are routed over a network of users, and nothing stops spies from participating in this process of forwarding transactions while monitoring the flow of funds. On the Lightning Network, blockchain analysis can be substituted for network analysis.

There are some solutions to limit these risks, like Tor-style onion routing. These help, but, depending on network topology and types of payments, weaknesses can remain. The Bitcoin and Lightning developer going by the pseudonym ZmnSCPxj has, in recent weeks, published extensive analysis of persisting risks on the Lightning-dev mailing list (1, 2, 3).

Based on his analysis, ZmnSCPxj also offered a solution. Similar to Payswap — his proposal for on-chain privacy, covered by Bitcoin Magazine two weeks ago — the developer thinks that “self-payments” could be an important part of the privacy puzzle.

Understanding Self-Payment

In a previous article, we discussed Payswap, a proposal by ZmnSCPxj to improve on-chain privacy by seemingly inverting the relation between payer and payee. ZmnSCPxj actually initially came up with this idea in the context of the Lightning Network. In fact, it would probably be of even better use on the Lightning Network: Some of the trade-offs embedded in the on-chain alternative do not apply on the Layer 2 protocol.

In short, for the Lightning version of Payswap, the self-payment is part of the same payment route.

To explain how this works, let’s look at an extremely simplified version of a Lightning Network. A(lice) has payment channels with B(ob) and C(arol). Bob has channels with Alice and D(ave). Carol has channels with Alice and Dave. And Dave has channels with Bob and Carol.

A — — B

 |            |

 |            |

C — — D

If Alice wants to pay Dave 3 Bitcoin, she’d normally route the payment through either Bob or Carol. Bob or Carol would charge a small fee for the service, but for simplicity, we’re going to ignore fees in this example. However, the fact that, in reality, fees are paid will be relevant a few paragraphs down, so keep that in mind. 

For now, we’ll say that Alice opts for Bob’s route to make the payment. She sends 3 coins to Bob, and Bob goes on to forward 3 coins to Dave. The payment is a success.

But unfortunately, in this example, it would be easy for Bob to correctly assume that Alice paid Dave 3 coins. He knows the amount because he forwarded it, while if Alice wanted to pay Carol, or Carol wanted to pay Dave, they could have done so directly, without depending on Bob as an intermediary. If Bob is a spy monitoring network traffic, his correct assumption harms both Alice and Dave’s privacy.

ZmnSCPxj, therefore, proposes an alternative. Alice could route the payment all the way back to herself … a “self-payment,” with Dave taking a very big “fee.” The fee would in actuality be the real payment.

To pay Dave like before, Alice would, for example, route 5 coins this time. First, she’d send the 5 coins to Bob, who would forward the 5 coins to Dave. Then — this is the trick — Dave would go on to forward the payment, to Carol … but he only forwards 2 coins! Lastly, Carol would forward the 2 coins back to Alice. In the end, Alice is 3 coins poorer, and Dave is 3 coins richer. Hence, Alice paid Dave 3 coins.

This self-payment would mislead both Bob and Carol. Bob forwarded 5 coins and may logically but wrongly assume that Alice paid Dave 5 coins. Meanwhile, Carol would arguably be even worse off: She’d think that Dave paid Alice 2 coins. From Carol’s perspective, the direction of the payment is inverted.

If either Bob or Carol were secretly spying on network activity, they would have been misled about the size and/or direction of the payment, benefiting Alice and Dave’s privacy. If spies are misled often enough, it could even render such spying activity useless altogether.

PTLCs, Standard Amounts and More

Everything about the example above is simplified, from the network graph to the amounts transacted, while more subtle privacy risks such as fee amounts and timelocks are ignored altogether. Meanwhile, it is assumed that even if both Bob and Carol are spies, they are not cooperating, or worse: They are one spy pretending to be two users.

In reality, both the privacy risks and privacy benefits of routing are greater and more nuanced at the same time. Addressing all these subtleties is beyond the scope of this article; ZmnSCPxj’s submissions to the Lightning-dev mailing list are a better resource for a more in-depth analysis. And more generally, research into Lightning privacy is ongoing.

Still, it’s worth pointing out that ZmnSCPxj’s proposals to improve…

Article Source…