Pseudo(?) self-custodial LN wallets

[internetional]

Some LN wallets pretend to be self-custodial, but there is no option for users to force-close their channels there. So users have to rely on LSPs. If the LSP goes offline, users cannot access their money, and, in the worst scenario, they can completely loose it.

Here are some examples of such wallets.

Defiant


Bitmask


Bridge wallet


10101


None of them has any tools for channel management. Their users cannon force-close LN channels and may send money only from their channels only if wallet servers remain online and collaborate.

I asked support teams of all these wallets how I can access my money incase their servers go offline forever. But they have no answer. Only Bitmask says something that looks like kind of an answer:

I believe our server does support LNURL, we just don't have a way for a user to see that
Will look into it

Maybe I err, and funds in LN channels are self-custodial even if I have no tools for force-close?

[1714257799]

1714257799

[1714257799]

1714257799

[1714257799]

1714257799

[1714257799]

1714257799

[1714257799]

1714257799

[dkbit98]

I was playing with BitMask wallet recently and I didn't like it, but I never tested other wallets you mentioned here.

Some LN wallets pretend to be self-custodial, but there is no option for users to force-close their channels there. So users have to rely on LSPs. If the LSP goes offline, users cannot access their money, and, in the worst scenario, they can completely loose it.

Do you know if Breeze wallet falls into this category or not?
They claim that non-custodial Lightning node is running on mobile devices after installing Breeze app, but there is also a warning that you may loose funds when you first start the app, because they are in beta stage.
https://breez.technology/mobile/

[internetional]

Do you know if Breeze wallet falls into this category or not?

