Not possible to remove hosted channel or drain it

[rkfg]

Today I updated SBW and noticed there's a second channel that I never opened, a hosted channel. There are no details about it so I had to look around the main site to understand what this is. Ok, it's a sort of a custodial channel. The problems are:

• I never asked for it
• the way to remove it isn't obvious (swipe right); there's a menu item to close the channel for regular channels, I suggest adding the same item for the hosted channels
• this channel is prioritised over my own real private channel (my inbound capacity is shown as 2m sats, the capacity of this hosted channel, while I also have my own channel of 1m sats), I sent 100 sats to SBW and they ended up in this channel instead of my own, also in the decoded invoice my channel isn't even mentioned
• when I try to drain it using the provided option the app crashes with this trace:

  java.lang.IllegalArgumentException: requirement failed: amount is not valid
  at scala.Predef$.require(Predef.scala:224)
  at fr.acinq.eclair.payment.PaymentRequest$$anonfun$10.apply(PaymentRequest.scala:43)
  at fr.acinq.eclair.payment.PaymentRequest$$anonfun$10.apply(PaymentRequest.scala:43)
  at scala.Option.foreach(Option.scala:257)
  at fr.acinq.eclair.payment.PaymentRequest.<init>(PaymentRequest.scala:43)
  at fr.acinq.eclair.payment.PaymentRequest$.apply(PaymentRequest.scala:143)
  at immortan.ChannelMaster.makePrExt(ChannelMaster.scala:252)
  at immortan.ChannelMaster.localSendToSelf(ChannelMaster.scala:263)
  at com.btcontract.wallet.ChanActivity.drainHc(ChanActivity.scala:291)
  at com.btcontract.wallet.ChanActivity$$anonfun$onChoiceMade$4.apply(ChanActivity.scala:257)
  at com.btcontract.wallet.ChanActivity$$anonfun$onChoiceMade$4.apply(ChanActivity.scala:257)
  at com.btcontract.wallet.BaseActivity$$anonfun$3.apply$mcV$sp(BaseActivity.scala:239)
  at com.btcontract.wallet.BaseActivity$$anon$5.onClick(BaseActivity.scala:181)
  at android.view.View.performClick(View.java:7161)
  at android.view.View.performClickInternal(View.java:7133)
  at android.view.View.access$3500(View.java:804)
  at android.view.View$PerformClick.run(View.java:27416)
  at android.os.Handler.handleCallback(Handler.java:883)
  at android.os.Handler.dispatchMessage(Handler.java:100)
  at android.os.Looper.loop(Looper.java:241)
  at android.app.ActivityThread.main(ActivityThread.java:7604)
  at java.lang.reflect.Method.invoke(Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:941)

It's a bad UX when something suddenly appears and forced upon the user even if I never asked for it. A better UX is showing this new feature after update and asking if the user wants to try it out + let me easily turn it off if I don't like it.

All that said I fully understand that for some users who don't care about the underlying blockchain security this might be a viable option. These channels are free and ready to be used instantly after all.

[akumaigorodski]

I never asked for it

Agreed, a chosen approach of just implanting it is a bit aggressive but I wanted a wallet to be immediately usable for those who don't care about non-custodial stuff, hence this. To compensate for this there's a draining ability and distinguishable HC channel card so it at least can be spotted and get rid of easily.

the way to remove it isn't obvious (swipe left); there's a menu item to close the channel for regular channels, I suggest adding the same item for the hosted channels

There are two ways to close a normal channel (cooperative and force-close) but only one way to remove an HC so I wanted that red button to still be functional for it and putting the same removal option to menu seemed redundant. I'll think more about this, maybe HC removal red button can stand out a bit and be visible by default.

also in the decoded invoice my channel isn't even mentioned

This is a bug which is now fixed in https://github.com/btcontract/wallet/commit/463f952d3a13d6d467a00d6bc884378aeb304c45.

when I try to drain it using the provided option the app crashes with this trace

