--- Log opened Fri Oct 01 00:00:23 2021 00:12 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has quit [Ping timeout: 252 seconds] 00:12 -!- early [~early@static.38.6.217.95.clients.your-server.de] has quit [Ping timeout: 252 seconds] 00:13 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has joined #c-lightning 00:14 -!- early [~early@static.38.6.217.95.clients.your-server.de] has joined #c-lightning 00:21 -!- kakolainen[m]1 [~kakolaine@2001:470:69fc:105::34f9] has joined #c-lightning 00:21 -!- early` [~early@static.38.6.217.95.clients.your-server.de] has joined #c-lightning 00:21 -!- early [~early@static.38.6.217.95.clients.your-server.de] has quit [Ping timeout: 252 seconds] 00:21 -!- kakolainen[m] [~kakolaine@2001:470:69fc:105::34f9] has quit [Ping timeout: 252 seconds] 00:21 -!- berndj [~berndj@ns2.linksynergy.co.za] has quit [Remote host closed the connection] 00:21 < vincenzopalazzo> willcl_ark: Well, I like to call it "estimation", we can't tell precise the time to confirm a channel I think. this is how c-lightning estimate the fee with the bcli plugin https://bitcoincore.org/en/doc/0.21.0/rpc/util/estimatesmartfee/ 00:22 -!- _aj_ [aj@user/aj/x-5857768] has quit [Ping timeout: 252 seconds] 00:22 -!- _aj_ [aj@cerulean.erisian.com.au] has joined #c-lightning 00:22 -!- _aj_ [aj@cerulean.erisian.com.au] has quit [Changing host] 00:22 -!- _aj_ [aj@user/aj/x-5857768] has joined #c-lightning 00:22 -!- berndj [~berndj@ns1.linksynergy.co.za] has joined #c-lightning 00:23 < vincenzopalazzo> So, I think the urgent it is like the shorter range in terms of the block to have a transaction confirmed. Right now, a transaction with a lower fee is confirmed also in a resonable time (in terms of blocks) 00:33 < vincenzopalazzo> Today, a log of update readme PR :-) 00:36 < openoms[m]> "So, I think the urgent it is..." <- one can do 00:36 < openoms[m]> `bitcoin-cli estimatesmartfee 1` (next block) or `bitcoin-cli estimatesmartfee 6` (estimate in 6 blocks). They are not the same. 00:38 < vincenzopalazzo> > <@openoms:matrix.org> one can do 00:38 < vincenzopalazzo> > `bitcoin-cli estimatesmartfee 1` (next block) or `bitcoin-cli estimatesmartfee 6` (estimate in 6 blocks). They are not the same. 00:38 < vincenzopalazzo> good point here openoms, thanks to catching my bug :) So definitely we can fix this "inconsistency" across doc vs code comments. 00:39 < vincenzopalazzo> usually for me the range [1, 6] it is all the same :-P this is a mind bug I think 00:40 -!- rl-d_ [~administr@170.51.53.197] has joined #c-lightning 00:42 < vincenzopalazzo> rusty are doing hard experiment with BLUEIRON-v0.10.1-215-g4de7a9e node I think :-P it is down again. hope that the #4831 doesn't make bug damage 00:43 < openoms[m]> I have a BROKEN channel with another quite big CL node: https://github.com/ElementsProject/lightning/issues/4698#issuecomment-931734741. just building to the latest master now 00:45 < vincenzopalazzo> openoms: Just reading it now (with my coffee), and I think your journalctl catch a very good info 01:02 < vincenzopalazzo> "I have a BROKEN channel with..." <- BTW, the assert `!channel->option_static_remotekey` looks like that no longer exist on the actual master :/ 01:14 -!- nathanael_ is now known as nathanael 01:26 < openoms[m]> "BTW, the assert `!channel->..." <- yea, updating to the master got rid of the BROKEN things, so it remains like it is for fiatjaf 01:27 < openoms[m]> endless: 01:27 < openoms[m]> `Peer transient failure in CHANNELD_NORMAL: channeld: Owning subdaemon channeld died` 01:40 -!- valwal [~valwal@70.107.207.192] has quit [Read error: Connection reset by peer] 01:41 -!- valwal [~valwal@70.107.207.192] has joined #c-lightning 01:42 -!- kanzure [~kanzure@user/kanzure] has quit [Ping timeout: 252 seconds] 01:43 -!- kanzure [~kanzure@user/kanzure] has joined #c-lightning 02:04 -!- kexkey_ [~kexkey@static-198-54-132-172.cust.tzulo.com] has quit [Ping timeout: 250 seconds] 02:06 -!- kexkey [~kexkey@static-198-54-132-92.cust.tzulo.com] has joined #c-lightning 02:07 -!- valwal3 [~valwal@70.107.207.192] has joined #c-lightning 02:11 -!- berndj-blackout [~berndj@ns2.linksynergy.co.za] has joined #c-lightning 02:12 -!- kanzure_ [~kanzure@user/kanzure] has joined #c-lightning 02:14 -!- valwal [~valwal@70.107.207.192] has quit [Ping timeout: 252 seconds] 02:14 -!- kanzure [~kanzure@user/kanzure] has quit [Ping timeout: 252 seconds] 02:14 -!- berndj [~berndj@ns1.linksynergy.co.za] has quit [Ping timeout: 252 seconds] 02:14 -!- valwal3 is now known as valwal 02:14 -!- rl-d_ [~administr@170.51.53.197] has quit [Remote host closed the connection] 02:15 -!- berndj-blackout is now known as berndj 02:24 -!- rl-d_ [~administr@170.51.53.197] has joined #c-lightning 03:52 -!- rl-d_ [~administr@170.51.53.197] has quit [Ping timeout: 252 seconds] 04:04 -!- rl-d_ [~administr@170.51.51.34] has joined #c-lightning 04:07 -!- sturles_ is now known as sturles 05:10 -!- rl-d_ [~administr@170.51.51.34] has quit [Ping timeout: 252 seconds] 05:12 -!- rl-d_ [~administr@170.51.61.156] has joined #c-lightning 05:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 06:29 -!- Victorsueca [~Victorsue@user/victorsueca] has joined #c-lightning 07:40 -!- kexkey [~kexkey@static-198-54-132-92.cust.tzulo.com] has quit [Ping timeout: 252 seconds] 07:42 -!- kexkey [~kexkey@89.36.78.220] has joined #c-lightning 07:47 -!- kexkey [~kexkey@89.36.78.220] has quit [Ping timeout: 252 seconds] 07:51 -!- kexkey [~kexkey@static-198-54-132-156.cust.tzulo.com] has joined #c-lightning 08:16 -!- sr_gi [~sr_gi@static-43-117-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer] 08:17 -!- sr_gi [~sr_gi@static-43-117-230-77.ipcom.comunitel.net] has joined #c-lightning 08:24 -!- rl-d_ [~administr@170.51.61.156] has quit [Ping timeout: 252 seconds] 08:30 -!- rl-d_ [~administr@170.51.50.183] has joined #c-lightning 08:37 -!- rl-d_ [~administr@170.51.50.183] has quit [Ping timeout: 252 seconds] 08:44 -!- rl-d_ [~administr@170.51.50.231] has joined #c-lightning 11:16 -!- rl-d_ [~administr@170.51.50.231] has quit [Ping timeout: 252 seconds] 11:18 -!- rl-d_ [~administr@170.51.61.180] has joined #c-lightning 11:22 -!- dergoegge [sid453889@id-453889.lymington.irccloud.com] has joined #c-lightning 11:28 -!- rl-d_ [~administr@170.51.61.180] has quit [Ping timeout: 252 seconds] 11:40 -!- rl-d_ [~administr@170.51.53.17] has joined #c-lightning 11:51 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has quit [Quit: The Lounge - https://thelounge.chat] 11:59 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has joined #c-lightning 12:47 -!- kexkey [~kexkey@static-198-54-132-156.cust.tzulo.com] has quit [Read error: Connection reset by peer] 12:49 -!- kexkey [~kexkey@static-198-54-132-156.cust.tzulo.com] has joined #c-lightning 13:03 -!- kanzure_ is now known as kanzure 14:46 < mschmoock> cdecker: any clue why lightningd/options.c line 241 has to prevent to announce two instances of the same address type? Looks like the code checks not to announce like i.e. two IPv4 addresses or two TORv3 addresses etc. The protocol allows that and I see good reasons to have our code be capable of doing this 16:21 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds] 16:33 -!- belcher [~belcher@user/belcher] has joined #c-lightning 21:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 23:28 -!- nathanael [~nathanael@user/nathanael] has quit [Quit: connection reset by purr] 23:34 -!- nathanael [~nathanael@user/nathanael] has joined #c-lightning 23:35 -!- nathanael [~nathanael@user/nathanael] has quit [Client Quit] 23:35 -!- nathanael [~nathanael@user/nathanael] has joined #c-lightning 23:35 -!- nathanael [~nathanael@user/nathanael] has quit [Client Quit] 23:40 -!- nathanael [~nathanael@user/nathanael] has joined #c-lightning --- Log closed Sat Oct 02 00:00:24 2021