The Lightning Network FAQ

[Wind_FURY]

I meant, isn't it possible to develop privacy features to hide sender, receiver, and amount, off-chain in the Lightning Network?

Nodes participating in the routing process don't know who initiated the transaction and what the final destination is thanks to onion routing. Transactions are not listed anywhere so they can't be tracked by outsiders. As for hiding the amount, multi-part payments have just become a real thing.

For hiding amounts and CLTV deltas, C-lightning also uses shadow routing.

OK, with all that, can Lightning then be developed into a viable, trust-minimized alternative for centralized mixing/tumbling?

[LoyceV]

OK, with all that, can Lightning then be developed into a viable, trust-minimized alternative for centralized mixing/tumbling?

I don't expect LN to be used for many large transactions, so it might be used to hide the coffee beers you bought from your wife, but not to hide your yacht.
Even at low LN-fees, I assume nodes will charge a percentage because that's how they earn (and they need to balance their channels again), so for high amounts, on-chain fees will be much lower.

[darosior]

I meant, isn't it possible to develop privacy features to hide sender, receiver, and amount, off-chain in the Lightning Network?

Nodes participating in the routing process don't know who initiated the transaction and what the final destination is thanks to onion routing. Transactions are not listed anywhere so they can't be tracked by outsiders. As for hiding the amount, multi-part payments have just become a real thing.

For hiding amounts and CLTV deltas, C-lightning also uses shadow routing.

OK, with all that, can Lightning then be developed into a viable, trust-minimized alternative for centralized mixing/tumbling?

As I said above not really if you want to get back on chain afterwards. But just use joinmarket if you want trustless mixing...

Even at low LN-fees, I assume nodes will charge a percentage because that's how they earn (and they need to balance their channels again), so for high amounts, on-chain fees will be much lower.

It depends, I expect most of routing nodes to remove (most of?) their base fee in the future, and thus thanks to multi part payments you could make big payments as well.
As the network grows there will be more and more alternative paths from you to your destination (and even more with smaller payments if you use MPP!), and if some node owners rise their fees too much they wont be chosen into routes anymore. So I don't expect fees to rise that much.
Nonetheless I hope the base layer will still be used because...  

[DooMAD]

https://bitcoinmagazine.com/articles/lightning-network-traffic-analysis-raises-questions-fees-privacy
https://arxiv.org/pdf/1911.09432.pdf

this paper’s findings currently put the responsibility of privacy on users selecting their payment routes.

Oh, no!  Responsibility?!  What a catastrophe!  

Responsibility is something that generally comes with freedom.  It's only natural.  Even if no further advancements were made towards privacy from this point forwards, it's a fair price to pay (and I suspect the majority of users on this chain would rather take on some additional responsibility, rather than sacrifice decentralisation, which is a much higher cost to bear).  But I suspect we'll be making continued advancements in privacy anyway, both on-chain and off.

[Wind_FURY]

I meant, isn't it possible to develop privacy features to hide sender, receiver, and amount, off-chain in the Lightning Network?

Nodes participating in the routing process don't know who initiated the transaction and what the final destination is thanks to onion routing. Transactions are not listed anywhere so they can't be tracked by outsiders. As for hiding the amount, multi-part payments have just become a real thing.

For hiding amounts and CLTV deltas, C-lightning also uses shadow routing.

OK, with all that, can Lightning then be developed into a viable, trust-minimized alternative for centralized mixing/tumbling?

As I said above not really if you want to get back on chain afterwards. But just use joinmarket if you want trustless mixing...

But, can it help in making your transactions harder to trace? I believe that's the whole point I was arriving at.

https://bitcoinmagazine.com/articles/lightning-network-traffic-analysis-raises-questions-fees-privacy
https://arxiv.org/pdf/1911.09432.pdf

this paper’s findings currently put the responsibility of privacy on users selecting their payment routes.

Oh, no!  Responsibility?!  What a catastrophe!  

Responsibility is something that generally comes with freedom.  It's only natural.  Even if no further advancements were made towards privacy from this point forwards, it's a fair price to pay (and I suspect the majority of users on this chain would rather take on some additional responsibility, rather than sacrifice decentralisation, which is a much higher cost to bear).  But I suspect we'll be making continued advancements in privacy anyway, both on-chain and off.

Privacy in on-chain transactions are also the users' responsibility. What's so special about it for the troll?

[DooMAD]

Privacy in on-chain transactions are also the users' responsibility. What's so special about it for the troll?

Thought they were scoring cheap points.  Failed as usual.   

One day they'll learn that they've lost every argument before they've even tried to make it, because their go-to position is to throw decentralisation under the bus.  It's the one thing all the Lightning detractors can't get around.  LN provides more throughput without placing any additional burden on the non-Lightning users who secure the blockchain.   

[LoyceV]

But, can it help in making your transactions harder to trace?

Of course Want to test it for yourself? Try finding my on-chain address connected to this transaction.

[darosior]

Hi everyone,

As we talked about privacy in this thread, here is a great write up by ZmnSCPxj which summarizes a lot of the known privacy breaches: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002408.html.

[Wind_FURY]

But, can it help in making your transactions harder to trace?

Of course Want to test it for yourself? Try finding my on-chain address connected to this transaction.

I can't, of course.

But that's the beauty if some specialized actors, good or bad, decide to track and breach user-privacy. They're required to stake Bitcoins in Lightning, provide liquidity, which add value to the network.

[Carlton Banks]

Also in relation to privacy/fungibility over Lightning, here is a link to another write-up by the same author (ZmnSCPxj) Darosior linked on a Coinswap-like procedure using the Lightning protocol:

https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002245.html

[DaveF]

Can anyone do me a favor and open up a channel to my node at home?

