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 Lightning privacy go beyond self-payments — in some scenarios, additional protocol changes would in fact be more-or-less necessary for self-payments to be effective privacy improvements. The two most important changes are a switch from hashed timelock contracts (HTLCs) to public key timelock contracts (PTLCs), and adoption of standard amounts. So let’s look at these two in brief.
Right now, Lightning payments are routed using HTLCs. All users along a route essentially pass on a code which guarantees that they can claim funds from one counterparty if the other counterparty claims funds from them (This is how funds are forwarded over the network). Unfortunately, if cooperating spies are part of the same route, they can use the HTLCs to tell that different hops are in fact part of the same payment, to an extent undoing the benefit of onion routing. PTLCs would leverage cryptographic tricks to prevent spies from linking different hops to the same route.
ZmnSCPxj also proposes that Lightning users adopt standard amounts. While optional, wallets would be encouraged to split payments up into smaller (but interlinked) payments, where each smaller payment consists of standard amounts. If the standard amounts are for example 1, 2 and 5 coins, Alice in the above example would make two payments of 1 coin and 2 coins, instead of one payment of 3 (Or, if she makes a self-payment, she could send 5 and route 2 back to herself).
If enough users would limit their (fractions of) payments to standard amounts, spies cannot rely on amounts to link different hops to the same payment. In the context of self-payments, users could even route nonstandard amounts from the payee back to themselves, making these look even more like regular payments.
Self-Payment Drawbacks
The on-chain version of ZmnSCPxj’s proposal, Payswap, comes with significant trade-offs. Compared to a regular payment, more transactions are needed, which translates into higher fees. On top of that, Payswap transactions require interaction between users outside of the Bitcoin protocol; regular bitcoin transactions do not.
On the Lightning Network, these drawbacks don’t hold up — or they hold up to a lesser extent. Lightning payments require interaction in either case, so a self-payment wouldn’t make the situation worse. And while some extra transaction hops are necessary to make a self-payment, these hops happen off-chain, so they don’t require extra blockspace.
That said, self-payments still come with some drawbacks, even on Lightning. While cheaper than on-chain fees, extra hops do cost a bit more in routing fees. Additionally, as more hops are added to a payment, the risk of a failed payment increases, and the risk of a spy being part of a route increases, too (If only Carol was a spy in the example above, the self-payment would have given her more information than a simple route through Bob would have).
Lastly, of course, there might be other (as of yet unforeseen) trade-offs as well; self-payments are a relatively new proposal. As ZmnSCPxj concluded in his emails, “More analysis on the use of circular payments when paying may be in order.”
The post Paying Yourself? Self-Payments Could Be a Key to Lightning Privacy appeared first on Bitcoin Magazine.
