--- Log opened Tue Mar 16 00:00:57 2021 05:51 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has joined #c-lightning 05:51 -!- Topic for #c-lightning: Next meeting here @8PM UTC Monday Jan 25 Chat about the C-lightning implementation: https://github.com/ElementsProject/lightning https://lists.ozlabs.org/listinfo/c-lightning Current Version: https://github.com/ElementsProject/lightning/releases/tag/v0.9.3 Logs at http://gnusha.org/c-lightning/ Dev Roadmap: https://github.com/ElementsProject/lightning/wiki 05:51 -!- Topic set by cdecker [~cdecker@mail.snyke.net] [Thu Jan 21 01:57:33 2021] 05:51 [Users #c-lightning] 05:51 [@cdecker ] [ jonasschnelli ] 05:51 [@niftynei ] [ k3tan ] 05:51 [ achow101 ] [ kanzure ] 05:51 [ adam3us ] [ ksedgwic ] 05:51 [ andytoshi ] [ Letze ] 05:51 [ az0re ] [ lio17 ] 05:51 [ belcher ] [ m-schmoock ] 05:51 [ berndj ] [ michaelfolkson] 05:51 [ bitdex ] [ midnight ] 05:51 [ blockstream_bot] [ Nebraskka ] 05:51 [ cryptosoap ] [ Norrin ] 05:51 [ ctrlbreak_MAD ] [ nothingmuch ] 05:51 [ CubicEarth ] [ opsec_x122 ] 05:51 [ darosior ] [ phantomcircuit] 05:51 [ DeanWeen ] [ qubenix ] 05:51 [ devrandom ] [ queip ] 05:51 [ dongcarl ] [ rh0nj ] 05:51 [ drolmer ] [ rny ] 05:51 [ early` ] [ Ron-Na ] 05:51 [ felixweis ] [ rotarydialer ] 05:51 [ fiatjaf ] [ RubenSomsen ] 05:51 [ fjahr ] [ rubikputer ] 05:51 [ Galvas ] [ ShotokanZH ] 05:51 [ ghost43_ ] [ spinza ] 05:51 [ gleb ] [ sr_gi ] 05:51 [ gnusha ] [ t0mix ] 05:51 [ grubles ] [ tigermousr ] 05:51 [ gwillen ] [ vasild ] 05:51 [ harding ] [ Victorsueca ] 05:51 [ HelloShi1ty ] [ warren ] 05:51 [ isenough ] [ willcl_ark ] 05:51 [ Jackielove4u ] [ windsok ] 05:51 [ jb55 ] [ wraithm ] 05:51 -!- Irssi: #c-lightning: Total of 66 nicks [2 ops, 0 halfops, 0 voices, 64 normal] 05:51 -!- Home page for #c-lightning: https://github.com/ElementsProject/lightning 05:51 -!- Channel #c-lightning created Mon Mar 13 17:49:31 2017 05:53 -!- Irssi: Join to #c-lightning was synced in 129 secs 06:10 < kanzure> darosior: oops, just noticed this. email would have reached me quicker. i've turned it back on but need help recovering the lost days. if someone could prepare the files for me that would be very helpful. 06:11 < kanzure> jasan/rusty: thanks for noticing too 06:11 < darosior> kanzure: checking if my bouncer have some 06:14 < darosior> Ok got some, so since the 11th right 06:16 < darosior> kanzure: which mail can i send them to you on ? I have #c-lightning #bitcoin-core-dev #lightning-dev #bitcoin-dev #bitcoin-wizards #bitcoin ##miniscript #rust-bitcoin #joinmarket #electrum ##taproot-activation #revault 06:26 < darosior> Well, sent my logs of the main channels on an address i had already tell me if you need more 06:28 -!- jonatack_ [~jon@37.165.122.66] has joined #c-lightning 06:52 -!- jasan [~j@n.bublina.eu.org] has joined #c-lightning 07:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 264 seconds] 07:07 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 07:12 -!- jonatack_ [~jon@37.165.122.66] has quit [Quit: jonatack_] 07:12 -!- jonatack [~jon@37.165.122.66] has joined #c-lightning 08:01 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 08:03 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 08:12 -!- rny [~rny@gateway/tor-sasl/renlord] has quit [Remote host closed the connection] 08:12 -!- sr_gi [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer] 08:12 -!- rny [~rny@gateway/tor-sasl/renlord] has joined #c-lightning 08:12 -!- sr_gi [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #c-lightning 09:44 -!- fiatjaf [~fiatjaf@2804:7f2:2a8c:f814:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 260 seconds] 09:44 -!- fiatjaf [~fiatjaf@2804:7f2:2a8c:f814:ea40:f2ff:fe85:d2dc] has joined #c-lightning 09:46 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has left #c-lightning [] 09:47 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has joined #c-lightning 10:20 -!- mrostecki [mrostecki@nat/suse/x-nlycqglaotxrnwbd] has joined #c-lightning 11:14 -!- fiatjaf [~fiatjaf@2804:7f2:2a8c:f814:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 260 seconds] 11:15 -!- fiatjaf [~fiatjaf@2804:7f2:2a8c:f814:ea40:f2ff:fe85:d2dc] has joined #c-lightning 11:26 -!- jasan [~j@n.bublina.eu.org] has quit [Quit: Bye!] 11:30 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection] 11:31 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #c-lightning 11:44 < az0re> "Master said send error channel [...]: Offered HTLC [#] SENT_ADD_ACK_REVOCATION cltv [block] hit deadline", and channel transitioned to AWAITING_UNILATERAL 11:45 < az0re> Can someone please help me understand what went wrong? 11:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 11:59 < az0re> Hey rusty 11:59 < az0re> "Master said send error channel [...]: Offered HTLC [#] SENT_ADD_ACK_REVOCATION cltv [block] hit deadline", and channel transitioned to AWAITING_UNILATERAL 11:59 < az0re> Can someone please help me understand what went wrong? 11:59 < rusty> az0re: the other side didn't close the HTLC in time, so we had to go onchain to do it. 12:00 < az0re> Was that really necessary? :( 12:00 < az0re> I would like to be a bit more lenient if it's not a big security risk 12:01 < az0re> Anyway, my channel is now stuck in AWAITING_UNILATERAL, my channel (ex-)peer does not appear to be broadcasting their unilateral close, and `lightning-cli close` gives me an error because my channel is already in AWAITING_UNILATERAL. 12:01 < az0re> Any advice for me? 12:02 < rusty> az0re: you should be broadcasting it already? 12:02 < az0re> Does AWAITING_UNILATERAL mean that *we've* broadcasted it? 12:02 < az0re> i.e. AWAITING_UNILATERAL_CONFIRMATION ? 12:04 < az0re> It would be great if there was a channel state diagram describing the implemented state machine and using the C-Lightning state names 12:04 < rusty> az0re: yes, exactly. 12:05 < az0re> Bummer. 12:05 < rusty> az0re: yes. Your peer has completely died it seems, with an HTLC in flight. That's hard to recover from! 12:07 < queip> hmm some things are hard to recover from in LN? but it is guaranteed he will get his money back just later? 12:07 < rusty> queip: yes, his node is holding a valid transaction at all times. So it just gave up on the unresponsive peer and broadcast it. 12:08 < az0re> Did they just transiently go offline with an HTLC in-flight or something? Is there a risk they can steal the HTLC or could I tweak my node to be more lenient about such failures? 12:08 < queip> rusty: will this auto-resolve, or is there any risk of funds being lost in case if node admin is not around to fix manually? 12:08 < rusty> queip: autoresolve. 12:09 < queip> (assuming the node will be though online from time to time, as required for retribution etc) 12:09 < queip> k 12:09 < rusty> az0re: not transient, they need to be gone for quite a few blocks. 12:09 < queip> are watchtowers automatically supported yet? or at least, if I have 3 compouters can I tell them to protect one-another (as watchtowers)? 12:10 < rusty> az0re: I assume they are still unreachable? You can look up the scratch_txid and see what's happening with that tx. 12:10 < az0re> Since I'm once again paying a princely sum for yet another unilateral close, I would like to set my max_acceptable commitment feerate to the `normal` rate instead of `very_urgent`. My only risk here is that my peers close my channels if my max_acceptable is below their min_acceptable, right? 12:10 < az0re> Thanks, I will do that. 12:10 < az0re> I think the block generation rate was particularly high, so they might not have been gone that long 12:10 < rusty> queip: there is a watchtower plugin, but I haven't run the server side (there's a public one at eye of satoshi tho) 12:11 < az0re> I mean, they were certainly marked as 'online' at least up until a dozen or so blocks before the crash, and probably even later 12:12 < rusty> az0re: the risk is that you don't get your tx in time and they cheat you of the HTLC. Though you can extend your timeout ('cltv-delta'), and probably change things to reduce the fee. THe real trick is for me to finish anchor_outputs so we can adjust the fee dynamically after we close, rather than guessing it. 12:13 < az0re> (and also set my unilateral feerate to `slow` instead of `urgent`) 12:13 < az0re> Agreed WRT anchor outputs solving the fee issue, but until they're here I need to mitigate 12:13 < az0re> I keep getting burned 12:15 < az0re> Also please help me understand more, if you don't mind: What happened was I offered an HTLC, they accepted the offer and we both updated the commitment tx, then the payment failed and I tried to revoke the HTLC after the timeout but my peer did not respond, leaving me stuck with a commitment tx with this HTLC dangling. 12:15 < az0re> Is that right? 12:16 < az0re> Aha, it's the CLTV delta the controls the HTLC lockout time. That finally just clicked for me :) 12:23 < rusty> Sorry, fully occupied in ##taproot-activation, and it's 5:30am here 12:33 < rusty> az0re: yeah, your peer needs to close the HTLC before timeout, and didn't. That's v. bad. 12:48 < az0re> Sorry rusty... FYI you can feel free to ignore me, at least when it's 5:30AM lol 12:49 < az0re> Thanks a lot for the explanations, though 13:03 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #c-lightning [] 13:44 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection] 14:31 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning 14:52 -!- jonatack_ [~jon@37.171.42.2] has joined #c-lightning 14:56 -!- jonatack [~jon@37.165.122.66] has quit [Ping timeout: 264 seconds] 15:20 < kanzure> darosior: thank you 15:35 -!- Netsplit *.net <-> *.split quits: queip 15:36 -!- Netsplit over, joins: queip 16:50 -!- mol [mol@gateway/vpn/protonvpn/molly] has joined #c-lightning 18:10 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has left #c-lightning [] 18:10 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has joined #c-lightning 18:28 -!- rny [~rny@gateway/tor-sasl/renlord] has quit [Remote host closed the connection] 18:30 -!- rny [~rny@gateway/tor-sasl/renlord] has joined #c-lightning 19:00 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...] 19:12 -!- spinza [~spin@102.132.245.16] has joined #c-lightning 19:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 19:57 < fiatjaf> if I call 'pay' and the payment gets stuck for one week, at which point will 'pay' return? after one week? 20:18 < rusty> fiatjaf: yep. We used to have an async one which returned after a little white and then you'd poll paystatus, but that API confused everyone... 20:19 < fiatjaf> yes, I know I was confused 20:19 < fiatjaf> I'm still confused, that's why I'm asking 20:19 < fiatjaf> but I can still close the socket if I want and the payment attempts continue in the background, right? 20:20 < fiatjaf> also, if one payment attempt is taking more than retry_for to resolve it will be the last attempt, right? 20:41 < rusty> fiatjaf: yeah, in normal case we'll time out. And of course, you can close, lightningd will keep tracking it (this is true for all cmds) 21:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 21:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning 21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 21:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 22:00 -!- jonatack_ [~jon@37.171.42.2] has quit [Ping timeout: 256 seconds] 22:19 < warren> Is there currently a way to pay an invoice with retries but only from a channel that you specify? 22:20 < warren> Harder: Possible to temporarily pause one of your channels so an incoming payment comes by other routes? 22:22 < warren> A-B-C where A-C are directly connected. If I want to guarantee that A-C will not be used and it instead goes by multihop A-B-C or C-B-A 22:41 < az0re> Hey rusty: According to niftynei you're working on something to avoid immediately spending the DELAYED_TO_US CheckSequenceVerify-encumbered unilateral close output and spend it later like any other UTXO in the wallet. 22:42 < az0re> Until that's done, is there a quick hack I can do to avoid spending that output right now, without screwing anything up, such that in the future when this feature is complete, I will be able to spend it without issue? 22:46 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection] 23:05 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning 23:05 < az0re> Shit, sorry, got disconnected 23:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] 23:37 < warren> "avoid immediately spending the DELAYED_TO_US CheckSequenceVerify-encumbered unilateral close output and spend it later like any other UTXO in the wallet." <--- Curious to learn more about this. 23:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 23:44 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection] 23:44 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #c-lightning --- Log closed Wed Mar 17 00:00:58 2021