This is another bug which is now also fixed in https://github.com/btcontract/wallet/commit/71351f50dfc9655a0063ee93c5157d061f795834. Although once HC capacity gets down to ~20 SAT it will become undrainable, but at least there will be a warning instead of crash.

Both of these bugs should be gone in 2.1.14-75.

[rkfg]

Thanks a lot!

but I wanted a wallet to be immediately usable for those who don't care about non-custodial stuff, hence this.

Maybe only add it if there are no channels already open then? That would fix both issues at once.

I wanted that red button to still be functional for it and putting the same removal option to menu seemed redundant. I'll think more about this, maybe HC removal red button can stand out a bit and be visible by default.

I see. Yes, since it's all virtual it can't be closed in two ways. And hiding the red button would be inconsistent with other channels. Does closing it drain it actually or would I lose all my sats in it?

Although once HC capacity gets down to ~20 SAT it will become undrainable, but at least there will be a warning instead of crash.

Hmm, this is strange. Isn't it just a balance stored in a separate database? Why impose such a limit? I know the motivation of having some amount reserved in regular channels (1% by default) but here we have an arbitrary balance that can be spent using whatever channels the node has.

I have 90+ sats there and couldn't drain it, from the PR I suppose the previous limit was 100 sats so that explains it. I'll try it in the next update.

[akumaigorodski]

Maybe only add it if there are no channels already open then?

Seems like a good compromise, will implement in next update.

Does closing it drain it actually or would I lose all my sats in it?

In principle it does nothing to funds: channel data just gets erased from phone and HC can later be fully restored by reconnecting to Host node. SBW automatic HCs are opened with node 021e7ea08e31a576b4fd242761d701452a8ac98113eac3074c153db85d2dcc7d27@lightning-wallet.com:9001 so that's the one to connect to and restore them if user changes phone for example (provided that same mnemonic is used). But of course once HC with balance is removed that balance will be gone in a wallet until HC is restored.

Hmm, this is strange. Isn't it just a balance stored in a separate database? Why impose such a limit? I know the motivation of having some amount reserved in regular channels (1% by default) but here we have an arbitrary balance that can be spent using whatever channels the node has.

There's no kind of reserve for HC indeed, 20 SAT is just SBW's minimal expected off-chain fee since it does not know what the fee will be until payment is started. An alternative to this is, say, allow to withdraw everything but then see payment most likely failed because there is no space left for any fee.

[rkfg]

There's no kind of reserve for HC indeed, 20 SAT is just SBW's minimal expected off-chain fee since it does not know what the fee will be until payment is started.

Okay, sounds reasonable. However, for a real channel you can always get the reserve back if you close it, the reserve limit is only enforced in the protocol but not on chain. Does draining actually return you the entire HC balance (minus unknown fee) or are those 20 sats locked forever? It's not a significant amount (for now!) but would be good to know. I realize that if you let anyone drain the full balance then your node might overpay the fees which opens a possibility to exploit this to drain sats continuously.

I think in the future a good approach would be probing the route first with 99% of the amount (using random preimage/payhash) to know if there's enough liquidity on the route for this amount. If we get "invalid payment details" then the liquidity is there. Then we know it should succeed, we can suggest the user the amount they can withdraw (full amount - total routing fee for this amount). There's still a small chance of failure because we used 99% when probing (and 1% was reserved for the fees) and the final amount will be slightly higher given that the actual routing fee is <1%. But I guess most of the time it will be accurate enough and if it won't succeed we can retry probing ignoring the failed channel.

[rkfg]

I updated the app and drained the HC, 17 sats were left there and can't be withdrawn. Removing and adding the HC is easy now (although a nitpick would be that after removing it I can't immediately add it back, there's no "Request hosted channel" button until I go to the main screen and back into the channels list). The generated invoice includes both channels (if HC is active) now and mine is at the top. I don't know if it affects the pathing algorithms of other wallets but it's there and it's all good.

Thanks for fixing these issues so quickly! I appreciate it.