LN annoyances

[theymos]

Today I finished rewriting the forum's payment processing code, partially with LN acceptance in mind. I can now add LN support with only a little more work. However, I ended up deciding not to accept LN at this time because I think it'd end up being too much of a headache:

First, Internet protocol designers often underestimate the fragility of the Internet, and don't realize that DDoS protection is probably the single largest issue facing any site large enough to be noticed. You can't just expect sites to run some non-standard public-facing server like it's nothing. Most affordable anti-DDoS services don't even support anything but HTTP(S). I know how to set up an effective layer 4 anti-DDoS system on my own, having run the forum behind such a system for years, but most people can't do that, and it's a big hassle which I'm not going to endure just for LN. (In reality, if I was going to set up LN now, I'd put it on its own VPS and just not care if it gets taken down. But this isn't a good solution.)

Second, because the forum's use-case is in many ways perfect for LN, the forum's LN node could be called on to do a lot of LN routing. So I'd then become a service provider for something new that I don't have time for, where many people will be adversely affected if I decide to bring my LN node & payments down for a few days for tinkering or whatever. LN will make money across many tiny fees, but since the total value is likely to be minuscule, this'll probably be more of an accounting annoyance than anything.

So anyone who wants to accept LN payments in a fully-participating manner basically needs to enter a new side business with a whole new set of paying (but not-very-well-paying) customers who might get annoyed at you for various reasons, and a whole new set of technical concerns. This does not appeal to me...

I suspect that the only people who will accept LN payments in its current state are enthusiasts who are too small or too enthusiastic to care about those issues, plus maybe the very largest of businesses which have both the motive and ability to deal with this. For LN to see wide adoption in its current state, I'd expect it to only be through a proliferation of trusted-third-party LN-based payment processors, which is very much not ideal. In order to avoid this, I recommend one of these solutions:

 - Create a system where third-parties can trustlessly proxy incoming LN payments. It's OK if the final recipient needs to run an always-on daemon, just as long as it's not public. Bonus points if the final recipient doesn't need to open any ports, or if you can do something to allow offline recipients.
 - Restructure LN to be inherently DDoS-resistant. For example, instead of having one public node IP/onion, a unique onion with restrictive data limits could be automatically created and given to each new person you interact with (eg. included in invoices). Also, make LN refuse to route transactions by default.
 - Rather than LN, put more focus on other off-chain systems such as sidechains.

[1714262221]

1714262221

[1714262221]

1714262221

[1714262221]

1714262221

[1714262221]

1714262221

[1714262221]

1714262221

[1714262221]

1714262221

[achow101]

What LN software were you trying to use?

How can LN be made inherently DDoS resistant? I don't think that's something that can be done on a protocol level. It has to be implemented by the implementors of any network protocol, and that pertains to any software that provides a network service.

With routing, the protocol does allow you to not route payments. AFAIK, the option to not route payments is not exposed on existing software.

[Carlton Banks]

- Create a system where third-parties can trustlessly proxy incoming LN payments. It's OK if the final recipient needs to run an always-on daemon, just as long as it's not public. Bonus points if the final recipient doesn't need to open any ports, or if you can do something to allow offline recipients.

You can do this now, and all it involves is not opening ports on your lightning node.

You'd need to come up with a custom script to create the liquidity you need, as people wouldn't be able to find your node in order to initiate opening channels. But you could initiate opening channels with nodes you connect to. Setting up a sufficient number of private channels to serve the site might eventually become a problem, but the overall network liquidity will continue to grow in the meantime.

So it would be more involving than just running the node's autopilot channel management. But it can be done.

[monst]

"setting up DoS protection (outside of what impls do) would be no more diff that any regular layer 4 DoS protection

routing is optional also, you can just reject all forwards, not advertise your channels, have no onion addr or IP, and accpet only"

-roasbeef

[bvu]

If you're just accepting and issuing payments from the forum, you should only require a small number of private channels (~5, depending on the size of payments and how well-balanced the flows are) to gateway routing nodes. Routing nodes basically are the third-parties that "trustlessly proxy incoming LN payments" (and outgoing). Some more info about this can be found in this blog post: https://blog.lightning.engineering/posts/2018/05/30/routing.html.

There's really no reason for the forum to be doing routing, as each of the forum members should be creating channels to routing nodes as well (so that they can send and receive payments to and from anyone in the network), not just the forum node itself.

As far as DDoS protection, that's definitely not my area of expertise, but in the standard case, an LN node can filter traffic from IP addresses other than the ~5 routing nodes you have, and can also filter anything outside of a specific set of ports. Also, since you would be using private channels, the IP address of your node won't be visible to anyone other than your set of routing nodes, and you can also use Tor if you'd like to keep it private from them as well.

[theymos]

If you're just accepting and issuing payments from the forum, you should only require a small number of private channels (~5, depending on the size of payments and how well-balanced the flows are) to gateway routing nodes. Routing nodes basically are the third-parties that "trustlessly proxy incoming LN payments" (and outgoing). Some more info about this can be found in this blog post: https://blog.lightning.engineering/posts/2018/05/30/routing.html.

There's really no reason for the forum to be doing routing, as each of the forum members should be creating channels to routing nodes as well (so that they can send and receive payments to and from anyone in the network), not just the forum node itself.

As far as DDoS protection, that's definitely not my area of expertise, but in the standard case, an LN node can filter traffic from IP addresses other than the ~5 routing nodes you have, and can also filter anything outside of a specific set of ports. Also, since you would be using private channels, the IP address of your node won't be visible to anyone other than your set of routing nodes, and you can also use Tor if you'd like to keep it private from them as well.

