“I already had a channel. Why did they open another one when I received a new payment?”
Do you see how this quickly becomes more complicated than something like WoS? Zeus is absolutely amazing and I love what they’ve built. For someone already familiar with bitcoin it is one of the best apps out there. But it is one tool in your tool belt, and for someone who doesn’t even understand bitcoin it will require a lot of handholding. I’m not suggesting it shouldn’t be used, or that it self-custody shouldn’t be taught, but it’s not the first step when someone is learning about bitcoin.
As for the fees, Zeus’s fee structure is untenable for very small payments the way people zap on Nostr. As for the channels tab, I think it’s fine where it is. It isn’t the default tab, and it makes it easy to find if you need it. Maybe an option to hide it if you don’t want to always see it would be useful.
To be fair, if both channels are with the LSP then I wish they would incorporate the Phoenix splicing model and keep it as one channel with flexible sizing. I’m not smart enough to understand if there are significant downsides of doing this, but if you’re already going to have to go on chain to add liquidity, why not consolidate to one UTXO as well?
I agree that it can be more complicated and pose more questions for new users, but a lot of people won’t ever bother to ask questions as long as it works. And to me, it’s across a threshold of usability where I’d be comfortable recommending it to one of my parents.
Phoenix’s fees are even worse than Zeus after they moved to splicing. If Zeus did the same I would stop using it altogether. You are basically paying higher fees than on chain every time you receive in Phoenix
I still don’t understand why that’s the case for them. Why wouldn’t it just check if there is enough inbound liquidity, and then if there isn’t, splice in the money to an existing channel? What about that structure makes fees so expensive?
My assumption is that it’s about risk management for them. Maybe I’m wrong though. Keeping sats locked up in fixed-size channels creates potential risk for the node operators. In their old model, if the sats were sitting on your side of your channel or channels (aka, your wallet balance), then the risk is yours to take and they probably wouldn’t care. But if the sats are sitting on ACINQ’s side of the channel (so you have inbound liquidity), then they’re assuming any risk associated with keeping those funds locked up until you receive a payment that moves them to your side of the channel. By splicing, now they can change the size of your single channel to minimize the amount of sats sitting locked up on their node. When you send and receive, they just adjust the channel size accordingly and you pay whatever mining fee is associated with making that happen. 
I see. They should make splicing-in a default setting, but they should make splicing-out only for cases of emergency. I’m not sure what risk they are taking, it seems like if what you’re saying is right they are being stingy and just don’t want to deploy adequate capital. I personally would happily pay high fees (even 1-2%) if a business would maintain the capacity of my channel even if it’s mostly on their side.
I would probably still use it if they did that and the channel size stayed the same until a splice in was needed to increase it. That makes more sense to me from a user standpoint. But there are other good options. I’ve been really happy with Breez for a long time.
I think it’s a great feature if implemented correctly. But I’ve only ever personally used Zeus or my own LND node.
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
By the way, I would add, that different wallets might be useful for different usecases.
I am trying wallets for buying corn nokyc, and Phoenix seems bad, but seemed better to get my funds onchain then using a swap service with Breeze. But it was in a low fee environment. In a high fee environment is different again 😂
So nokyc, non-custodial == trouble 😂💜🦙
Thread collapsed
Thread collapsed
Thread collapsed
