--- Log opened Wed Jan 31 00:00:45 2024
02:32 -!- jespada [~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net] has quit [Read error: Connection reset by peer]
02:35 -!- jespada [~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net] has joined #lightning-dev
03:05 -!- the_mariner [~Thunderbi@2804:7f7:e18e:3341:35da:df42:61ec:b4c] has joined #lightning-dev
05:14 -!- the_mariner [~Thunderbi@2804:7f7:e18e:3341:35da:df42:61ec:b4c] has quit [Ping timeout: 264 seconds]
05:36 -!- the_mariner [~Thunderbi@2804:7f7:e18e:3341:35da:df42:61ec:b4c] has joined #lightning-dev
05:58 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev
06:01 -!- _flood [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 260 seconds]
07:43 -!- jarthur [~jarthur@user/jarthur] has joined #lightning-dev
08:04 -!- jarthur_ [~jarthur@user/jarthur] has joined #lightning-dev
08:04 -!- jarthur [~jarthur@user/jarthur] has quit [Ping timeout: 268 seconds]
08:34 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
08:38 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev
08:50 -!- the_mariner1 [~Thunderbi@191-247-24-86.3g.claro.net.br] has joined #lightning-dev
08:54 -!- the_mariner [~Thunderbi@2804:7f7:e18e:3341:35da:df42:61ec:b4c] has quit [Ping timeout: 256 seconds]
08:55 -!- the_mariner1 [~Thunderbi@191-247-24-86.3g.claro.net.br] has quit [Ping timeout: 264 seconds]
08:55 -!- the_mariner [~Thunderbi@2804:389:7104:9173:10b7:4da8:c750:6411] has joined #lightning-dev
08:55 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
09:37 < Ademan> probably a dumb question but I am only just now starting to read up a bit more on ln-symmetry. Supposing that you have a channel partner that broadcast an old channel update, and you go to broadcast your own, couldn't a malicious peer malleate your update to spend the previous update instead of the funding transaction? As I was typing this I realized that this wouldn't actually force you to pay more 
09:37 < Ademan> fees, since presumably your channel partner CPFP'd their update tx enough for it to make it into the mempool anyway?...
09:56 -!- faceface [~faceface@user/faceface] has joined #lightning-dev
09:56 -!- the_mariner1 [~Thunderbi@2804:7f7:e18e:3341:5dce:8620:a2f3:91f6] has joined #lightning-dev
09:59 -!- the_mariner [~Thunderbi@2804:389:7104:9173:10b7:4da8:c750:6411] has quit [Ping timeout: 256 seconds]
09:59 -!- the_mariner1 is now known as the_mariner
10:10 -!- cguida [~cguida@2806:2f0:55e1:f7b9:9a30:242d:c028:f77c] has joined #lightning-dev
11:10 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
12:33 -!- proofofkeags [~proofofke@fw1.groundfloorclub.edge.customer.sonic.net] has joined #lightning-dev
12:34 < proofofkeags> Is there a fundamental reason that we prohibit at the protocol level the channel reserve needing to exceed the dust limit?
12:35 < BlueMatt[m]> you mean the other way around, right (that reserve must exceed dust)? But, yes, the point of the reserve is to have something to steal if the broadcaster cheats. if that something is dust, then we have nothing.
12:35 < proofofkeags> ah yes sorry for the negation
12:35 < proofofkeags> I understand why we WANT to set it to a level that is appropriately high
12:36 < proofofkeags> but we have someone asking about a LSP<->mobile use case and they don't want to impose reserve on their users for whatever reason
12:36 < proofofkeags> and they understand the reason for the channel reserve
12:37 < proofofkeags> so I think relaxing that to SHOULD as opposed to MUST seems appropriate
12:38 < BlueMatt[m]> there are indeed many mobile <-> LSP cases where the mobile user is allowed to have a zero reserve, but I'm not really at all convinced its something we should support at the BOLT level...
12:38 < BlueMatt[m]> IIRC the BOLTs allow the counterparty to do something stupid (like set zero reserve) it only requires that you require you counterparty not do something stupid
12:38 -!- proofofkeags [~proofofke@fw1.groundfloorclub.edge.customer.sonic.net] has quit [Remote host closed the connection]
12:41 -!- proofofkeags [~proofofke@fw1.groundfloorclub.edge.customer.sonic.net] has joined #lightning-dev
12:42 < proofofkeags> But that's not what the spec says in this case
12:42 < BlueMatt[m]> okay, well maybe should, that's at least how ldk does it :)
12:43 < proofofkeags> I mean, correct me if I'm wrong but... https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#requirements
12:43 < proofofkeags> "MUST set `channel_reserve_satoshis` greater than or equal to `dust_limit_satoshis`
12:44 < proofofkeags> and since that value is the imposition on the counterparty it should be able to be set arbitrarily low with the understanding that if the chan reserve is less than the dust limit the output just gets pruned
12:44 < BlueMatt[m]> that's on the sending side
12:45 < proofofkeags> yeah but sending a channel_reserve_satoshis is the requirement you are levying
12:45 < proofofkeags> not the  budget you're volunteering
12:45 < BlueMatt[m]> mmmmm, no you're right
12:45 < BlueMatt[m]> cause you MUST fail the channel if dust_limit_satoshis is greater than channel_reserve_satoshis.
12:45 < BlueMatt[m]> so LDK ignores that part
12:46 < BlueMatt[m]> and i think i agree that the bolt spec shouldnt require that
12:46 < proofofkeags> cool I'll make a PR
12:46 < BlueMatt[m]> but ultimately I'm not sure the BOLT spec (or anyone, really) should allow setting the dust limit to 0
12:46 < BlueMatt[m]> as much as i get the why and probably would do the same if i were running an LSP with mobile users :)
12:46 < BlueMatt[m]> but i assume you've seen https://github.com/lightning/blips/pull/30
12:47 < proofofkeags> ah, I hadn't seen the blip but I know that tbast has mentioned it on a few occasions
12:48 < proofofkeags> help me square "not sure BOLT/anyone ... dust limit to 0" and "I... would probably do the same if..."
12:48 < proofofkeags> seems like the BOLT spec is there to help make it such that coordination is possible
12:49 < BlueMatt[m]> i mean its pretty trivially possible today, luckily, people dont really change much just the field in the negotiation
12:49 < BlueMatt[m]> there's been some discussion about it re: v2 opens
12:49 < BlueMatt[m]> cause those mandate 1% reserve
12:49 < proofofkeags> right but again, I'm not sure it makes sense to do that at the spec level
12:49 < BlueMatt[m]> see comment at https://github.com/lightning/bolts/pull/851/files#r1466807265
12:50 < proofofkeags> at minimum should be relaxed from MUST to SHOULD
12:51 < proofofkeags> catching up on the thread you linked
12:52 < proofofkeags> I agree that making it negotiable is probably complexity we don't need, and that a 1% or 0% is probably sufficient
13:10 < proofofkeags> https://github.com/lightning/bolts/pull/1133
13:15 -!- proofofkeags [~proofofke@fw1.groundfloorclub.edge.customer.sonic.net] has quit [Remote host closed the connection]
13:17 -!- proofofkeags [~proofofke@fw1.groundfloorclub.edge.customer.sonic.net] has joined #lightning-dev
13:58 -!- proofofkeags [~proofofke@fw1.groundfloorclub.edge.customer.sonic.net] has quit [Remote host closed the connection]
14:05 -!- proofofkeags [~proofofke@fw1.groundfloorclub.edge.customer.sonic.net] has joined #lightning-dev
15:08 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
15:39 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
15:39 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev
16:12 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 252 seconds]
17:17 -!- the_mariner [~Thunderbi@2804:7f7:e18e:3341:5dce:8620:a2f3:91f6] has quit [Ping timeout: 240 seconds]
17:21 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
17:54 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 255 seconds]
19:05 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
19:09 -!- proofofkeags [~proofofke@fw1.groundfloorclub.edge.customer.sonic.net] has quit [Remote host closed the connection]
19:25 -!- proofofkeags [~proofofke@157-131-201-29.fiber.dynamic.sonic.net] has joined #lightning-dev
19:35 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 264 seconds]
19:46 -!- proofofkeags [~proofofke@157-131-201-29.fiber.dynamic.sonic.net] has quit [Remote host closed the connection]
20:35 -!- b42 [~mmilata@b42.cz] has quit [Ping timeout: 256 seconds]
20:46 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
21:16 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 264 seconds]
21:36 -!- lbia1 [~lbia@user/lbia] has quit [Quit: lbia1]
22:17 -!- b42 [~mmilata@2a01:430:17:1::ffff:586] has joined #lightning-dev
22:34 -!- proofofkeags [~proofofke@2601:646:4381:7100:d26:4ae:15b5:6b4f] has joined #lightning-dev
22:39 -!- proofofkeags [~proofofke@2601:646:4381:7100:d26:4ae:15b5:6b4f] has quit [Ping timeout: 260 seconds]
22:51 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 276 seconds]
23:02 -!- jarthur_ [~jarthur@user/jarthur] has quit [Quit: jarthur_]
23:16 -!- proofofkeags [~proofofke@2601:646:4381:7100:d26:4ae:15b5:6b4f] has joined #lightning-dev
23:33 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev
--- Log closed Thu Feb 01 00:00:46 2024