--- Log opened Fri Jul 21 00:00:05 2023
00:59 -!- b_101_ [~robert@static-198-54-129-102.cust.tzulo.com] has joined #lightning-dev
01:00 -!- riclas [~riclas@26.27.71.148.rev.vodafone.pt] has joined #lightning-dev
01:00 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has quit [Ping timeout: 244 seconds]
01:06 -!- riclas [~riclas@26.27.71.148.rev.vodafone.pt] has quit [Ping timeout: 250 seconds]
01:32 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
01:36 < vincenzopalazzo> I found this nice use case in core lightning tests while implementing a verifying logic inside the announcement_signatures. What should happen when a chain reorg happens on our part before sending the announcement_signatures? In our code base, a test was to normalize the short channel id to the canonical one. But this does not match so well will the announcement_signatures verification because the announce_channel that we
01:36 < vincenzopalazzo> will go to build will diverge inside by the short_channel_id
01:39 < vincenzopalazzo> and from BOLT 7 suggest the following 
01:39 < vincenzopalazzo> if the short_channel_id is NOT correct:
01:39 < vincenzopalazzo> SHOULD send a warning and close the connection, or send an error and fail the channel.
02:28 < vincenzopalazzo> How others implementation handle this? by a rapid take a look, I guess idk reject the announcement signatures but not sure about this, because the library can do other things before
02:34 -!- greypw2546002161 [~greypw254@grey.pw] has quit [Quit: I'll be back!]
02:34 -!- greypw2546002161 [~greypw254@grey.pw] has joined #lightning-dev
03:16 < _tnull> <vincenzopalazzo> "How others implementation handle..." <- I think your understanding is correct: we would fail the channel in case the signatures do not match.
03:28 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev
03:30 < vincenzopalazzo> Good, thanks for checking
03:31 -!- Jackielove4u [uid43977@user/jackielove4u] has joined #lightning-dev
03:32 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 260 seconds]
03:33 < vincenzopalazzo> IMHO failing the channels make sense because if one of the nodes is under chain reorg we can disagree also on update_fee later when the channel will be announced. Mh wondering if there is any thought on this and if we should allow a way to open a channel also during chain reorg? Maybe this is a good ML post
04:22 -!- riclas [~riclas@26.27.71.148.rev.vodafone.pt] has joined #lightning-dev
06:06 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:09 -!- Chris_St1 [~Chris_Ste@87.249.134.10] has quit [Ping timeout: 245 seconds]
06:38 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev
06:41 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 258 seconds]
06:58 -!- whysthatso125070 [~whysthats@74-206-50-195.sta.estpak.ee] has joined #lightning-dev
07:02 -!- jonatack3 [~jonatack@user/jonatack] has quit [Ping timeout: 245 seconds]
07:10 -!- jonatack3 [~jonatack@user/jonatack] has joined #lightning-dev
07:37 -!- jonatack3 [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
08:34 -!- jonatack3 [~jonatack@user/jonatack] has joined #lightning-dev
08:48 -!- whysthatso125070 [~whysthats@74-206-50-195.sta.estpak.ee] has quit [Quit: The Lounge - https://thelounge.chat]
09:27 -!- whysthatso125070 [~whysthats@74-206-50-195.sta.estpak.ee] has joined #lightning-dev
09:38 < BlueMatt[m]> yea, similar question came up for us recently of what do you do if someone sends an announcement_signatures when we haven't seen the funding tx confirm yet. obv we should see it - if not it indicates our peer is a full six blocks head of us (?!), but if it does, do we store the sigs and check them later, or do we just assume something is horribly wrong and error the channel (which is what we do now)
09:47 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev
09:50 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 246 seconds]
09:54 < vincenzopalazzo> yeah I see! manage this case in a lite way is a good way only for testnet or similar networks when in these networks this kind of reorg will happen, but I guess in mainet six blocks are enough to stop and think that there is something strange that it is going on
09:57 < vincenzopalazzo> I think I will go to make a deep think on this and write an ML blog about this! In our case (cln) this happens only in a test where we force the reorg, there is someone that notes this also on production? or maybe on testnet? Where do you have this report in ldk Matt Corallo ?
10:05 < BlueMatt[m]> We did not have a report of it ever happening
10:06 < BlueMatt[m]> We were just talking about it in the abstract when looking at that code
10:13 < vincenzopalazzo> Oh nice! Ok got it! I was under the feeling that I was missing somethings, but I was not!
10:48 -!- jonatack3 [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.8]
10:52 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev
12:54 -!- Netsplit *.net <-> *.split quits: jkczyz, gleb
13:01 -!- Netsplit over, joins: gleb, jkczyz
16:05 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev
16:09 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 244 seconds]
17:14 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Quit: Konversation terminated!]
19:14 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev
19:18 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 250 seconds]
19:50 -!- riclas [~riclas@26.27.71.148.rev.vodafone.pt] has quit [Ping timeout: 244 seconds]
22:24 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev
22:27 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 244 seconds]
--- Log closed Sat Jul 22 00:00:06 2023