pull down to refresh
268 sats \ 37 replies \ @k00b OP 29 Apr \ parent \ on: SN's wallet plans meta
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
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
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.
reply
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
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
reply
nah... I will became DarthAnon
And I will launder even more sats through SN. Just like that.
reply
reply
watch me.... I already know a trick.
reply
reply
k00b will know. He's the "watcher" :)