Whacker
03400a67375da5d5d04dd59514452ce9f0cadb2fbec65863073897d52843b61c80@24.45.24.105:9735
03400a67375da5d5d04dd59514452ce9f0cadb2fbec65863073897d52843b61c80@whacker.cas8.com:9735

I can open channels out and pay invoices, but when I try to open one from my other node at the office it fails.

But, I have done some testing on my node at the office and I don't know if I broke something.

Thanks,
Dave
edit: someone opened one. If it was one of you thanks :-)
Now all I have to do is figure out what I broke on the office one.

[Wind_FURY]

Who among the consistent Lightning users here have been running a node, specialized specifically for routing transactions/providing liquidity, how long have you been running it, and what's the averge cost of running it?

[darosior]

Who among the consistent Lightning users here have been running a node, specialized specifically for routing transactions/providing liquidity, how long have you been running it, and what's the averge cost of running it?

I've been running one (C-lightning) for almost two years now, and it costs me barely nothing : just setup on top of my old computer which already ran core.
So it costed me a low end computer which I had for free (I'm in the process of changing it, but I'm not that well connected after all) and electricity cost for an idle computer.
The bigger cost is the coins to open channels.

[Rath_]

Lnd v0.9.0-beta was released 2 days ago. The update introduced quite a few new features and changes. While 0.9.0 does not support sending MPP (Multi-Path Payments), it does support receiving them. It looks like we will have working MPPs by the end of the year!

Once I have passed all of my exams, I will look into other implementations and see if they also got similar features.

-snip

I stopped running my node at some point since I didn't need a dedicated server for anything else at that time. I might consider running it again since I have been renting a dedicated server for 2 months now. The resource usage is negligible.

[LoyceV]

While 0.9.0 does not support sending MPP (Multi-Path Payments), it does support receiving them. It looks like we will have working MPPs by the end of the year!

I've been wondering for a while now how that would work. You don't want one path to be confirmed, and the other paths to get stuck. That would result is a partial payment.
It turns out the magic word to solve this problem is "Atomic". I'll only quote the magic part, the full article explains it in depth:

If Bob does not receive all of the partial payments, then he cannot generate the base pre-image thus making it atomic.

I stopped running my node at some point since I didn't need a dedicated server for anything else at that time. I might consider running it again since I have been renting a dedicated server for 2 months now. The resource usage is negligible.

Doesn't it need a full Bitcoin Core, and thus quite a lot of disk space and RAM?

[darosior]

Hi,

While 0.9.0 does not support sending MPP (Multi-Path Payments), it does support receiving them. It looks like we will have working MPPs by the end of the year!

I've been wondering for a while now how that would work. You don't want one path to be confirmed, and the other paths to get stuck. That would result is a partial payment.
It turns out the magic word to solve this problem is "Atomic". I'll only quote the magic part, the full article explains it in depth:

If Bob does not receive all of the partial payments, then he cannot generate the base pre-image thus making it atomic.

What you describe is a proposal made from Lightning Labs team (namely Olaoluwa and Conner), which is about "mathematical" atomic multi-parts payments.
However, what has been merged to the spec and is implemented by LND, C-lightning and Eclair (maybe Rust-Lightning too?) are kind of "economical" multi-parts payments. The receiver won't claim (and thus release the preimage, which is a proof of payment) any part before having all of them. Doing so would be economically irrational as the receiver would accept the payment before receiving it entirely. As such all parts use the same payment hash, thus the same preimage (== proof of payment).

Some refs:
- Link to the "mathematical" AMP mailing list thread https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html
- Link to the "mathematical" AMP spec proposal https://github.com/lightningnetwork/lightning-rfc/pull/658
- Link to then "economical" AMP (merged) spec proposal https://github.com/lightningnetwork/lightning-rfc/pull/643

[Rath_]

Doesn't it need a full Bitcoin Core, and thus quite a lot of disk space and RAM?

The only alternative that comes to my mind is neutrino (for LND) which fetches the necessary data from compatible full nodes It makes use of BIP158. It's not as reliable as the full node setup. I might try using it this time so I can let you know how it performs if you want.

[darosior]

The only alternative that comes to my mind is neutrino

I know you are talking about LND, but for reference that's not specific to all LN nodes. C-lightning can run against a pruned node for example, so you can have a full Bitcoin-today setup for 30GB of storage (or even less).

[Rath_]

C-lightning can run against a pruned node for example, so you can have a full Bitcoin-today setup for 30GB of storage (or even less).

I had been using LND for most of the time; that's why I mostly mention features available only for it. Thanks for bringing it up. Running a pruned node sounds more appealing than experimental software. What other c-lightning features are worth paying attention to?

[darosior]

C-lightning can run against a pruned node for example, so you can have a full Bitcoin-today setup for 30GB of storage (or even less).

I had been using LND for most of the time; that's why I mostly mention features available only for it. Thanks for bringing it up. Running a pruned node sounds more appealing than experimental software. What other c-lightning features are worth paying attention to?

I'd say plugins for extensibility.
If you are a regular user, you can choose from a constantly growing list of community-curated C-lightning plugins.
If you are a developer, or at least know a bit of Python or other high-level language (there are libs for Python, JS, Go, C, C++), you can script a C-lightning plugin really quickly that fits your needs. The C-lightning server (`lightningd`) will send to plugins notifications about events (like, "an invoice has been paid") or hooks (like, "I got an HTLC, its details are {}, what do I do with it ?"), and allow it to register new RPC commands (for example the summary plugin adds the `summary` command which give a higher level summary of your node's status).

Otherwise, not that many features as C-lightning aims to only implement the core functionalities : anything higher-level belongs to plugins.