--- Log opened Thu Oct 22 00:00:54 2020
00:05 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 272 seconds]
00:25 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has joined #c-lightning
00:46 < sword_smith> az0re: I will check if I have a channel with ACINQ.
00:46 < sword_smith> Thanks.
00:48 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 272 seconds]
00:51 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #c-lightning
00:52 -!- t0mix [~t0mix@78-141-123-99.dynamic.orange.sk] has quit [Ping timeout: 260 seconds]
00:58 -!- jonatack [~jon@37.170.172.122] has joined #c-lightning
01:03 -!- jonatack [~jon@37.170.172.122] has quit [Ping timeout: 264 seconds]
01:04 -!- jonatack [~jon@213.152.161.69] has joined #c-lightning
01:11 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving]
01:16 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has quit [Ping timeout: 240 seconds]
01:21 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has joined #c-lightning
01:28 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has quit [Ping timeout: 265 seconds]
01:31 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
01:35 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
01:48 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
02:05 -!- kexkey [~kexkey@37.120.205.214] has quit [Ping timeout: 264 seconds]
02:05 < m-schmoock> Closure reason and details PR is ready for review ...  https://github.com/ElementsProject/lightning/pull/4126
02:13 -!- belcher_ is now known as belcher
02:49 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has joined #c-lightning
02:56 -!- jonatack [~jon@213.152.161.69] has quit [Ping timeout: 260 seconds]
02:57 -!- jonatack [~jon@37.170.192.187] has joined #c-lightning
03:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
03:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
03:15 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has quit [Ping timeout: 272 seconds]
03:50 -!- wxss [~user@mail.deeplinkmedia.com] has quit [Quit: leaving]
03:51 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 258 seconds]
03:51 -!- wxss [~user@mail.deeplinkmedia.com] has joined #c-lightning
03:53 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
03:53 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
04:18 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has joined #c-lightning
04:18 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #c-lightning
04:32 -!- sr_gi [~sr_gi@static-128-69-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
04:32 -!- sr_gi [~sr_gi@static-128-69-224-77.ipcom.comunitel.net] has joined #c-lightning
05:07 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
05:09 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
05:20 -!- jonatack [~jon@37.170.192.187] has quit [Read error: Connection reset by peer]
05:35 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has quit [Ping timeout: 264 seconds]
05:40 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has joined #c-lightning
06:37 -!- wxss [~user@mail.deeplinkmedia.com] has quit [Quit: leaving]
06:47 -!- jonatack [~jon@37.170.192.187] has joined #c-lightning
06:50 -!- wxss [~user@mail.deeplinkmedia.com] has joined #c-lightning
07:03 -!- fiatjaf [~fiatjaf@2804:7f2:2a84:12c:ea40:f2ff:fe85:d2dc] has quit [Read error: No route to host]
07:24 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
07:37 -!- kabaum [~kabaum@ua-84-216-128-14.bbcust.telenor.se] has quit [Ping timeout: 272 seconds]
07:43 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
07:49 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has quit [Remote host closed the connection]
07:49 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #c-lightning
08:42 -!- sr_gi [~sr_gi@static-128-69-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
08:42 -!- sr_gi [~sr_gi@static-128-69-224-77.ipcom.comunitel.net] has joined #c-lightning
08:55 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
09:27 -!- jonatack [~jon@37.170.192.187] has quit [Read error: Connection reset by peer]
09:28 -!- jonatack [~jon@37.170.192.187] has joined #c-lightning
10:08 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
10:08 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
10:19 -!- jonatack [~jon@37.170.192.187] has quit [Ping timeout: 260 seconds]
10:49 < HelloShitty> Hello peeps. Can we control to which addresses goes our sats when we close channels?
10:49 < zmnscpxj__> yes
10:50 < zmnscpxj__> you can have a plugin that handles the `openchannel` hook and provide a `close_to` addr.
10:52 < zmnscpxj__> And if you are willing to drop down to `fundchannel_start`/`fundchannel_complete` then `fundchannel_start` also exposes a `close_to` address
10:52 < zmnscpxj__> but note that these are settings that are specified on *funding* the channel
10:52 < zmnscpxj__> if you want to specify at *close* time then I think not.
10:53 < zmnscpxj__> Ah, wait, `close` has a `destination` argument
10:55 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning
10:58 < HelloShitty> heheh
10:58 < HelloShitty> I tried once some of those commands
10:58 < HelloShitty> but got errors and then I jus tused fundchannel
10:58 < HelloShitty> but I want to unerstand better these options
11:01 < HelloShitty> zmnscpxj__: and are those plugins installed by default or those options are the ones that we can use out of the box after installing c-lightning?
11:01 <@niftynei> 'close_to' also just got added to fundchannel + multifundchannel; it'll be available in the next release
11:06 < HelloShitty> niftynei: is Rusty, here in IRC, this gentleman: https://www.youtube.com/watch?v=fab4P3BIZxk
11:07 <@niftynei> yep, that's rusty
11:09 -!- jonatack [~jon@213.152.161.170] has joined #c-lightning
11:09 < HelloShitty> ohh, ok. Nice
11:09 < HelloShitty> niftynei: one question: Can I reboot my laptop and keep channels open?
11:10 <@niftynei> channels don't close until you or the peer publish a transaction closing them
11:10 < HelloShitty> I have 2 outbound channels and one inbound channel... Will those channels keep open after 'lightning-cli stop' and reboot?
11:10 < HelloShitty> hum, ok, so it's perfectly safe
11:11 < HelloShitty> That's good
11:11 <@niftynei> rebooting c-lightning will make your channel non-operational (ie payments can't get forwarded through your node) but it shouldn't close the channel
11:11 <@niftynei> unless your peer decides that you disappearing is unacceptable :P
11:11 < HelloShitty> ok. It will take a minute
11:12 < HelloShitty> hope he cannot miraculously gain self-willing
11:12 < HelloShitty> That would be a problem
11:12 < HelloShitty> brb
11:12 <@niftynei> afaik most peers dont' seem to have very requirements wrt channel-partner uptime
11:12 <@niftynei> tchau
11:12 <@niftynei> godspeed
11:14 -!- HelloShitty [~narayan@bl20-171-222.dsl.telepac.pt] has quit [Quit: leaving]
11:14 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
11:16 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
11:18 -!- Ademan [~ademan@47.185.88.223] has quit [Quit: leaving]
11:38 -!- HelloShitty [~narayan@bl20-171-222.dsl.telepac.pt] has joined #c-lightning
11:41 < HelloShitty> ok, I'm back and everything seems to be fine
11:41 < az0re> Hi, Back
11:41 < HelloShitty> :)
11:56 -!- HelloShitty [~narayan@bl20-171-222.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
12:12 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Ping timeout: 256 seconds]
12:15 -!- HelloShitty [~narayan@bl20-171-222.dsl.telepac.pt] has joined #c-lightning
12:20 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
12:21 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
12:29 < HelloShitty> So, about these fundchannel commands available
12:30 < HelloShitty> is it correct to assume tat fundchannel is a set of command such as fundchannel_start and fundchannel_complete? 
12:41 -!- qubenix [~qubenix@66.172.11.228] has quit [Quit: quit]
12:42 -!- qubenix [~qubenix@66.172.11.228] has joined #c-lightning
13:14 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
13:14 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]
13:14 < HelloShitty> niftynei: when we use fundchannel_start, if I don't want to use one of the option arguments, how do I do to use the other arguments after it?
13:23 <@niftynei> there's a way to do it but i can never remember, check out the -k flag which lets you name arguments, e.g. id=8829eab81...
13:24 <@niftynei> also make sure you check the warnings on fundchannel_start -- you should never broadcast the funding tx until AFTER fundchannel_complete has been succesfully called for the peer
13:25 <@niftynei> maybe try putting in 'null' for args you don't want on the command line? i usually just fallback to the keyword arg list
13:26 < HelloShitty> ok, that's quite a lot
13:26 < HelloShitty> I found that the default for feerate is 'normal', so I just used normal
13:27 < HelloShitty> I read about that warning
13:27 < HelloShitty> and it makes me think that there are 3 steps/commands to open a channel and fund it
13:27 < HelloShitty> is this correct
13:28 < HelloShitty> or the warning tells us to wait for the transaction to have 3 confirmations before issuing the fundchannel_complete command?
13:29 < HelloShitty> I can't also find the options available for 'annouce'. I would try 'true' or 'false', but not sure. I can't find the available options for this argument in the docs (lightning-cli help fundchannel_start)
13:31 < HelloShitty> About the flag '-k', you mean something like this: lightning-cli -k feerate=NULL ?
13:33 < az0re> I'm curious why this happened and about my unilateral close.  In `listpeers` I see one of my channels was closed because: "CHANNELD_NORMAL:Bad commit_sig signature ... for tx ... feerate ..."
13:34 < az0re> I guess it was my channel peer's error but shouldn't that... simply never happen?
13:35 < darosior> az0re: ouch please fill an issue
13:35 < darosior> It should not indeed
13:36 < darosior> (assuming your peer is not malicious, which usually isn't and it's a bug in one of the two implems)
13:37 < az0re> Would love to but GitHub won't allow me to sign up over Tor
13:37 < az0re> Happy to send any useful information to you by IRC private message or email, though
13:37 < darosior> arf, yeah i'll fill it for you
13:38 < darosior> Unfortunately for your privacy, we'd need the signature, tx and feerate values
13:38 < darosior> Obviously not going to put them in the issue
13:38 < az0re> Yeah, happy to provide those privately, just don't want them public
13:39 < darosior> But share them with niftynei cdecker and rusty
13:39 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
13:40 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
13:40 < az0re> Sorry about that...
13:40 < az0re> <darosior> But share them with niftynei cdecker and rusty
13:40 < az0re> Will do.  Can you /msg me their email addresses?
13:41 < az0re> Nvm I can see them in the git log
13:41 < darosior> hehe
13:41 < az0re> :)
13:42 < darosior> Just don't want to give false expectations: i can't debug this soonish :/
13:42 < az0re> Don't worry, my expectations do not exist
13:43 < az0re> Just happy to help (eventually) solve an issue
13:43 < darosior> Great, thanks! Opened https://github.com/ElementsProject/lightning/issues/4152 to track this
13:43 < az0re> Unfortunately this channel peer has no contact info :-\
13:43 < az0re> And they probably have more relevant information about what happened
13:44 < darosior> Ah yeah the peer id will be helpful
13:44 < az0re> Cool, thanks, I'll reference that in my email
13:44 < darosior> to deduce their implem
13:44 < az0re> Sure, I'll send the whole peer object from `listpeers`
13:48 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
13:54 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
13:57 < az0re> Also, before my node sends out its OUR_HTLC transaction, how should I best adjust the feerate?
13:58 < az0re> I'm fine with setting the feerate really low and waiting a long time for it to confirm, so long as it doesn't put my funds at risk
13:59 <@niftynei> HelloShitty: you need to call `fundchannel_start`, build a tx but NOT send it, call `fundchannel_complete` with the *correct* info about the funding tx and the output index of the funding output, then broadcast tx
13:59 < az0re> Should I change plugins/bcli.c:505 to replace `stash->urgent` with e.g. `stash->normal`?
13:59 < az0re> (505 is the line for "htlc_resolution")
13:59 <@niftynei> if the only reason you're using fundchannel_start is to access `close_to`, i'd recommend either using the latest master which has this for fundchannel, or waiting til the next release (should be nov 10th)
14:00 < HelloShitty> I'm trying to use the commands to get a bit better comprehension about how the channels work in the background
14:01 < darosior> "so long as it doesn't put my funds at risk" => depending on the situation (which tx and does the peer knows the preimage) it actually does
14:02 < az0re> Hmmmm I see
14:02 < darosior> az0re: Fees are usually critical, so you should not tinker with bcli's internals
14:02 < darosior> And we'll never use urgent for something well not urgent
14:03 < az0re> Well, at least I should come to this channel and announce my boneheaded intentions
14:03 < az0re> :P
14:03 < darosior> As bitcoind is conservative enough wrt to fees :p
14:04 < az0re> In this case, where my node funded the channel and initiated the unilateral close, and I have two in-flight HTLCs in states RCVD_REMOVE_HTLC and SENT_ADD_ACK_REVOCATION, what exactly is at risk?
14:05 < az0re> The combined value of both HTLCs?
14:07 < HelloShitty> niftynei: so, that means that after fundchannel_start and fundchannel_complete, I need to broadcast the transaction from my bitcoin node?
14:07 < HelloShitty> Or is it from c-lightning node?
14:08 < HelloShitty> I just remember that there are some sendtx or sendtraansaction commands in c-lightining
14:11 < az0re> This is important to me because the current estimated urgent fee is ~130ksats, larger than the value locked in either HTLC
14:11 < az0re> I prefer a risk of losing an HTLC value vs. guaranteed losses greater than an HTLC amount
14:20 < az0re> Also this logic should probably be part of the fee selection code.  I never want to guarantee higher losses to urgent/very_urgent fees than the value I put at risk by choosing a lower fee.
14:24 < az0re> Just to be confirm: If my channel peer is not malicious, it should not be a problem to use an arbitrarily low fee, right?  My risk is only that they do something dishonorable to violate the HTLC, right?
14:25 < az0re> s/be confirm/confirm/
14:42 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has quit [Remote host closed the connection]
14:42 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #c-lightning
14:47 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #c-lightning
14:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
14:53 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
14:53 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
14:53 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
14:53 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
14:53 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
14:53 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
14:53 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
14:53 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
14:55 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
15:02 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
15:08 < darosior> "not be a problem to use an arbitrarily low fee, right?" => implementations steal by default (iirc)
15:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
15:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
15:13 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
15:30 < az0re> Really?
15:30 < az0re> :(
15:31 < az0re> Why oh why>
15:31 < az0re> ?
15:32 < az0re> This really sucks then, having to pay over over 10% of the total channel capacity because my peer had an error
15:32 < az0re> With no way around it, apparently
15:36 < darosior> There are, but they are at a protocol level. Interesting discussions related to this on the ML currently,  reducing a node exposure to HTLCs is... Complex to get right to say the least
15:36 < darosior> (It's been discussed for long fwiw, but the complexity is the reason it's not settled yet and thus not implemented)
15:56 < HelloShitty> darosior: what means, when we open a channel, instead of the number of blocks missing for confirmation, usually 3, I have a message saying "CHANNELD_AWAITING_LOCKIN: waaiting for theirs" ??
16:18 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
16:19 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning
17:46 -!- mrostecki_ [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
17:46 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
17:49 < az0re> darosior: I see.  I guess I should get on the mailing list.
17:49 < az0re> Is there any way to tell how much value is at risk of theft?
17:50 < az0re> Even if I'm guaranteed that my channel peer will steal from me, it's totally possible they will steal less than I will pay in `3 CONSERVATIVE` fees.
18:14 < zmnscpxj__> HelloShitty: peer has to sync their view of the bitcoin blockchain as well
18:15 < zmnscpxj__> az0re: `listpeers` should show an `htlcs` field for each channel
18:15 < az0re> Yup I see it, I guess that means that both of my "out" HTLCs are at risk
18:15 < zmnscpxj__> but note that if the peer is offline you cannot change the onchain fees for a channel
18:15 < zmnscpxj__> as the stored commitment transaction (i.e. the unilateral close) is presigned by both parties
18:16 < az0re> But what about the HTLC resolution tx fees?
18:16 < zmnscpxj__> same deal, it is presigned on both sides
18:16 < zmnscpxj__> if you refer to the second-stage transactions
18:17 < zmnscpxj__> though if you are not using second-stage, hmm, I think we just use some multiple of urgent and do not have a way to override that
18:17 < az0re> I'm not sure if I am
18:17 < az0re> I'm referring to (in listpeers): "ONCHAIN:4 outputs unresolved: in 30 blocks will spend OUR_HTLC (...) using OUR_HTLC_TIMEOUT_TX"
18:17 < zmnscpxj__> If you are the one closing unilaterally, HTLCs you claim use a second-stage tx
18:18 < az0re> The HTLC timeout tx is presigned by both parties?
18:18 < zmnscpxj__> yes
18:18 < az0re> I see...
18:18 < zmnscpxj__> HTLC-timeout in bolt 3
18:18 < az0re> Is there any way to inspect this presigned tx before it goes out?
18:19 < zmnscpxj__> You can see its structure in BOLT3, we do not stoer the tx explicitly, only the signature
18:19 < az0re> I will read it again, maybe absorb more info this time
18:19 < zmnscpxj__> we just re-generate the tx I think
18:19 < az0re> So, anyway to regenerate and display that tx?
18:20 < zmnscpxj__> devtools/mkcommit creates a commitment tx, but I do not know if it creates the second-stage txes as well
18:22 < az0re> OK thanks
18:25 < az0re> BTW, is there a state diagram for c-lightning's HTLC implementation?
18:25 < zmnscpxj__> HTLC? do you mean the offchain resolution of HTLCs? or onchain resolution?
18:26 < zmnscpxj__> for offchain HTLC resolution, the nearest you might get is section "Normal Operation" in BOLT2
18:27 < zmnscpxj__> for onchain resolution, none, you have to read onchaind/onchaind.c, sorry
18:28 < zmnscpxj__> the state machines are fairly complicated
18:29 < az0re> For onchain resolution...
18:30 < az0re> Yeah, great :-\
18:30 < zmnscpxj__> sorry
18:30 < zmnscpxj__> but onchain resolution is much simpler
18:30 < az0re> Also, re: this unilateral close I've been talking about
18:31 < zmnscpxj__> if you offered the HTLC in the first place, you just wait out the timeout and broadcast HTLC-timeout
18:31 < az0re> I see two unspent outputs, one in an amount of the HTLC and another in what is likely my channel balance
18:31 < zmnscpxj__> if it gets claimed by someone else with the preimage, you nab the preimage and consider the HTLC fulfilled
18:31 < az0re> But when I do `listfunds`, there is no entry for that channel balance output
18:31 < zmnscpxj__> you just wait it out
18:31 < zmnscpxj__> since unilateral closes have a timeout during which the peer can show you cheated
18:32 < zmnscpxj__> if you did not cheat, nothing to do but wait it out
18:32 < az0re> Oh right
18:32 < zmnscpxj__> (C-Lightning does not cheat by default)
18:32 < zmnscpxj__> you would need to store old state elsewhere
18:32 < zmnscpxj__> so onchaind is mostly just "are we there yet?" all the time
18:33 < az0re> So once HTLC expiry hits I'll see both the HTLC output and that channel balance output in `listfunds`?
18:33 < zmnscpxj__> not yet
18:33 < az0re> Or after self_delay
18:33 < zmnscpxj__> there is still the `self_delay` of the **peer**
18:33 < az0re> OK, got it, thanks
18:34 < zmnscpxj__> our `self_delay` setting applies to the peer, and what applies to us is the `self_delay` of the peer
18:34 < az0re> Yes I forgot that
18:34 < zmnscpxj__> note that the countdown for the main channel balance output started as soon as the commitment tx dropped onchain
18:34 < zmnscpxj__> confirmed onchain
18:34 < az0re> Right
18:35 < zmnscpxj__> if the HTLC was outgoing, you will wait for the HTLC timeout and *then* get the self-delay.
18:35 < az0re> Yup OK
18:35 < zmnscpxj__> before the HTLC timeout, the peer can claim it onchain and your node will treat it as a fulfillment of the channel and resolve any forwards back to upstream
18:36 < az0re> Looks like they're not gonna do that at this point
18:36 < az0re> Or else they would have done it already
18:36 < zmnscpxj__> you might be surprised
18:37 < zmnscpxj__> sometimes the delay in HTLC resolution is just due to a later node going offline
18:37 < zmnscpxj__> and when it comes online, it is able to continue the HTLC resolution
18:37 < az0re> Yeah but this I think is different
18:37 < zmnscpxj__> could be
18:37 < az0re> The weird bad commit_sig caused me to close the channel
18:37 < az0re> And the node is online
18:38 < zmnscpxj__> the HTLC delay could be further downstream
18:38 < az0re> Mmmm I see
18:38 < zmnscpxj__> though if the HTLC is failed at your peer, then it cannot tell you about that fact (and you cannot start  the to-self-delay timer before the HTLC timeout anyway)
18:39 < az0re> But I think this HTLC is just fucked somehow and probably won't resolve downstream
18:39 < zmnscpxj__> yes, that is the most likely thing-to-happen
18:40 < az0re> So this fiasco is costing me way more than that 20ksat mutual close fee I was bitching about before...
18:40 < az0re> I'd really like to see a feature that allows a node operator to set a universal max feerate
18:40 < zmnscpxj__> yes, unilateral closes with HTLCs on the line are painful
18:40 < zmnscpxj__> that would probably require specs change
18:41 < az0re> And if the peer refuses to agree to an HTLC with a too-low feerate, just allow that channel not to be used until congestion improves and the estimated feerates fall under the maximum
18:41 < zmnscpxj__> anyway, the hope is that something like anchor commitments will reduce the HTLC feerates we use
18:41 < zmnscpxj__> an issue we have is that since all the txes are presigned, we have to overestimate the feerates
18:42 < az0re> For sure
18:42 < az0re> But I would also like to be able to say "Mmmm, estimated fee rates are too high right now.  Just don't negotiate HTLCs until the situation improves."
18:42 < zmnscpxj__> with anchor commitments, that issue will disappear, so hopefully unilateral close feerates
18:43 < az0re> Yet again I need to read up on anchor commitments :)
18:43 < zmnscpxj__> you could probably make a plugin that hooks into `htlc_accepted`
18:43 < zmnscpxj__> which at least can prevent you from forwarding the HTLC
18:43 < az0re> Sounds interesting
18:43 < zmnscpxj__> alternately, set your channel routing fees higher during high onchain feerates
18:44 < az0re> Not sure how difficult it would be
18:44 < az0re> I don't think I could possibly adjust the routing fees high enough
18:44 < az0re> Well, unless it's infinity or whatever
18:45 < az0re> I guess that's what you do, set channel fees to infinity or total channel capacity or whatever
18:45 < zmnscpxj__> you might be able to adjust it high enough to defray your costs in case of a unilateral close, but you at least  discourage routing through you
18:45 < az0re> Yeah that should work but if everyone does that it's gonna generate a shitload of gossip traffic
18:45 < zmnscpxj__> you might *NOT* be able to adjust it high enough to defray your costs in case of a unilateral close, but you at least  discourage routing through you
18:46 < zmnscpxj__> onchain feerates do not change suddenly, so just doing this about once an hour should be fine? hmmmm
18:46 < az0re> Well, a unilateral close could happen any time regardless of forwarded payments
18:46 < az0re> So yeah that makes sense
18:46 < zmnscpxj__> indeed
18:47 < az0re> Yeah it doesn't need to happen too frequently
18:47 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #c-lightning
18:47 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
18:48 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
18:48 < zmnscpxj__> should probably include something like that in CLBOSS
18:48 < az0re> Sounds like the mempool watching and setchannelfee approach would be quicker and easier to implement than the `htlc_accepted` hook
18:48 < az0re> yes indeed
18:49 < zmnscpxj__> CLBOSS already monitors onchain feerates anyway, and has a facility for modules to merge their channelfee modifications, so should be doable
18:50 < zmnscpxj__> A precision, before anchor commitments (i.e. today), you only need to do this for channels you funded yourself, as channels you did not fund will have closing fees paid by the peer and not you
18:52 < az0re> So, uh, can I get a preview? :)
18:52 < az0re> I'll help to test it
18:52 < zmnscpxj__> https://github.com/ZmnSCPxj/clboss.git
18:52 < az0re> Cool, thanks
18:53 < zmnscpxj__> I will probably implement the channelfees-based-on-onchain-fees next week, am still wrangling with rebalancing
18:53 < zmnscpxj__> this is not even re-alpha software so caveat emptor
19:34 < az0re> Yeah I understand
19:34 < az0re> Although I'm not buying it, so maybe 'caveat emptor' is not the most apt expression here :)
19:39 <@niftynei> HelloShitty, just seeing this; yes after fundchannel_start + fundchannel_complete you broadcast the funding tx
19:42 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
20:35 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
20:35 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
20:36 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
20:43 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
21:00 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
21:00 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
21:07 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
21:12 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
21:21 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
23:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
23:46 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
--- Log closed Fri Oct 23 00:00:55 2020