pull down to refresh
88 sats \ 24 replies \ @DarthCoin 29 Apr freebie \ parent \ on: SN's wallet plans meta
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
reply
reply
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:
-
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.
-
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.
-
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
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.
-
For micro-transactions fees can be proportionally high. I'd say up to 10% when sending 10 sats. Never saw more than that though.
-
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.
-
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.
Is every SN zap really a lightning transaction? That's nuts. Why?!
The only LN transactions should be topups for when there is insufficient funds in your SN wallet.
I guess now ln is cheap enough that it doesn't matter, so why not?
But this won't last forever.
Edit: as to the why, I guess the answer is so that SN can be not-custodians and all the regulatory and ethical and security headache that flows from that.
Well, that does make sense.
reply
Is every SN zap really a lightning transaction? That's nuts. Why?!
It isn't currently. Even after this switch, "every" zap won't be a lightning transaction. If you want the zaps you receive to be bitcoin and not some in-game currency/sn gift card, you're only going to achieve that with a lightning transaction. Otherwise SN would be a money transmitter and would be obligated to KYC you (which is more nuts imo).
But this won't last forever.
I don't suspect LN will ever be much more expensive than 1-2% of the funds moved.
reply
My understanding of SN zaps... is that they were held in an 'account' for us till they were 'withdrawn'. Each 'zap' is not a lightning transaction then. Just a number on a screen saying what our sat-count was (until we withdrew some of them).
There is no need, in my opinion, to worry about custodial/non-custodial over 100 sats it's too small to be significant.
reply
reply
Let's create an SN bailout fund in case any stacker finds himself behind bars for these illogical regulations.
reply
Why 'mericans became such pussies these days?
That "money transmission law" refer only to fiat money, not to bitcoin.
reply
None of this makes any sense.
reply