I didn’t use Breez, so I can’t answer. They say they provide an option to close channels (https://doc.breez.technology/How-to-close-Breez's-channels.html) but it’s not clear whether it needs to be a cooperative closure, or users may close their channels unilaterally. Similar buttons are present in Electrum and in Green.

I like Blixt. It has a special “force-close” button, and it works. Such button is present in Phoenix also. I think, it must work. But I’ve never tried it.

[NotATether]

Any self-respecting Lightning service provider should allow you to export your macaroons and seed phrases, so that you can interact with the node with a command-line tool or some other wallet. Don't bother using them if they don't let you do that.

I don't use mobile LN apps, but I do have a browser extension. It's not much better security wise, but there is only a couple of sats in there.

You  might be able to buy channels to your node with some service like Amboss though.

[BlackHatCoiner]

Do you know if Breeze wallet falls into this category or not?

It's been years since I tried Breeze, but I remember that I could receive sat without any channel, which gave me the impression it is custodial.

Any self-respecting Lightning service provider should allow you to export your macaroons and seed phrases, so that you can interact with the node with a command-line tool or some other wallet.

I would also add that for a lightning wallet to respect self-custody, it has to be open-source, and as far as I can see, Bridge isn't. You wouldn't call a closed-source Bitcoin wallet self-custodial; don't trust, verify.

[internetional]

I doubt the self-custodial nature of the Mutiny wallet.

Their website states that the wallet is self-custodial.


However, recently Mutiny introduced a fee of 1 satoshi for each incoming transfer. If I create an invoice for 1000 satoshis, and someone pays it and sends me 1000 satoshis, Mutiny somehow manages to take one satoshi for itself from the received amount, leaving me with 999.

In my opinion, such a maneuver wouldn't be possible with self-custodial storage. If a thousand satoshis are received via my invoice, no one should be able to withdraw anything from that thousand without my permission. Yet, Mutiny can. Therefore, the wallet developers have access to the bitcoins in it. Applying the term "self-custodial" to such a wallet, in my view, is incorrect.

[DaveF]

I doubt the self-custodial nature of the Mutiny wallet.

Their website states that the wallet is self-custodial.
***image removed***

However, recently Mutiny introduced a fee of 1 satoshi for each incoming transfer. If I create an invoice for 1000 satoshis, and someone pays it and sends me 1000 satoshis, Mutiny somehow manages to take one satoshi for itself from the received amount, leaving me with 999.

In my opinion, such a maneuver wouldn't be possible with self-custodial storage. If a thousand satoshis are received via my invoice, no one should be able to withdraw anything from that thousand without my permission. Yet, Mutiny can. Therefore, the wallet developers have access to the bitcoins in it. Applying the term "self-custodial" to such a wallet, in my view, is incorrect.

Can you control the channels or do they? If all the BTC goes though their channels then yes they can.
You have your channel(s) but they all go through theirs. It's a crappy way to do things and a logistical programming disaster but it can be done without them having access to your BTC

If you can connect to whatever peers and open channels to them then I do not see a way off the top of my head for them to take their fee.

-Dave

[internetional]

Can you control the channels or do they?

What does “control” mean?
In Mutiny wallet, I can open channels only to their default lightning service provider Voltage. So all the sats I receive to Mutiny via LN comes through Voltage’s node.
But I have some control over my channels. At least, I may close them unilaterally. (Actually, I haven’t tried, but there is such a button in the wallet interface.)

[FinneysTrueVision]

Do you know if Breeze wallet falls into this category or not?

It's been years since I tried Breeze, but I remember that I could receive sat without any channel, which gave me the impression it is custodial.

It is not custodial. Many lightning wallets are doing this now. When you receive a payment they will open a channel on demand to your node. You will have instant inbound capacity by opening a channel this way, instead of having to send a few payments first before you are able to receive sats.

[DaveF]

Can you control the channels or do they?

What does “control” mean?
In Mutiny wallet, I can open channels only to their default lightning service provider Voltage. So all the sats I receive to Mutiny via LN comes through Voltage’s node.
But I have some control over my channels. At least, I may close them unilaterally. (Actually, I haven’t tried, but there is such a button in the wallet interface.)

I was asking if you can open to wherever you like. And if they could open / close channels on your behalf.

In theory it's still self-custody but if they can have your wallet open channels to places that they want them opened to without you interacting it's different.

Yes you control it, but you can only open channels to these 50 other nodes....all of which we control....

-Dave

[internetional]

A user of Blitz wallet shared how after closing the channel to the LSP, the balance of his wallet became zero. It turned out that the closing transaction was broadcasted to the network with a fee of 2 sat/vB and was subsequently dropped from the provider's mempool. Now the provider (and consequently, the wallet application) cannot see the funds either on the Lightning Network or on the base layer, indicating that they simply don't exist.

Of course, if the mempool ever clears, the provider will eventually see the transaction, and it will appear in the wallet. Nevertheless, this story suggests that calling such storage non-custodial when you don't control the fee isn't entirely accurate. Due to incorrectly set fees by the application, you could lose access to your funds for a long time.

[DaveF]

A user of Blitz wallet shared how after closing the channel to the LSP, the balance of his wallet became zero. It turned out that the closing transaction was broadcasted to the network with a fee of 2 sat/vB and was subsequently dropped from the provider's mempool. Now the provider (and consequently, the wallet application) cannot see the funds either on the Lightning Network or on the base layer, indicating that they simply don't exist.

Of course, if the mempool ever clears, the provider will eventually see the transaction, and it will appear in the wallet. Nevertheless, this story suggests that calling such storage non-custodial when you don't control the fee isn't entirely accurate. Due to incorrectly set fees by the application, you could lose access to your funds for a long time.

It is easily fixed with either a CPFP OR bumping the fee if RBF is enabled (which it should) OR using a TX accelerator.

So it's not the end of world.

Did they share the TXID?

Makes you wonder what happened to cause the issue.

-Dave

[internetional]

It is easily fixed with either a CPFP OR bumping the fee if RBF is enabled (which it should) OR using a TX accelerator.

So it's not the end of world.

Did they share the TXID?

Makes you wonder what happened to cause the issue.

-Dave

Channel closing transactions are usually beyond the user's control in mobile LN wallets. So, it's impossible to initiate RBF.

For CPFP, you must control one of the receiving addresses. But Blitz wallet is based on BreezSDK/Greenlight. In this architecture, the addresses which receive the outputs of channel closing transactions are not controlled by users. The user whose channel is closed must order a "refund" after the closure. Thus, CPFP is impossible, too.

A TX accelerator may help. But one needs to know the TXID for it. And wallets may provide users with wrong TXIDs. At least, Green wallet, after the closure of my channel, gave me the TXID which cannot be found in mempool.space. I knew the TX which had opened the channel, so I managed to find the actual closing TX. But it was possible only because I opened the channel myself. Usually such wallets (Green, Relai, Blitz etc) open the channels when users top-up their wallets via LN invoices. In this case, users don't know the actual TXID of their opening transaction, and it may be hard to allocate the closing one.

[DaveF]

It is easily fixed with either a CPFP OR bumping the fee if RBF is enabled (which it should) OR using a TX accelerator.

So it's not the end of world.

Did they share the TXID?

Makes you wonder what happened to cause the issue.

-Dave

Channel closing transactions are usually beyond the user's control in mobile LN wallets. So, it's impossible to initiate RBF.

For CPFP, you must control one of the receiving addresses. But Blitz wallet is based on BreezSDK/Greenlight. In this architecture, the addresses which receive the outputs of channel closing transactions are not controlled by users. The user whose channel is closed must order a "refund" after the closure. Thus, CPFP is impossible, too.

A TX accelerator may help. But one needs to know the TXID for it. And wallets may provide users with wrong TXIDs. At least, Green wallet, after the closure of my channel, gave me the TXID which cannot be found in mempool.space. I knew the TX which had opened the channel, so I managed to find the actual closing TX. But it was possible only because I opened the channel myself. Usually such wallets (Green, Relai, Blitz etc) open the channels when users top-up their wallets via LN invoices. In this case, users don't know the actual TXID of their opening transaction, and it may be hard to allocate the closing one.

Sorry, I was pointing out that Blitz could do it, not that the person with the issue could. Did not make myself clear.
As, you pointed out they could possibly do #3 if they had the TXID but that's about it.

The issue can be handled / solved. It's not like the BTC went to an unknown address or something like that.

If Blitz chooses not to help their user that's their choice. But, then people can choose not to use them if issues like this keep coming up.

-Dave