I really like the name "cowboy credits" but I think "fee credits" might be clearer to most people. Naming is hard!
@anon would pay an invoice like they do currently. If the stacker they are zapping has an ABW that invoice will belong to the ABW. If the stacker doesn't have an ABW, the invoice will pay SN and SN will give the stacker fee credits.
okay, no change for @anon! Imagine if anons need to buy the fee credits then to zap would be such a turnoff I guess.
And from my understanding, it seems all stackers need to do is attach a wallet then pretty much nothing changes? when Zeus or Blink connection ๐Ÿ‘€ also I wonder would the zapping from external wallets quite slow?
reply
159 sats \ 14 replies \ @ek 29 Apr
also I wonder would the zapping from external wallets quite slow?
We try to make the zapping UX with attached wallets as close to the familiar custodial UX as possible. We can do this by using more optimistic updates that we already use.
For example, currently when you zap from your custodial wallet, the frontend immediately updates but that doesn't necessarily mean that the database finished updating. We only assume it will succeed since that's the case in 99.999% of the cases. If it doesn't succeed, the optimistic update in the frontend is reverted.
We just need something similar for external payments. For example, we can simply assume your attached wallet will be able to pay and update the frontend state immediately. If the payment fails, your zap will be "undone". But keep in mind, it never really happened in the backend, it's only about look and feel.
We already do something like this but it's still really bad. That's what my priority currently is ๐Ÿ‘€
reply
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
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
173 sats \ 1 reply \ @k00b OP 29 Apr
I just saw the Blink API announcement the other day. I'll look into it.
I don't think Zeus has an api yet. I might be wrong though.
reply
work with @justin_shocknet and his lightning.pub / shockwallet. From what I saw I think is a very good solution for SN.
reply
we will move all to anons. Case closed.
reply
You can also pay invoices from your account if you'd like. This is all still WIP so we'll listen to feedback the whole way through as usual.
reply
nah... I will became DarthAnon And I will launder even more sats through SN. Just like that.
reply
You will just be paying an invoice to yourself. We will never have control of your money.
reply
watch me.... I already know a trick.
reply
If you're anon we won't be able to though...
reply
k00b will know. He's the "watcher" :)