Not possible to remove hosted channel or drain it

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.

[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.

[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.