--- Log opened Fri Dec 17 00:00:03 2021
00:11 < valwal> cdecker[m]: would love to get your input on this convo with tbast: https://github.com/lightning/blips/pull/5#discussion_r766451691 
00:12 < valwal> no rush cuz holidays but wasn't sure if the blips repo was on your radar
01:04 < cdecker[m]> Sorry for the delay @valwal, I commented on the issue. I keep forgetting we bundled the total amount with the secret, which is kinda important for MPP keysend. Would be cool to get MPP keysend back working, but that may require a new featurebit, since lnd never supported it (for that matter they completely ignored featurebits for keysend opting for a fire-and-forget approach which I found weird tbh)
01:43 -!- nathanael [~nathanael@user/nathanael] has left #c-lightning []
02:03 -!- kexkey [~kexkey@static-198-54-132-121.cust.tzulo.com] has quit [Ping timeout: 252 seconds]
02:04 -!- kexkey [~kexkey@static-198-54-132-105.cust.tzulo.com] has joined #c-lightning
06:28 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #c-lightning
07:21 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
07:22 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #c-lightning
09:40 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #c-lightning
10:02 < ghost43> given c-lightning only supports one channel per node, if one closes a channel, how many confirmations are needed before a new channel can be opened with the same node?
10:06 < valwal> cdecker[m]: the blip specifies that feature bit 55 will indicate keysend support. do you mean we should have a separate separate keysend feature bit for mpp-keysend? 
10:06 < valwal> thanks for your response :) 
10:06 < valwal> on the PR
10:15 < cdecker[m]> ghost43: it should be possible to open a new channel as soon as `ONCHAIND` takes ownership of the closing channel. I.e, the only downtime is if we ourselves initiated the close, it is unilateral and the close doesn't have a confirmation yet, in all other cases it should be possible to fund a new one
10:16 < cdecker[m]> valwal: indeed, MPP-keysend is a different keysend flavor imho, requiring opt-in from the recipient. Generic opt-in using featurebit 55 would be ok, if that meant that all implementations agree on the flavors that this entails. But if lnd isn't using featurebit 55 at all then it should be ok to just collapse them into a single featurebit
10:20 < ghost43> cdecker[m]: I see. thanks
10:21 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Changing host]
10:21 -!- jb55 [~jb55@user/jb55] has joined #c-lightning
10:21 -!- jb55 [~jb55@user/jb55] has quit [Quit: jb55]
10:22 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #c-lightning
10:22 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Changing host]
10:22 -!- jb55 [~jb55@user/jb55] has joined #c-lightning
10:29 < laanwj> there's a lot of talk about balancing channels, but what's the best way to 'unbalance' a channel before closing (so that all the on-chain funds go in one direction), assuming both nodes are under your control? simply paying an invoice for the remaining value on the channel doesn't seem to work (runs into complaints about channel capacity / HTLC fee)... i guess you could just keep trying based
10:29 < laanwj> on an estimate, but is there an easier way?
10:40 < cdecker[m]> I'm afraid the spec doesn't really allow single-output closes if you ever went above 1% of the channel capacity and that's above the dust threshold. The reason is that in order to keep the parties honest we don't allow them to dip below the reserve, this reserve will result in a direct output to both parties. There are mechanisms to declare higher than dust as dust (this being the prime example where that second output is uneconomical),
10:40 < cdecker[m]> but afaik they're not exposed in any implementation yet, due to the "where did my money go" issue that this could end up causing :-)
10:41 < cdecker[m]> eltoo doesn't have reserves, which would then allow full use of the channel's balance, not just 98%, thanks to not requiring penalties
10:41 < laanwj> would it work to close with the other party's close address? or would that still generate a transaction with two outputs to the same address :)
10:42 < laanwj> thanks for the explanation
10:43 < cdecker[m]> Yeah, that'd still be 2 outputs, but I like the idea. Needs signalling either way so we could just add a parameter to the close negotiation, forfeiting all amounts below X for example
10:54 < valwal> cdecker[m]: thanks, that makes sense. i believe lnd isn't advertising the keysend feature bit atm 
11:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving]
11:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #c-lightning
12:28 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has quit [Remote host closed the connection]
12:28 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has joined #c-lightning
14:57 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 276 seconds]
15:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
18:32 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 276 seconds]
19:39 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #c-lightning
19:41 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
20:18 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
--- Log closed Sat Dec 18 00:00:04 2021