--- Log opened Thu Dec 19 00:00:23 2024 00:21 -!- kevkevin [~kevkevin@209.242.39.30] has joined #lightning-dev 00:48 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 272 seconds] 01:04 -!- rszarka [~szarka@2603:3003:4eac:100:50ee:c459:c941:6266] has quit [Ping timeout: 260 seconds] 01:19 -!- kevkevin [~kevkevin@209.242.39.30] has joined #lightning-dev 01:38 -!- emcy__ [~emcy@185.69.145.95] has joined #lightning-dev 01:42 -!- mcey_ [~emcy@148.252.129.21] has quit [Ping timeout: 272 seconds] 01:49 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds] 02:28 -!- kevkevin [~kevkevin@209.242.39.30] has joined #lightning-dev 02:59 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 265 seconds] 03:03 -!- szarka [~szarka@2603:3003:4eac:100:81fb:b1a5:1a10:6849] has joined #lightning-dev 03:25 -!- kevkevin [~kevkevin@209.242.39.30] has joined #lightning-dev 03:45 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds] 03:55 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds] 04:23 -!- kevkevin [~kevkevin@209.242.39.30] has joined #lightning-dev 04:43 < realtbast[m]> Question for CLN, LDK and LND: how does your implementation behave if it receives announcement_signatures or channel_announcement before 6 confirmations? 04:46 -!- jcea [~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00] has joined #lightning-dev 05:06 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 05:12 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds] 05:13 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 05:13 < realtbast[m]> Context: https://github.com/lightning/bolts/pull/1215 05:25 < tnull[m]> "Question for CLN, LDK and LND..." <- I think we just ignore it and return an error if we receive it before the channel is usable (i.e., sent and received channel_ready). 05:26 < realtbast[m]> Ok, so you only gate it on channel_ready? That works for me 👍️ 05:27 < realtbast[m]> And on the graph side, when you receive channel_announcement for an external channel (not yours), do you check that it has 6 confs before adding it to the graph? 05:33 < tnull[m]> So generally it's an interface that might get implemented differently, but our default gossip verifier implementation checks that we at least see 5 confirmations (intentionally leaving a buffer of one here) 05:34 < realtbast[m]> If it doesn't have 5 confirmations, what do you do with the channel_announcement? You drop it entirely or do you keep it and reprocess when the next block comes? 05:40 < tnull[m]> We don't cache them, i.e., drop them entirely 05:41 < tnull[m]> Assuming that nodes will rebroadcast once they are ready 05:43 < realtbast[m]> mmmh ok that may be an issue: if your view of the blockchain is late by a few blocks, won't you end up missing channels? 05:43 < realtbast[m]> you'll only resolve this on reconnection when you re-do some gossip sync, won't you? 05:43 < realtbast[m]> why don't you accept the channel_announcement as soon as it has 1 confirmation? 05:44 < tnull[m]> Yes, that's why we do 5 instead of 6 confirmations, as we might be a block late. 05:45 < realtbast[m]> on busy nodes, we've seen ourselves being late by 2-3 blocks a few times, I think 1 block isn't a good enough safety margin TBH 05:46 < realtbast[m]> but more importantly, what are you protecting against by rejecitng a channel_announcement that would have only 1 confirmation? 05:48 < realtbast[m]> (note that Bolt 7 today doesn't tell you to check for 6 confirmations when receiving channel_announcement) 05:50 < tnull[m]> "on busy nodes, we've seen..." <- What do you mean with 'busy nodes' here? 05:50 < realtbast[m]> Ours :) 05:52 < tnull[m]> realtbast[m]: Right, but how is being busy (presumably on the Lightning side?) connected to being behind on chain syncing? Does that mean that you're seeing loads so high that you're lagging behind block processing for that long? 05:53 < realtbast[m]> No, busy on the bitcoin side, usually when we're force-closing a lot of channels at once 05:53 < realtbast[m]> "but more importantly, what are..." <- Can you answer this? I'm curious to know why you think there's a reason to enforce 6 blocks here 05:54 < tnull[m]> realtbast[m]: Huh, not sure I understand how that is connected, but probably isn't too important. 05:55 < tnull[m]> realtbast[m]: Yeah, tbh. I'm not sure either, maybe Matt can shed some light on it. I presume it's to be relatively strict as our counterparty is only allowed to broadcast after 6 blocks. 05:56 < tnull[m]> Probably we also don't want to add additional complexity to our graph for marking any UTXOs as unconfirmed, which would need to happen in case of a reorg 05:57 < realtbast[m]> That's what I would like to relax in https://github.com/lightning/bolts/pull/1215, because I don't see a good reason for being strict here when validating external channels. 05:57 < realtbast[m]> As long as both channel peers think there are enough confirmations, other nodes should just check for the channel being confirmed and unspent and not-reorged, that's it. 05:57 < tnull[m]> But I'm not quite sure why we couldn't reduce the number to 3 or so 05:57 < realtbast[m]> thanks for your answers, let's wait for more people to chime in on the PR or here! 06:36 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 264 seconds] 07:37 -!- warmhug [~warmhug@gateway/tor-sasl/warmhug] has quit [Quit: quit_reason] 08:21 -!- jcea [~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00] has quit [Ping timeout: 248 seconds] 08:36 < BlueMatt[m]> "Probably we also don't want to..." <- yea, this. we'd have to implement reorg handling and I don't want to do that. 08:38 < BlueMatt[m]> left a comment on the pr but I feel like I'm missing the motivation here. 08:49 -!- td001 is now known as td00 08:51 -!- td00 is now known as td001 09:00 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 09:12 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer] 09:14 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 09:21 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #lightning-dev 09:38 -!- Ademan_ [~ademan@user/Ademan] has quit [Quit: leaving] 09:49 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer] 10:11 -!- Ademan_ [~ademan@user/Ademan] has joined #lightning-dev 10:27 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 10:36 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds] 11:31 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 12:34 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 272 seconds] 12:38 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 12:51 -!- vikanezrimaya [375e84341b@2a03:6000:1812:100::d9c] has quit [Remote host closed the connection] 12:51 -!- vikanezrimaya [375e84341b@2a03:6000:1812:100::d9c] has joined #lightning-dev 13:43 < Ademan_> Sorry to ask for spoon feeding but what papers are out there for multi-party channel systems? 13:59 < _aj_> Ademan_: https://github.com/JohnLaw2 has a bunch 14:10 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection] 14:19 < Ademan_> _aj_: thanks! I assume in particular I should be looking at the hierarchical channel one? 14:21 < _aj_> Ademan_: maybe start with optech summaries? https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories and https://bitcoinops.org/en/topics/channel-factories/ ? 14:27 < Ademan_> thanks! 14:57 -!- Ademan_ [~ademan@user/Ademan] has quit [Quit: leaving] 15:04 -!- jcea [~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00] has joined #lightning-dev 15:47 -!- Ademan_ [~ademan@user/Ademan] has joined #lightning-dev 16:04 -!- kevkevin [~kevkevin@2607:fb90:9b00:d02d:866:96f7:119a:41d] has joined #lightning-dev 16:57 -!- kevkevin [~kevkevin@2607:fb90:9b00:d02d:866:96f7:119a:41d] has quit [Ping timeout: 248 seconds] 17:34 -!- kevkevin [~kevkevin@2601:243:197e:8f10:e04a:698:d1cc:710f] has joined #lightning-dev 17:38 -!- kevkevin [~kevkevin@2601:243:197e:8f10:e04a:698:d1cc:710f] has quit [Ping timeout: 252 seconds] 17:53 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 264 seconds] 18:20 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 18:37 -!- kevkevin [~kevkevin@2601:243:197e:8f10:d822:688d:e9d6:6a06] has joined #lightning-dev 18:42 -!- kevkevin [~kevkevin@2601:243:197e:8f10:d822:688d:e9d6:6a06] has quit [Ping timeout: 276 seconds] 18:45 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving] 18:50 -!- emcy__ [~emcy@185.69.145.95] has quit [Quit: Leaving] 18:51 -!- mcey [~emcy@185.69.145.95] has joined #lightning-dev 19:19 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds] 19:40 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 20:58 -!- kevkevin [~kevkevin@2601:243:197e:8f10:fc3f:4f82:3d5e:5bdb] has joined #lightning-dev 21:03 -!- kevkevin [~kevkevin@2601:243:197e:8f10:fc3f:4f82:3d5e:5bdb] has quit [Ping timeout: 276 seconds] 21:16 -!- greypw149 [~greypw@user/greypw] has quit [Remote host closed the connection] 21:17 -!- greypw149 [~greypw@user/greypw] has joined #lightning-dev 22:01 -!- mcey [~emcy@185.69.145.95] has quit [Remote host closed the connection] 22:01 -!- mcey [~emcy@185.69.145.95] has joined #lightning-dev 22:42 -!- greypw149 [~greypw@user/greypw] has quit [Remote host closed the connection] 22:42 -!- greypw149 [~greypw@user/greypw] has joined #lightning-dev 23:00 -!- kevkevin [~kevkevin@2601:243:197e:8f10:e5c1:2fd4:e98a:36c2] has joined #lightning-dev 23:04 -!- kevkevin [~kevkevin@2601:243:197e:8f10:e5c1:2fd4:e98a:36c2] has quit [Ping timeout: 246 seconds] 23:32 -!- mcey [~emcy@185.69.145.95] has quit [Remote host closed the connection] 23:33 -!- mcey [~emcy@185.69.145.95] has joined #lightning-dev 23:43 -!- jcea [~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00] has quit [Ping timeout: 264 seconds] --- Log closed Fri Dec 20 00:00:24 2024