As I said many many many many times here: people should zap wisely. Now with this system, they will remember (again) my words. They will be forced to zap wisely, because if they will use their external wallet it will kill it with so many invoice/payment friction for few sats zaps, not talking also about the fees. Shitcoiners and grifters will just go away.
They will zap less but only when is needed. Damn it I hate when I am right again. @remindme 6 months
95 sats \ 1 reply \ @ek 29 Apr
We will lift your curse of being right all the time :)
reply
reply
62 sats \ 1 reply \ @k00b OP 29 Apr
reply
reply
It can work but only with lightning.pub or LNC to a stationary node, mobile nodes will be extinct soon™️
reply
mobile nodes will be extinct soon™️
If you refer to WoS & like, Phoenix and others that are using a single LSP, then yes, will not have too much time.
But I run Zeus and Blixt on a tablet 24/7, in persistent mode. Managing my own channels as I please, exactly like any other desktop stationary node. There's no difference. I tested even with public channels and I got some little routing, with few channels. I really don't need a full desktop routing node just for few sats I use on SN and buy beers. Both these mobile nodes have also LN address implemented and could extend more features.
We have plenty of solutions.
reply
That's solid, id consider that stationary still.. they both use LND, you've found a nice workaround for hardware... Battery safe like a laptop but low footprint like a raspi 🤌
reply
In your experience, how many payments does a custodial home node handle before getting into troubles?
reply
Some important aspects that seems nobody see with this system:
  1. For each zap, no matter how many sats will be, will carry a routing fee. Yes, stackers can open a channel with SN node and could have 0 fee. But not so many will afford that channel. These fees will make many stackers realize that is quite expensive to zap. So they simply stop zapping, stop posting, stop replying etc. SN will lose a lot of traffic. Some stackers here are even stacking hard few thousands of sats and then go to buy groceries with sats from SN... some people are looking to every single sat.
  2. Regarding the friction upon a node. For more transactions and channel status changes you have your channels.db will increase until will reach a moment that is very slow. yes, there are tools to compact that database, but many noobs do not even know how to manage well their channels... There are some settings you must do in your node to limit that, but all this require skills. Is not that easy to click that and that. In terms of space, in 1 week, depending on your volume of invoices and payments you db could double or triple.
  3. We will see many nodes having FORCE CLOSE channels just because they maintain badly their poor nodes and with just few dumb zaps of 10-20 sats, could get stuck HTLC in high fee environment and because of a stupid zap on SN they will pay huge amount of fees in force closed channels. EXAMPLE HERE:
@remindme 6 months
reply
@remindme (SN's wallet plans Start + 4 weeks) :)
reply
It seem like using your own node might be more trouble than it's worth.
reply
Lightning is super cool but very technical and if nobody can/wants to be custodian anymore it gets very difficult, especially for less committed users.
  1. For micro-transactions fees can be proportionally high. I'd say up to 10% when sending 10 sats. Never saw more than that though.
  2. To prevent this there could be a pooling system, maybe the custodial balance could be maintained to at least 10k sats in order to avoid creating too many transactions and to allow offline nodes to come back online.
  3. What a nightmare! This could happen any moment when using lightning, correct? More zaps only means more stuck HTLC.
reply
More zaps only means more stuck HTLC.
Not really that the number of zaps could get stuck. All depends of the routes is taking those zaps. Some routing nodes are already using LN firewalls to filter all these useless small zaps. Stuck HTLC could happen mainly because:
  • the sender close / go offline his wallet BEFORE the HTLC get "delivered". It could happen even with "stationary" nodes, bad internet, bad syncing, bad fees, bad channels, bad hardware. Are so many causes here.
  • on the route the HTLC encounter a bad node or even a LN firewall bad configured.
  • bugs in LN implementations that make them incompatible to deliver HTLC in some conditions.
The whole idea with using hold invoices is kinda of crazy, especially in this scenario with many small zaps, from many users.
reply