--- Log opened Wed Jun 16 00:00:39 2021
00:13 -!- jackielove4u [uid43977@user/jackielove4u] has joined #c-lightning
00:32 -!- gijswijs [~gijswijs3@60.51.27.106] has joined #c-lightning
00:39 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 244 seconds]
02:31 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Quit: Bridge terminating on SIGTERM]
02:31 -!- openoms[m] [~openomsma@2001:470:69fc:105::c2f] has quit [Quit: Bridge terminating on SIGTERM]
02:31 -!- Dan[m] [~drobertsm@2001:470:69fc:105::c80] has quit [Quit: Bridge terminating on SIGTERM]
02:31 -!- ChristianDecker[ [~cdeckerma@2001:470:69fc:105::2e8e] has quit [Quit: Bridge terminating on SIGTERM]
02:31 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Quit: Bridge terminating on SIGTERM]
02:31 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Quit: Bridge terminating on SIGTERM]
02:34 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #c-lightning
02:38 -!- openoms[m] [~openomsma@2001:470:69fc:105::c2f] has joined #c-lightning
02:38 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #c-lightning
02:38 -!- Dan[m] [~drobertsm@2001:470:69fc:105::c80] has joined #c-lightning
02:38 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined #c-lightning
02:38 -!- ChristianDecker[ [~cdeckerma@2001:470:69fc:105::2e8e] has joined #c-lightning
02:56 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 244 seconds]
02:58 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has joined #c-lightning
03:05 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
04:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
04:41 -!- gijswijs [~gijswijs3@60.51.27.106] has quit [Ping timeout: 240 seconds]
04:52 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 252 seconds]
05:37 -!- gijswijs [~gijswijs3@60.51.27.106] has joined #c-lightning
07:11 -!- gijswijs [~gijswijs3@60.51.27.106] has quit [Ping timeout: 268 seconds]
11:06 -!- belcher_ [~belcher@user/belcher] has joined #c-lightning
11:07 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 244 seconds]
11:11 -!- belcher_ is now known as belcher
16:40 -!- rusty [~rusty@203.221.41.134] has joined #c-lightning
16:52 -!- jarthur [~jarthur@2603-8080-1540-002d-d88a-0d46-4103-a0ae.res6.spectrum.com] has joined #c-lightning
18:34 < warren> Someone unknown to me opened a large-ish private channel toward our node, drained it, and it's been stuck that way for months. If I understand this correctly nothing will naturally route outbound through a private channel. So what motivation do I have to keep this channel open that ties up a part of our capital?
18:37 < warren> mschmoock: I've found Tor severely slows down routing attempts for some peers and often completely breaks ability to route at all for other peers. I've been declining peer requests from tor-only nodes for this reason. Previously operated a node as tor-only but switched it to IPv4 with reverse VPN NAT as a frontend in order to improve reliability.
19:13 < niftynei> warren: sounds like a close candidate to me
19:14 < rusty> warren: hmm, so they actually pushed significant funds in then, if they opened it.  Perhaps they made a large payment to the store?  But yes, if it's at reserve, might as well close it.
19:36 -!- jarthur [~jarthur@2603-8080-1540-002d-d88a-0d46-4103-a0ae.res6.spectrum.com] has quit [Quit: jarthur]
19:38 < warren> If I have a LN invoice is there a way to attempt to pay it exclusively with one particular outbound channel and otherwise fail if it can't?
19:42 < rusty> warren: not easily.  You can manually create a route (or getroute from your neighbor and prepend the first channel) then use that on sendpay directly.  
19:43 < rusty> (The rebalance plugin basically does this).
19:46 < warren> rusty: sendpay would MPP greater than 2^32 msats across that one channel in this case?
19:46 < rusty> warren: no, no MPP, sendpay is too low-level.
19:46 < warren> ok, so there's no way to ensure a MPP will take only one particular outbound channel?
19:46 < rusty> warren: not without doing MPP by hand, no :)
19:47 < rusty> You do not want to do this.  Easier to hack the pay plugin to allow addition of exclusions and have an arg to exclude all the other channels.
19:47 < rusty> warren: I'm curious why you're doing this though?
19:48 < warren> it's paying the neighbor directly for rebalancing the channel to 50% in this case. I'm guessing "pay" with maxfeepercent set very low would exclude other routes from accidentally being used?
19:49 < rusty> warren: ah, do channel is non-wumbo?
19:49 < warren> wumbo channel
19:49 < rusty> warren: then why mpp?
19:49 < rusty> warren: ah, wait, we still have the HTLC restriction, sorry.
19:50 < warren> oh I thought you're limited by 2^32 msats per part
19:50 < rusty> Right, OK.  Hmm, it *should* prefer the direct path.  I'd really like a 'dryrun" arg to pay for this, so you can see what it'd actually do.
19:50 < warren> yeah that would be helpful and increase confidence
19:51 < rusty> It will not try too many HTLCs through the same path at once, so a naive pay may not do the obvious thing.
19:52 < warren> lightning-cli pay <INVOICEHERE> -k maxfeepercent=SMALLNUMBER  (does the syntax work this way? i haven't used -k much)
20:03 < rusty> warren: yes.
20:04 < rusty> warren: try maxfeepercent=0 first, actually. 
20:05 < rusty> We kind of take the fee into account, but only as a guide: the theory is that you're using fees to direct traffic, so you presumably wanted to pay some attention to them even if you're not paying them to yourself.  But I *think* that w check maxfee afterwards, so all good..
20:07 < warren> maxfeepercent= in the rebalance plugin seems to be a hard cap or similarly a guide?
20:09 < warren> rusty: the party who opens the channel pays 100% of closing fees in all situations?
20:09 < rusty> warren: yes.
20:10 < rusty> warren: I think rebalance uses it for sanity check (since it's obv going to pay fees to drive funds in a circle!)
20:14 < warren> not obviously, you could have cooperation of the circle to drop fees to zero for a moment
20:15 < rusty> warren: yes, but we don't have that today.  There was a loose proposal by Rene Pickhardt to have a local chatter about such a thing, but never got to a solid proposal that I know of.
20:23 < warren> # lnc pay lnbcXXXXX -k maxfeerate=0
20:23 < warren> lightning-cli: Expected key=value in 'lnbcXXXXX': Success
20:23 < warren> rusty: i did something wrong?
20:23 < warren> "Successs" is confusing there
20:24 < warren> ooh it was a mistake to use pay without maxfeerate ... ugh
20:25 < warren> thankfully it expired
20:48 < warren> I'm doing this -k syntax wrong. Any suggestions?
20:50 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
20:54 < warren> oh it's maxfeepercent ... but that still isn't the syntax
20:56 < warren> hmm, it isn't trying to do the MPP over only that one channel
21:00 < warren> rusty: 2021-06-17T03:59:44.648Z INFO    plugin-pay: cmd 18080 partid 0: Payment fee constraint 0msat is below exemption threshold, allowing a maximum fee of 5000msat
21:09 < rusty> warren: ah, crap I forgot exemptfee=0
21:09 < rusty> Oh, and -k applies to everything, so you need bolt11=lnbc....
21:26 < warren> maxfeepercent=0 and exemptfee=0 seems to do what I want, but it still looks like it is trying to iterate through all other channels. Is it even possible to MPP like 30 million sats on one channel?
21:32 < rusty> Hmm, it will cap the number of HTLCs, depending on the channel.  This is more cdecker's area than mine though.
21:36 < warren> cdecker: If you have a 60 million sat channel imbalanced toward you, and you want to manually balance it by paying a single 30 million sat invoice, is there a way to force the MPP to happens only via that one channel? Is there a way to avoid iterating through all other possible channels?  (sendpay can use a specific route but it is limited to 4 million sats)
21:48 < warren> For now I asked him to send me a dozen invoices of 4,000,00X sats where X is the serial number LOL.
21:53 < rusty> warren: ha, actually, I think this will work.  for i in `seq 30`; do lightning-cli sendpay '[{"id": N, "channel": C, "direction": 0, "amount_msat": "1000000sat", "delay": D, "style": "tlv"]' H "sendpay-manual-$i" 30000000sat BOLT11 S $i; done
21:53 < rusty> N = nodeid
21:53 < rusty> C = channelid to node
21:53 < rusty> D = delay from BOLT11 invoice, plus one.
21:53 < rusty> H = payment_hash from invoice
21:53 < rusty> S = payment_secret from invoice
21:54 < rusty> BOLT11 = the actual bolt11 string
21:54 < rusty> warren: maybe I should test first?
21:57 < warren> lol I'm afraid
21:59 < rusty> warren: doign it now
22:02 < warren> If the bolt11 has a particular amount encoded then you'd need the last amount_msat to be the remainder right?
22:05 < rusty> warren: wel, I'm literally sending 1M in 30 parts here.  sendpay wants to know the total for a few reasons, but particularly so it can ensure you don't overpay.
22:20 < rusty> warren: ok, after some pebcak, I think I have it working.  One final tet.
22:21 < warren> plugin possible? I'm afraid
22:21 < warren> I should be working on X but I'm instead manually optimizing channels for negligible benefit.
22:23 < rusty> warren: naah, it's easy.  I was right.
22:25 < rusty> 1. lightning-cli decodepay $BOLT11
22:27 < rusty> 2. Check invoice amount is actually 30,000,000,000msat!
22:28 < rusty> 3. for i in `seq 30`; do l1-cli sendpay '[{"id": @payee@, "channel": "1x1x1", "direction": 0, "amount_msat": "1000000sat", "delay": @min_final_cltv_expiry + 1@ "style": "tlv"}]' @payment_hash@ "sendpay-manual2-$i" 30000000sat $BOLT11 @payment_secret@ $i; done
22:28 < rusty> Fill in the @@ from the decodepay results.
22:29 < rusty> (Yes, channel" 1x1x1 is a dummy, so is direction: they're not actually used for first hop)
22:30 < rusty> Oh, and replace l1-cli with lightning-cli.
22:30 < rusty> You can check the result with "lightning-cli listsendpays $BOLT11" and look for "status: complete"
22:30 < rusty> warren: ^
22:33 < warren> thanks!
22:35 < warren> rusty: btw can we adopt an official abbreviation for c-lightning like cln or lnc. Then searching Google for c-lightnign specific syntax examples for different situations would actually work. Right now it is unsearchable due to name collision.
22:35 < rusty> warren: lightningd?
22:36 < warren> sure but you can't use that as a search term. you only use lightningd once to launch the daemon. It also isn't a keyword that people typically put on various pages. They usallly call it c-lightning which isn't recognized as a unique search term.
22:38 < rusty> warren: yes, but there has been talk of rebranding, and that makes sense.
22:38 < warren> cln or lnc are my favorites personally. I use them as command line alias shortcuts.
23:21 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 268 seconds]
--- Log closed Thu Jun 17 00:00:40 2021