I didn't know that, thanks. I'll try to figure it out when I get time. It would be nice for this all to be handled automatically, though.

What LN software were you trying to use?

I was looking mainly at c-lightning because I don't want to use btcd and c-lightning's documentation seemed better-organized, but it looks like lnd might be better. (Also, after looking more closely, it might be possible to run lnd without btcd.)

[achow101]

I was looking mainly at c-lightning because I don't want to use btcd and c-lightning's documentation seemed better-organized, but it looks like lnd might be better. (Also, after looking more closely, it might be possible to run lnd without btcd.)

LND can be used with Bitcoin Core with fairly minimal setup. It uses Bitcoin Core's ZMQ interface so you will need to make sure that is enabled.

[darosior]

I was looking mainly at c-lightning because I don't want to use btcd and c-lightning's documentation seemed better-organized, but it looks like lnd might be better. (Also, after looking more closely, it might be possible to run lnd without btcd.)

Since release v0.6, C-lightning can be run (almost) without bitcoind too.

Lightweight nodes: Previous releases required a full bitcoind node running alongside c-lightning, to provide access to the Bitcoin network. This release still requires the bitcoin-cli utility to be present, but it can now talk to remote nodes as well, including some lightweight nodes such as spruned.

[bvu]

It would be nice for this all to be handled automatically, though.

Understand and agree. We (as in the Lightning community) are working on it. We're still in the bleeding edge days of mostly CLI and manual control, but lots of progress is being made to make things easier.

[Kakmakr]

Will the fact that you need to have the LN node running 24/7, not have a additional burden on the administration of this? Also, running multiple nodes in different locations, would make DDoS more difficult. <if possible>

It would be cool to incorporate cheap micro payments into a forum like this, <Possibly as a Tipping feature> in the future. 

In any way, #bvu's suggestion <gateway routing nodes> looks like the ideal short-term solution. 

[mocacinno]

I'm running bitcoind, c-lightning and lightning-charge on a very small demosite myself, and i must honestly say the whole setup wasn't that hard... It's pretty easy to setup and administer, and it's actually pretty hands-off.
Offcourse, i've only got a handfull of channels, and i've accepted ~60-ish payments so far, so i have no idear how my own sollution would scale for something as massive as bitcointalk.

[sat0shiswife]

I just got my node up and running on testnet today.

AFAIK, you don't have to route public payments. Its just a setting in lnd.conf (specifically nat=true needs to be deleted/commented out).

Also, I am running LND with bitcoind (not btcd) and so far, everything is working just fine (after a very very long time to sync everything).

I don't intend on routing public tx when I move to mainnet though, I planned on routing through TOR with a private address. So, my use-case might not be the best because if everyone did it this way, it would defeat the purpose of LN.

[xWolfx]

I don't intend on routing public tx when I move to mainnet though, I planned on routing through TOR with a private address. So, my use-case might not be the best because if everyone did it this way, it would defeat the purpose of LN.

The thing is that even when i'm not an expert in the subject, Tor could solve many security issues and not only DDoS. It's a somewhat simple solution for what could potentially be bigger problems specially today when DDoSing or hacking security systems is becoming increasingly easy.

The point of view of the administration to improve security couldn't come in a better time.

[sat0shiswife]

I don't intend on routing public tx when I move to mainnet though, I planned on routing through TOR with a private address. So, my use-case might not be the best because if everyone did it this way, it would defeat the purpose of LN.

The thing is that even when i'm not an expert in the subject, Tor could solve many security issues and not only DDoS. It's a somewhat simple solution for what could potentially be bigger problems specially today when DDoSing or hacking security systems is becoming increasingly easy.

The point of view of the administration to improve security couldn't come in a better time.

if only everyone ran a TOR Relay and an LN Node ... imagine the private, trustless, open utopia we could live in.

[buwaytress]

I don't intend on routing public tx when I move to mainnet though, I planned on routing through TOR with a private address. So, my use-case might not be the best because if everyone did it this way, it would defeat the purpose of LN.

The thing is that even when i'm not an expert in the subject, Tor could solve many security issues and not only DDoS. It's a somewhat simple solution for what could potentially be bigger problems specially today when DDoSing or hacking security systems is becoming increasingly easy.

The point of view of the administration to improve security couldn't come in a better time.

if only everyone ran a TOR Relay and an LN Node ... imagine the private, trustless, open utopia we could live in.

Speaking also from a non-technical opinion, in fact, seems to me that if enough people ran both, I imagine we wouldn't even need to run them 24/7, even just switching them on during our working hours might be enough to keep the whole thing afloat, as long as there were enough nodes and relays to take over seamlessly. The way it is now, though, it's not exactly private (if, for example, after a couple of hours of sessions I can already recognise relays) and not exactly trustless if we have to rely on the same few nodes.

[fronti]

Speaking also from a non-technical opinion, in fact, seems to me that if enough people ran both, I imagine we wouldn't even need to run them 24/7, even just switching them on during our working hours might be enough to keep the whole thing afloat, as long as there were enough nodes and relays to take over seamlessly. The way it is now, though, it's not exactly private (if, for example, after a couple of hours of sessions I can already recognise relays) and not exactly trustless if we have to rely on the same few nodes.

to turn on a TOR relay OR LN Node only for some hours is not as usefull as it sounds.
The routing allgorithm in both cases did not like to have this uncertainly. They can work with this but the whole network run smoother if the nodes not change to often.
so the best is to keep this running 24/7. But sure, it work also if it is only on for some hours..